to_the_sun

When using 'set current_song_time' in conjunction with 'set is_playing 1' and 'set record_mode 1' it seems that Live usually jumps to where the user last clicked (marked by an orange or sometimes green triangle) rather than the position specified by setting current_song_time. It really only seems that Live behaves the way I want it to when the set is fresh and has not been clicked on yet. Using deferlow i have it so is_playing happens first, and when that's finished, current_song_time followed by record_mode

It seems to me that this should be the correct order, though i've tried current_song_time first as well. Is there something I'm missing here or some other way to 'deselect' and make Live forget any prior manual selections? Or is deferlow not a big enough slow down between these 3 messages? This's gotta be a pretty common thing to want to do, so how do folks go about it?

setting-where-in-arrangement-to-immediately-begin-recording-reliably

I think 'set current_song_time $1' is basically a jump to the new position $1 when transport is running, regardless of any prior selection. So the order 'is_playing 1' followed by 'set current_song_time $1' seems correct to me. In theory, deferlow should only be needed if the messages are triggered from some high priority event like midi.

Hmmmm, it's triggered originally by a groove~ finishing up (sync outlet == 1., with a lot of other stuff in between). Maybe the transport isn't getting enough time to start up/update or something?

It seems that it does need more time than deferlow can provide. Paste this

into a patch and start the metro. If you manually click and stop the transport between each metro beat, notice the difference in behavior with a [pipe 100] thrown in. Assuming you've clicked somewhere in the arrangement first, without the pipe it will always go to the little green arrow. This makes me sad.

Looks like even a [pipe 25] doesn't provide enough time 

of the time. The worst part is that i have to say 

of the time; the time it needs seems to be pretty unpredictable.

Looks like even a [pipe 25] doesn't provide enough time most of the time. The worst part is that i have to say most of the time; the time it needs seems to be pretty unpredictable.


I came up with a solution (in [p del]) which should work for me

Yes, observing the transport should be a reliable solution. But since I've found that the API observer introduces variable latency up to 50ms, for more accurate observation of the transport state I generally use the left outlet of [plugsync~].

Ah, thanks for the tip. I was not yet aware of that object.

Setting where in arrangement to immediately begin recording, RELIABLY