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?
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.
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.
// 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
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?
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.
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.
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!