flexible and tight timing
hey out there, i am kinda new to max, just have 13days left with the demo, then i wanna know if its worth the bucks..
so i wanna switch from python to max because of the instable timing in python… i am mostly focusing on developing devices for live performance, so i cannat accept some inaccurate timers that frequently skipt some steps.. so simple question first.. how to make a reliable and 100% tight timer in timer in max? although then i dont even know just a small piece of whole max jitter etc, i have the reliability of a timer without hangovers…. but even there i saw the same problem that i observerd with python… lets say the timer is used to trigger a quant dynamic step seq, for 130bpm with steps of 18th, the timer is still sometimes skipping some steps … here its waaaaaaaay better then with that 50ms limit in lives python api, but it was still there. so is this signal stuff (green patch cords) the anser? didn yet work with that.. or even some other of the thousands of opportunities?
dont hesitate to tell me the most compley solution, for accurate timing i would nearly do everything
so far! thx and cheers
ah and ps :)
for every that is interested in the current project,i did a short feature video a time ago, its called "steq" and its basically midi devices synchronized and can be automated for weird shit on stage :D now first max steps are transfering this to max (http://www.youtube.com/watch?v=-jywWlDTmf0&feature=plcp awefully vid quality, but some links to python sources below)
Have a look at the factory step sequencer that comes with M4L.
It works for me without any glitches even at steps of 1/32.
to use maxmsp for timecritical stuff, go to audio setup and set a vector size = 32 and overdrive = true.
all objects which send data on the high priority thread (such as [metro]) will now run as tight as
exspected for building music apps.
okay will give it a try! thx
Regarding M4L, the vector size is 64 by default and cannot be changed.
is M4L also in overdrive on like pluggo was?
yes. M4L is fixed overdrive on and audio in interupt on, and Live (and thus M4L) is fixed 64 vector size.
even with the potential 64-bit and multichannel audio/midi and faster api access updates potentially coming in a Live9/Max7 type of update, i expect these sort of limitations are likely to remain the same. however, if video and jitter and jit.gl and jit.gl.pix etc integration becomes a bigger thing with M4L in the future (as i expect and hope), they will have to offer some sort of way to change this.
poly~ cannot work with @parallel in M4L at the moment, although can be used for custom vector sizes and up/down sampling etc. gen is working well but i have not tested more advanced things with it.