to_the_sun

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

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...

which-objects-require-a-deferlow-after-them

the uzi examples are not equivalent. definitely hard to say for sure without a patch what you should do(using the high-priority thread is not necessarily a bad thing if you have no other need for the cpu).

"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"

good strategy :) (you'll see the actual effects as it applies to your own intuition and get the proper feel for deferring things(max is very open-ended, choosing which math to use is often developed as a form of intuition by trying things out the way you describe))

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.

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.)

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. 

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?

"you also dont need to use defer or deferlow when triggering something jitter-ish, the video objects do it from alone."

not sure if that's quite true... if you bang output from jit.matrix using a metro, it behaves very differently than if you use qmetro, at least as far as i've seen(better to use the deferred 'qmetro' with jitter objects).... perhaps roman is talking more about the outlets of jitter objects... while i'm talking about triggering output from jitter objects using bangs at inlets.

"Can i expect everything represented by 2) to happen on low-priority and then at 3) pick up on high?"

ya, sorta.... everything represented by 2) is moved to low-priority, but since uzi itself is not deferred at its 'donebanging' outlet, that middle outlet might trigger sooner than the deferred stuff at its right-outlet is completely received by other objects... this might not matter much, though, depending on the rest of your patch...

(crap, i'm not going to be able to explain this... haha... hopefully someone else can pick up better...)

either way, it's safe to assume that the stuff going out the right outlet of your above-patch will be deferred to low-priority, while the stuff going out the left-outlet will be left at whatever priority existed before.

ya, sorta.... everything represented by 2) is moved to low-priority, but since uzi itself is not deferred at its 'donebanging' outlet, that middle outlet might trigger sooner than the deferred stuff at its right-outlet is completely received by other objects... this might not matter much, though, depending on the rest of your patch...
(crap, i'm not going to be able to explain this... haha... hopefully someone else can pick up better...)

either way, it's safe to assume that the stuff going out the right outlet of your above-patch will be deferred to low-priority, while the stuff going out the left-outlet will be left at whatever priority existed before.


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]?

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...

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...

"What about if I deferred the carry outlet of the uze also, and then immediately undeferred it with a [del 0]?"

i might put a deferlow at the 'carry outlet'(the 'break' message will work for you the way you want)... but i'm not sure about this 'undeferring' stuff... not sure if it's necessary.

let's say you have a deferlow at the 'carry outlet', which then triggers a toggle to trigger a metro. the bang coming out the 'carry outlet' is deferred in priority, but once it triggers(perhaps a little later than when in regular priority), the toggle and metro will then work in their regular priority(whatever that is according to scheduler settings.... in other words, they will work same as they normally do without any deferment(unless you were to put additional 'deferlow's at their outlets as well...).

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.

Others will correct me if i'm wrong(hopefully. i wouldn't mind being cleared up on this either. i thought i understood it before, but considering it in newer contexts always trips me up...), but having a 'del 0' immediately(or even shortly) after a 'deferlow' seems unnecessary(if you want to use 'del 100' because you really need the delay, that's understandable, but a 'del 0' will not put anything back on track timing/priority-wise anyways.... just to be clear: del DOES move things to higher-priority, but using 'del 0' to do this after a 'deferlow' might not have the effect you expect)...

i might put a deferlow at the 'carry outlet'(the 'break' message will work for you the way you want)... but i'm not sure about this 'undeferring' stuff... not sure if it's necessary.
let's say you have a deferlow at the 'carry outlet', which then triggers a toggle to trigger a metro. the bang coming out the 'carry outlet' is deferred in priority, but once it triggers(perhaps a little later than when in regular priority), the toggle and metro will then work in their regular priority(whatever that is according to scheduler settings.... in other words, they will work same as they normally do without any deferment(unless you were to put additional 'deferlow's at their outlets as well...).

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.
Others will correct me if i'm wrong(hopefully. i wouldn't mind being cleared up on this either. i thought i understood it before, but considering it in newer contexts always trips me up...), but having a 'del 0' immediately(or even shortly) after a 'deferlow' seems unnecessary(if you want to use 'del 100' because you really need the delay, that's understandable, but a 'del 0' will not put anything back on track timing/priority-wise anyways.... just to be clear: del DOES move things to higher-priority, but using 'del 0' to do this after a 'deferlow' might not have the effect you expect)...


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....

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

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.

"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.

oops, slight clarification about something i said: "i might put a deferlow at the ‘carry outlet’…"

i take that back. trying what roman said "see what an [uzi 10000000] will do to a [metro 25]-[click~]"... i see you don't need to defer uzi's carry outlet if you're deferring any other outlet; it's as if uzi knows when the last deferred bang goes through.

this deferring business is complex :p ...but i see the focus of deferring(by the deferlow help file) is on 'incoming messages'(rather than the inlet of deferlow as i was saying), so i guess in a way it defers the entire incoming connection... as is explained more clearly in this article and seems implied in particular by the passage that says the object is placed between the 'output node' and the 'input node' of the deferred connection:

https://cycling74.com/articles/event-priority-in-max-scheduler-vs-queue/

(at least the rest of it besides that extra deferment of carry-outlet works the way i thought it would :p)

(i got some more ideas, but i'll post in your other thread... just wanted to drop that link above here, relevant to the thread, in case it's helpful for you or future-others :)

i take that back. trying what roman said "see what an [uzi 10000000] will do to a [metro 25]-[click~]"... i see you don't need to defer uzi's carry outlet if you're deferring any other outlet; it's as if uzi knows when the last deferred bang goes through.
this deferring business is complex :p ...but i see the focus of deferring(by the deferlow help file) is on 'incoming messages'(rather than the inlet of deferlow as i was saying), so i guess in a way it defers the entire incoming connection... as is explained more clearly in this article and seems implied in particular by the passage that says the object is placed between the 'output node' and the 'input node' of the deferred connection:
https://cycling74.com/articles/event-priority-in-max-scheduler-vs-queue/

(at least the rest of it besides that extra deferment of carry-outlet works the way i thought it would :p)
(i got some more ideas, but i'll post in your other thread... just wanted to drop that link above here, relevant to the thread, in case it's helpful for you or future-others :)


Which objects require a deferlow after them?