Andrew Lauzon

- Pauses for a random interval (within specified parameters)

I've been approaching this by using timepoint messages and 0/1 messages to start/stop the transport accordingly, but it seems to get stuck on the first stop. It stops ok, but then doesn't restart and it looks to me like there's a conflict between the stop (0) and start (1) messages repeating simultaneously so it just doesn't go anywhere. I didn't think this would be an issue as the start (1) message should come after a delay, but alas.

Maybe there's a better way to approach this, I don't know. Open to suggestions!

- Metronome plays 8 beats
- Pauses for a random interval (within specified parameters)
- Resumes for another 8 beats
- Stops

I've been approaching this by using timepoint messages and 0/1 messages to start/stop the transport accordingly, but it seems to get stuck on the first stop. It stops ok, but then doesn't restart and it looks to me like there's a conflict between the stop (0) and start (1) messages repeating simultaneously so it just doesn't go anywhere. I didn't think this would be an issue as the start (1) message should come after a delay, but alas. 

Maybe there's a better way to approach this, I don't know. Open to suggestions!


pause-and-automatically-restart-transport

Thanks Rick! That does the trick, although the patch is in fact much more complex than that - it needs to wait for a response after the second pause, and then repeat a specific number of times. I only posted the relevant section to keep it simple, and the main toggle triggers a bunch of other stuff so I'm not sure it would work in the grand scheme. Anyway, I ended up using a combination of counters and select messages - screenshot pasted below if anyone is interested.

But what I don't understand is why yours worked and mine didn't? It looks like the only thing you changed was the destination of the output from the "1" message to go into the Toggle instead of the Transport. Either way, the Transport is receiving a "1" message to restart. So what's the difference?

It's because your patch sends a zero at the same time that it sends a one to the transport. Easier to see...

Ah yes, I do see that now - thank you. I figured the 1 would be sent after the 0 and thus not be a problem - but (and please correct me if I'm wrong) I suppose the 0 is triggered again as a consequence of the 1 because it has restarted the transport at that same time point...?

Your right the one is sent after the zero and when you restart the transport, time has not changed and the timepoint bangs zero and sends a delayed bang to one restarting the transport, time has not changed......

Pause and automatically restart transport?