Which objects require a deferlow after them?
I'm attempting to move a large portion of a large patch to the low-priority queue and I need to know which objects to watch out for, because if anything downstream jumps back up to high-priority it could cause issues. I know a [delay 0] will jump back to high; what about a [delay 100] (after the 100ms of course)? What about uzi, line, or clocker? In other words is
[deferlow]
|
[uzi]
equivalent to
[uzi]
|
[deferlow]
or no? At the moment, I think my strategy is going to be to just place one wherever I'm not sure, and err on the side of overdoing it. Here goes...
without getting too much into tech talk (which i am not very good at compared to certain others here):
when you do [uzi]–[deferlow] or [uzi]–[defer], the bangs output from uzi are already in the main thread.
a [defer] _before [uzi] does nothing, or to be exact, almost nothing (except when this [uzi] was banged from another [uzi] hundreds of times as well.)
the main question is not so much for which object, but in what situation and for what messages.
you will most likely not move [uzi 100] in a text program to the main thread, when you will run it on a mac pro.
but when you want to initialise something using [uzi 1000] while something else (music sequencer?) also runs in the hig priority thread, and you want it to run bug free on sub 500 Mhz computers, without [defer] you had no chance.
you also dont need to use defer or deferlow when triggering something jitter-ish, the video objects do it from alone.
your assumption about [delay 100] is right. it works internally like this: first moves input to higher priority, then applies the delay.
-110
Thanks for all the info. The "defer everything" method, btw, was a total failure. Everything was stuttery and just plain didn't work. My next attempt:
Q: Can i expect everything represented by 2) to happen on low-priority and then at 3) pick up on high?
Oh ok, so you're saying some or all of 2) that's triggered by the last number coming out of the third outlet is likely to get eclipsed by the carry bang. Makes sense (although i haven't gotten the chance to actually try it out yet.) I need ALL of 2) to happen before 3).
So then everything should work the way I need it to in the event of the 'break' message? I suppose that means i could always code in my own "carry bang" instead... What about if I deferred the carry outlet of the uze also, and then immediately undeferred it with a [del 0]?
If you're trying to slow down an Uzi, often best to just come up with some other way to do it. I don't know if the [sluzi] abstraction is still floating around, but there are other approaches. qmetro --> bline is another one...
\M
Basically, ‘deferlow’ defers the thing it receives in its inlet, and although this means it could slow the timing of everything that comes after it, it only does this by slowing/deferring the stuff coming into its inlet.
Oooooooooh! This totally clarifies my (mis)conception of how deferring works. It doesn't somehow have an explicit effect on everything downstream from it, it just takes a message and holds onto it while the high-priority queue clears and then lets it go. Well in that case I'm going to have to reassess this whole deferring strategy of mine....
Ok so, as Roman said above
when you want to initialise something using [uzi 1000] while something else (music sequencer?) also runs in the hig priority thread, and you want it to run bug free on sub 500 Mhz computers, without [defer] you had no chance.
This is basically what I'm trying to do. I have 1000+ uzi bullets being fired off at once and I'm getting blips in my audio when they do. But this is audio that isn't created or altered by, or ever even enters, any m4l device, just audio (either guitar coming in or going out from a midi instrument) being processed by Live itself. So how does this kind of audio interact with the processing happening in my device? As I'm coming to a greater understanding of how it all works (thanks btw) I guess I'm wondering if deferring can even be expected to alleviate this issue. So far all of my attempts at deferring have failed.
@raja: about video objects doing it from alone ... i was just thinking the same when i read my comment again. :)
what they do is probably just queueing the uzi output, which has nothing to do with threading.
i was mislead by the picture where video editing applies: you usually do not even turn overdrive on when working with jitter.
-110
"it just takes a message and holds onto it while the high-priority queue clears and then lets it go."
a deferred [uzi] still lets you shoot data as fast as possible, but without interrupting or delaying other data, which is in the high priority queue or else. just make some experiments with uzi, and see what an [uzi 10000000] will do to a [metro 25]-[click~]–[dac~] patch - or to your mouse cursor.
-110