data arrival within a vector?
so this might be a silly question, but i want to make sure i am not doing
something wrong.
imagine the following situation: i have two poly~s, and i want to turn one
off while the other one is turned on.
because i dont want glitches in the resulting signal outputs of the poly~s,
i need to make sure that the data coming from, for example [t 1 0], arrives
within the same audio vector.
should it do that already, or is there a chance that the 1 comes late (so that
the signal of the second poly~starts late?)
[t 1 0]
[poly~ signal1] [poly~ signal2]
|
-110
It depends on your settings, and threading context.
- If your t is working in the main thread, the sequence of events it triggers can be interrupted at any time by the computation of an audio vector
- If it’s working in the high priority thread, AND you have "scheduler in audio interrupt" on, it won’t be interrupted by an audio vector. On the other hand, if you’re asking for too much work to be done after the trigger, your audio might crackle. And if your signal vector size is too high, the timing of your events might not be precise enough.
for more details, have a look at http://cycling74.com/2004/09/09/event-priority-in-max-scheduler-vs-queue/
best
aa
yeah, i wouldnt have asked if it was under metro conditions.
but in the given case it is triggered by the user, and how much
other work has to be done is uncertain.
what would you suggest? [uzi 1] – [t b b] ?
You know, I don’t think there is a way to prevent the evaluation of a message from being interrupted by another thread taking over. this would require a thread-locking system at the patching level, and we don’t have one – not even with a custom external.
the only way is setting "scheduler in audio interrupt", and making sure that [t] runs in high priority. [uzi] won’t do this (if you bang it in the main thread, it will fire in the main thread as well), but [del 0] will.
hope it makes sense…
aa
well i am clear about the sheduler settings and overdrive and in
interterrupt – luckily – are my regular settings anyway in this application.
delay 0 is a good idea, but i really did not know that uzi wont get the
event up in the priority, thanks for clarifiying.
just to make me understand: would a metro recreate the bang in high
priority?
-110
then why not uzi?
ok thanks guys.
btw:
"This is a critical difference as the defer object
can cause a message sequence to reverse order,
while deferlow will preserve a message sequence’s
order."
lalala …
-110