Easier one-shot sequences

[blurk]

Unless I've missed something obvious, I'd like an easier mode for setting up one-shot sequences. The obvious thing I have tried, as per the documentation is to simply turn off the "Loop" parameter in various step sequencers. Unfortunately, since I'm still using the normal run mode for most things, it seems that turning off looping for a single step sequencer will also stop the master transport (I guess that's a side affect of the way all the transport controls are linked).

With a bit of effort, I set up a one-shot step-seq by changing the run mode to CV Trig: Play and linking the Master Clock gate out to the step-seq's trigger in. Even then, it only seems to work the first time I start the master transport playing. So hence my feature request for an easier one-shot mode that won't affect the master transport.

[jim]

Unless I've missed something obvious, I'd like an easier mode for setting up one-shot sequences. The obvious thing I have tried, as per the documentation is to simply turn off the "Loop" parameter in various step sequencers. Unfortunately, since I'm still using the normal run mode for most things, it seems that turning off looping for a single step sequencer will also stop the master transport (I guess that's a side affect of the way all the transport controls are linked).

I'm thinking that behavior is a bug, but I'd better think about it some more before I make a final call...

With a bit of effort, I set up a one-shot step-seq by changing the run mode to CV Trig: Play and linking the Master Clock gate out to the step-seq's trigger in. Even then, it only seems to work the first time I start the master transport playing. So hence my feature request for an easier one-shot mode that won't affect the master transport.

That should actually work. Both "CV Trig: Play" and "CV Trig: Gated" work for an example I built. Try "CV Trig: Gated" on a simple example, if that does not work for you, email me that file.

Cheers,
Jim

[blurk]

I'm thinking that behavior is a bug, but I'd better think about it some more before I make a final call...
Yes, that's why I didn't immediately assume it is a bug. If the implementation can't distinguish between the case where the specific step seq stops due to it being in one-shot mode and the case where the user explicitly stops via that step seq's transport control, then the behaviour of linking all the transports should take priority, and this won't be a bug. However, if it is easy for the implementation to distinguish these cases then I can't think of a case where it would be generally desirable for a single step sequencer in a one-shot mode to stop the entire transport.

One thing I will note (and I'm being slack here by not raising it as a bug report), but assuming this stopping behaviour isn't a bug, then there is a separate bug here: set up a MonoNote sequencer, leave the run mode as normal but make sure auto-reset is off and loop is off. The sequence will run through once, then play the first note of the sequence again, then stop. That is, it appears to reset then stop, despite auto-reset being off. That additional note should not be played, I think.

That should actually work. Both "CV Trig: Play" and "CV Trig: Gated" work for an example I built. Try "CV Trig: Gated" on a simple example, if that does not work for you, email me that file.
Confirmed: starting from scratch, with a simple case, CV Trig: Play works as expected. So there must be something weird with the case I tried (which was an attempt at tempo modulation, so there could be something extremely strange happening there). I will try and narrow that down, and send a bug report if I get anything conclusive.

Update: It appears the project goes strange when I add a GrooveClock to the stack. Bug report forthcoming...