Messinki

I'm having trouble with using seq~ and a locked phasor. Whenever I start Live's transport, the first note at 0. is missed, also if the tempo is sped up enough every 0. is missed...

I have heard about SeqPlayer, but MaxObjects.com seems to be broken at the moment, does anyone have, or know if a Mac 64bit port for SeqPlayer exists?

Hello,
I'm having trouble with using seq~ and a locked phasor. Whenever I start Live's transport, the first note at 0. is missed, also if the tempo is sped up enough every 0. is missed...

I have heard about SeqPlayer, but MaxObjects.com seems to be broken at the moment, does anyone have, or know if a Mac 64bit port for SeqPlayer exists?
Thanks, Harry


Hello,
I'm having trouble with using seq~ and a locked phasor. Whenever I start Live's transport, the first note at 0. is missed, also if th

eric-singer's-seqplayer-64bit-port

Hi Harry, this myabe not the answer you're looking for, but I've got Scheme for Max working in Live nicely and want to build up a library of sequencer code examples for people. If you can share more about what SeqPlayer does (or point me at resources) I might be able to make a Scheme port for M4L.

Now that aside, in my experiments, I found that how you trigger a start makes a difference. Have you tried starting SeqPlayer off a plugsync~ object? I get tighter first beat lock up that than anything else. If one uses the transport aware clocking in Max it works very well with Live, but the first beat can have an issue depending on how you start them both.

That sounds awesome! I haven't used SeqPlayer and don't know much about it, but want to have a play with it to see if I can find a work around that is proving tricky with seq~.

https://docs.cycling74.com/max8/refpages/seq~

The usefulness of seq~ is that it has a high resoluction, so rather than a normal sequencer that is limited to a resolution of something like 16th notes, I can send seq~ a list of unquantised midi notes, and it will play back the loop just as I recorded it.

Seq~'s timing runs off a phasor~ which can be locked to Live's transport, so overall it is synced very tightly, it's just that pesky initial note it misses. I am playing with a workaround that triggers an unsynced phasor~ for syncing duringthe initial period, then fades it back into the unlocked phasor~ after a few milliseconds. 

It may be the locked phasor~ that is causing issues so this might not be solvable with Scheme for Max. 

Hi Iain,
That sounds awesome! I haven't used SeqPlayer and don't know much about it, but want to have a play with it to see if I can find a work around that is proving tricky with seq~.
https://docs.cycling74.com/max8/refpages/seq~
The usefulness of seq~ is that it has a high resoluction, so rather than a normal sequencer that is limited to a resolution of something like 16th notes, I can send seq~ a list of unquantised midi notes, and it will play back the loop just as I recorded it.

Seq~'s timing runs off a phasor~ which can be locked to Live's transport, so overall it is synced very tightly, it's just that pesky initial note it misses. I am playing with a workaround that triggers an unsynced phasor~ for syncing duringthe initial period, then fades it back into the unlocked phasor~ after a few milliseconds. 

It may be the  locked phasor~ that is causing issues so this might not be solvable with Scheme for Max. 


So there are a lot of misconceptions around that stuff now. Sometime ago (I don't know which version), the Max scheduler was overhauled and high precision clock functions were introduced. These are self-correcting, in that they figure out when they should happen at a higher resolution than the scheduler itself runs, meaning that any jitter from scheduler run frequency does not accumulate. The upshot of this is that they are as accurate as phasors for scheduling. This is because no matter how you clock things, a Max event can 

 run on the next scheduler thread pass, and in the context of Max4Live, that's going to be once per 64 samples (Live runs Max as if Audio in Interrupt is enabled, which means the Max audio thread and scheduler thread round-robin, each running once per signal vector - which is always 64 in Live). So as long as your event is ultimately triggered by a message (including midi), it doesn't matter whether you clock them off phasors or off event triggered clocking such as I use in Scheme for Max. in the case of Scheme for Max sequencers in Max for Live, if you use the transport aware quantized delay functions, they will stay as locked up with the Live clocks as it's possible for a Max *event* to be. So in other words, in the context of Max4Live, the way seq~ clocks doesn't make a difference if you are ultimately clocking an event.

Now you can still get a delay between the low thread (in which the Live API runs) and the other Max thread, so there will be a tiny delay if you are listening to Live API notifications and starting your sequencer off them. This is not the case with plugsync~ - in that case, you get triggered off the higher priority thread, as far as I understand Live's threading for Max.

FWIW, I've done extensive load testing of sequencers in Scheme for Max with Live, and if I'm triggering sounds in the same track that s4m is running in (to avoid inter-track delays over sends and receives), it stays completely locked in with Live. I'm planning on some demos of doing this over the next week or two!

So there are a lot of misconceptions around that stuff now. Sometime ago (I don't know which version), the Max scheduler was overhauled and high precision clock functions were introduced. These are self-correcting, in that they figure out when they should happen at a higher resolution than the scheduler itself runs, meaning that any jitter from scheduler run frequency does not accumulate. The upshot of this is that they are as accurate as phasors for scheduling. This is because no matter how you clock things, a Max event can only run on the next scheduler thread pass, and in the context of Max4Live, that's going to be once per 64 samples (Live runs Max as if Audio in Interrupt is enabled, which means the Max audio thread and scheduler thread round-robin, each running once per signal vector - which is always 64 in Live). So as long as your event is ultimately triggered by a message (including midi), it doesn't matter whether you clock them off phasors or off event triggered clocking such as I use in Scheme for Max.  in the case of Scheme for Max sequencers in Max for Live, if you use the transport aware quantized delay functions, they will stay as locked up with the Live clocks as it's possible for a Max *event* to be. So in other words, in the context of Max4Live, the way seq~ clocks doesn't make a difference if you are ultimately clocking an event. 

Now you can still get a delay between the low thread (in which the Live API runs) and the other Max thread, so there will be a tiny delay if you are listening to Live API notifications and starting your sequencer off them. This is not the case with plugsync~ -  in that case, you get triggered off the higher priority thread, as far as I understand Live's threading for Max. 

Oooh, very interesting, and imformative! Thank you, I will see if I can get any more reliable results using plugsync~ then.

I will keep a look out for your scheme demos, I've never heard of it before now, but sounds exciting!

Eric Singer's SeqPlayer 64bit port?