Midi Sequencing in MSP?
Hi :)
This is just a general question i was thinking of..
So from what i have understood msp driven sequencers are a very stable and tight way of sequencing in max. But is this still the case in scenarios where these signals need to be translated back to max control rate (i.e. edge detecting), like for example when working with midi messages / sequencing?
Thx for the help in advance :)
in this case the scheduler can be better, because the conversion introduces jitter.
so this means that enabling overdrive in the scheduler & working with metro based timing will be a better option in this case if i get you right? I guess other conversion options like snapshotting are also jittery?
Pretty sure this is a conceptual question, but for me as a beginner it is quite difficult to distinguish which parts of a patch are woth to be realisied in msp and which in max controle rate (apart from obvious UI applications of course). Or lets say: is there a general rule of thumb how to interact with those rates (+ gen) most efficently?
if you ask me, the general rule is "avoid it when you can, and if you do it, never do it two times but only on one direction."
on one hand using snapshot 0.7 at a vectorsize of 32 will still still give you a data rate stream of up to 0.7 ms, which is about what a physical DIN MIDI connection can transport (assuming here that most midi data consists of 3 bits)
on the other hand when working with midi you often want to keep control about priority (beginning with the different channels), which is hardly possible when coming from two signals.
signal rate sequencing is great when you stay within MSP - for most other use cases i would question the point of the matter.
mc.midiplayer~
XXXXXXXXXXXXXXXXXXXXXXXXXXXX
Haha whooooot? That’s exactly what I was searching for double_UG! Can’t wait to test this! Thx!
Hi Lucas, unfortunately the nature of the internet is that very old and out of date information on Max circulates forever! The control rate clocks in Max were overhauled several versions ago and are now dead accurate. They will stay correct over the long haul to the nearest possible control rate boundary (ie jitter to it). You can test his by setting the Max signal vector to 1 sample, and you'll have sample accurate sequencing.
There are of course other reasons you might want to sequence in audio or gen, but as Roman points out, that only makes sense if you are doing other work that is in MSP or Gen. If you are go over the boundary anyway, it won't make any difference to timing accuracy as crossing from audio to control will introduce the same jitter (up to 1 signal vector size of samples).
I did extensive tests on this when building Scheme for Max. My Scheme (control rate scheduler) sequencers stay locked up with Ableton's built in sequencers forever.
hope that helps!
Hi Ianin!
Thx for sharing this, thats very good to know. I was wondering if this jitter/delay thing/issue also counts for objects like what~?
what~ reacts to message input sample accurate when interrupt is turned ON.
i think the same is true for vst~ and click~ since several years and sig~ since ever.
older objects like edge~, snapshot~, number~ can only only output messages with every vector (so it depends on runtime´s vectorsize - where 1 is quite expensive and won´t even work with most DACs.)
however, compared to messages (in an almost empty scheduler thread) one sample is also "slow". :)
when i think about it, snapshot~ should actually output at scheduler clock (1ms grid) in interrupt.
Intersting! And how abou that index message which what~ will put out of its right outlet? Is this also sample accurate? If this would be the case t b this message would be a neat way of translating the audio clicks into bangs right?
My understanding is that if you have Audio in Interrupt and Overdrive on, Scheduler execution cycle time IS one vector size. The scheduler clock setting only has an effect if you do not have Audio in Interrupt selected. in interrupt mode, it will roundrobin between a pass of processing messages and a pass of processing audio.
So no matter what you do, if you listen to signals and output messages, your message output will be delayed to the next boundary of a message pass.
some do samples when in interrupt - including the output of newer versions of snapshot~ - i can´t remember where, but i promise i read that in a cycling document(!)
it won´t change anything about the recommendation to stay in data rate. there you do not have to worry about how all this weird stuff works and why and in which version something has changed its behaviour.
we have already seen patches by people who try to go from signal to bang and back to signal, with objects who are said to support this - but it still might not work sample exact as soon as the scheduler queue is huge... the rate bang can still be so so slow that it is shifted for one sample at the next domain change. :)
and how many snapshots you want to run in parallel when you create a 100 track sequencer? they become very, very hungry, the more you use of them...
otherwise... click to bang: edge~, bang to click: click~