Getting Gp Transport to reset on stop

Hey Folks,

Sure I’m missing something really obvious, but I can’t for the life of me figure out how to make the GP playhead reset to zero on stop.

The default behaviour is, basically, Play/Pause, so when you hit play again it picks up from where it stopped rather than starting again from the top of the loop or part. Loads of situations in which that would be a useful behaviour for sure, but I’m running a looper, so I’d like to be able to stop all of the backing, and then kick it in again from the top of the loop. Is there a setting I’m just not finding?

Cheers folks.

Are you talking about Audio Player or MIDI File Player?
And what Play button are you using?

Third party looping plugin (melda audio Msuperlooper).

Using the play button on the main transport in GP, between the link button and the metronome. Currently the looper is set to follow main transport, but as I say it seems to default to pause behaviour rather than. However it may be that that is a quirk of the plugin, as I’ve just bunged the audio player in there and stuck a loop in, sync’d it to main transport, and it seems to reset the loop each time I start and stop the main transport. So, probably a Superlooper issue rather than a GP one. Thanks Paul.

Ok, so you are using the global play button.

Yes, Global play button.

OK, does Melda Looper expose a parameter to start the loop from the beginning?

Yes, it does have a reset parameter. So you can achieve the behaviour I’m looking for by stopping playback, hitting reset and then starting playback, but that’s a whole extra button press I really don’t want every time I start and stop the loops in a live context. I also can’t imagine a scenario in which I would want to restart loops from wherever I stopped them, so I’m looking to make resetting on start a default behaviour. THe plugin doesn’t seem to offer that as an option though.

OK, with scripting I think that can be solved

// Called on attempt to change playhead status - (Rackspace and GigScript only)
On SystemEvent(newValue : double) Matching PlayheadStateChanged
 if newValue == 1.0 then 
    // Start Looper from beginning
 else
   // Stop Looper
 end
End

As always you are the script master Paul.

If I’m understanding that right, when the playhead state is changed to 1 (play) it calls start looper from beginning, and when it is changed to 0 (stop) it simply calls stop looper?

So I’d need to change the two instructions affter the // to execute the relevant actions in Msuperlooper? Guessing I need to asign them widgets and gpl script names, and then call them here somehow?

Yes, try to map widgets to the parameters of the looper
and in scripting you activate to desired widget.

Maybe that helps.

You can also use this function

SetParameter(<p : Block>, <index : Int>, <value : double>)

This way you do not need a widget but can trigger exposed parameters of a plugin directly.

The Parameter Number you should see when you activate some buttons of the plugin.
The Parameter Number should be shown in the top of the plugin window.

Example here the MIDI In Plugin

Not for me it doesn’t. When I start/stop the global playhead, MSuperlooper starts all loops from the beginning.

Ok. Interesting. Maybe it’s a setting in MSuperLooper then?

which version are you on? I’m on 14.16 currently

You have the ‘Sync’ button activated in MSuperlooper?

Paul thankyou that’s very helpful. I’ll give that a try If i can’t solve the problem at the plugin end.

Cheers!

1 Like

Ah, ok. But then I can’t freely loop, I’m locked to the bpm in GP. Yeah, that makes sense, but It’s not the behaviour I want. I want to be able to live loop (guitar, violin, beatbox, voice) without being locked to an intial tempo. Obvs with super looper, once i’ve laid down the base loop for a track, everything else will be in sync with that, but I want to be able to freely define that first loop to fit in with the flow of playing live, rather than hving to have a prerecorded starting loop or a metronome going to get it started.

I think you’ve identified the fundamental problem though. I suspect Superlooper’s only receiving a transport reset if it’s in sync mode. I probably need to pursue some kind of internal solution using scripting to act on the plugins own transport (which displays the same behaviour, the master play button pausing the loops on stop). I’ll report back if I get anywhere.

Just to check, I can’t map a widget to trigger two plugin parameters can I? It’s a one to one relationship.

Correct.

Maybe set the plugin parameter directly via scripting is easier.

No, but you can use two widgets and put them in the same group to achieve this result.

1 Like

Yes, I suspect you are right.

So, slightly new scenario: I’ve given up on using GP’s master transport to control the looper, I’ve activated the internal master transport in the plugin. I just need to create a situation in which me triggering the start/stop button also triggers the loop restart button.

Ah David-San! Widget groups. These I knew not of, but now I see that that is indeed a thing. Magnifiicent. I will give that a try for starters!

1 Like