Does using inlet~ create latency?
I know that using send~ and receive~ introduce latency and am wondering whether using subpatches via inlet~ and outlet~ also introduce latency.
Related questions:
Does send (without tilde) introduce any latency?
Does using subpatches rather than one big page introduce latency?
I'm using a Pi Zero and the buffer needs to be 512 ad 4 mS to eliminate clicks, so the send~ adds up to a very noticeable lag.
Thanks!
I know that using send~ and receive~ introduce latency
Not necessarily. You can in fact force the receive~ to be scheduled after the send~, in which case there is no latency, just like with delwrite~ and delread~.
and am wondering whether using subpatches via inlet~ and outlet~ also introduce latency.
No, unless the inner patch has a bigger blocksize than the outer patch. In that case, the latency is the difference between the two block sizes.
Does send (without tilde) introduce any latency?
"latency" doesn't exist in the message domain. When you send a message to [send], it is delivered instantly to all receivers. There is no semantic difference between using [send] or patch cords.
Does using subpatches rather than one big page introduce latency?
No.
Thank you very much for the reply.
I can't seem to find any information on how to "force the receive~ to be scheduled after the send~, in which case there is no latency, " The Puckette manual doesn't describe that feature (unless I missed it).
Any help would be appreciated.
Cheers!
@StepAudio See Pd/doc/3.audio.examples/G05.execution.order.pd in your installation folders.
You will find the explanation there.
David.
I remember a cartoon (Bugs Bunny? Roadrunner?) where they are in the desert with a can of freeze dried water. The instructions were "just add water". If you have to use subpatches connected by audio connections in order to make audio sends and receives latency-free, then what have you gained?
@jameslo: Note that latency is not equal to efficiency. In that case what you gain is to avoid the (e.g. 64 samples) offset introduced (in the delay line for instance). And IIRC it costs nothing (in term of CPU) as the inlet~ will be probably cropped/removed from the DSP chain.
@Nicolas-Danet Understood, but my point is that if you have to connect two subpatches with an audio connection in order to make s~/r~ behave like an audio connection, then why not just use an audio connection? (I guess they didn't show that American cartoon in France 
)
@jameslo: you are right, it is a bit silly. 
Of course we have on TV. I have seen a lot of them when i was a child (long time ago).
@jameslo i haven't tested it but it might be the case that if you make sure to create [receive~] after [send~] that there will be no latency, (unless the [receive~] is in part of the graph that leads to [send~]). You might have to create the entire graph the [recieve~] is part of after creating the entire graph the [send~] is part of, I'm not sure..
edit: after testing I was not able to get that to work 
edit2: after further testing it seems like if I create the graph with the [receive~] first it gets sorted last, but not if I delete the [receive~] and recreate it afterwards
so there isn't always latency, it depends on how the dsp graph is sorted. If the [recieve~] is sorted earlier in the graph before the [send~], as in the case of feedback, then there will be a block delay since [recieve~] will process the shared buffer's samples before [send~] has had a chance to write to the shared buffer. (so [recieve~] will only get the samples written in the current block by [send~] in the next block, creating a block delay.)
@seb-harmonik.ar I'm confused. You write about manipulating the dsp graph sort order, but you don't mention using the subpatch/audio connection idiom as described in Pd/doc/3.audio.examples/G05.execution.order.pd. Is there another way? Please show!
@jameslo I didn't actually go through the code but just in the simple tests I did if you create the entirety of the graph with the [receive~] (including the [receive~]) before the graph with the [send~] (including the [send~]) then it appears to be in the right sort-order.
however when I deleted the [send~] and [receive~] afterwards I couldn't get it back in the right order when I recreated them no matter the order.. maybe something to do with [send~] being at the bottom of a graph and [receive~] being at the top of one or something.
might have a look through the source later and try to figure it out for real.
I would think that this is dependent on the implementation and not guaranteed to stay the same if the implementation changes significantly tho..
Ideally all [send~] graphs would be sorted before their corresponding [receive~] graphs..
@seb-harmonik.ar Ugh, I'm still not following. Could you please post your test patch?
@seb-harmonik.ar Oh I see! I didn't know dsp sort order was influenced by the object creation order. The fact that you can't see it suggests to me that this is one of those behaviors one shouldn't rely on if code clarity is your goal. The creation order can be seen if you open the patch in a text editor, right?
@jameslo yeah, and also it could change based on the implementation. Definitely should be avoided, but it seems possible.
@jameslo Yes and this is also the case with [receive]. The [receive] created first will get the message first. By using cut & paste you can change the order of receives. 
@ingox it's not exactly the same bc the management of the dsp graph is not exactly analogous to the "receive list" of the send symbol
I wonder if it would be helpful if both [receive] and [receive~] objects supported a numeric argument for response priority. (Maybe [send~] as well, for this case: currently it seems it's mandatory to create the receiver first, but a priority order could fix that.)
It's one of the things that continually grates in graphical patchers: programming logic can be altered by features of the patch that are not visible in the patch. [t] handles this for explicit connections but there is no equivalent for [receive] -- or rather, the existence of [t] acknowledges that this is a real problem, but yet unsolved for send/receive.
hjh
There is [oreceive] object in iemguts lib that supports a numeric argument for response order.
Oops! Looks like something went wrong!
