Re: [PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?
Hi frank,
Thank you for the clarifications.
However, I don't see how you would "sort" (i.e. force a desired execution order) [send~]s and [receive~]s in a useful way, that is in situations where you need them.
If the only way to force execution order is by actually creating a "wired" path with subpatches, then it seems to me it is useless for [s~]s and [r~]s because if you can sort them in a wired way, then you can just replace them by wires, so you didn't need them in the first place.
Is there some other way of "sorting" them??
It's the same for messages, that's why I always keep telling newbies to use more [trigger] objects.
No it's not the same. There is a big difference. A [s] and a [r] (no tilde) _is_ equivalent to a wired connection. Ok if you have a [s xxx] and multiple [r xxx]s you cannot control the order of execution of the receives, but you _do_ know that all those [r]s (and their subtree) will be executed before the following "sibling" nodes of the [s] are executed. That is exactly the same that would happen if you had a wired connection between what is connected to [s] and all the subtrees that are connected to the [r]s: a direct one-to-many wired connection without a [trigger].
The problem with [s~] and [r~] is not the execution order among the multiple [r~]s, i.e. which [r~] is executed first. The problem is that you don't know whether the [s~] or the [r~] is executed first. That has no analogy with [s] and [r] as far as i can see.
Hi Matteo,
On Sun, Apr 18, 2010 at 12:06:57PM +0200, Matteo Sisti Sette wrote:
If the only way to force execution order is by actually creating a "wired" path with subpatches, then it seems to me it is useless for [s~]s and [r~]s because if you can sort them in a wired way, then you can just replace them by wires, so you didn't need them in the first place.
As I wrote, for "simple" connections it's not useful, but as soon as you do "bigger" calculations where order matters, it's a technique you need to know. Also s~/r~ are often used where direct connections are inconvenient, for example if you want to pass the target name by argument or if you would have a large number of connections/outlets or so. *If* order matters to you (it may not always do) you can still use the subpatch approach with dummy inlet~/outlet~ objects.
And don't forget the other application of s~/r~ where you actually *want* to have a delay of one block: feedback algorithms.
For s~/r~ may be not so useful as for delays and tabsend~/tabreceive~,though. In my upcoming paper for the LAC2010 in Utrecht, I present a way to do "control-rate" computations with signal objects as an optimization technique. For example you can calculate the "flatness" of a table by dividing the arithmetic and the geometric mean of the table calculating everything in the signal domain. There you have three operations: two means and one division. You need to make sure that you do both means before the division. The means are sent to a table, and to make sure, they are written before the division I use order forcing with subpatches.
Is there some other way of "sorting" them??
Not that I know of.
It's the same for messages, that's why I always keep telling newbies to use more [trigger] objects.
No it's not the same.
I was comparing sorting DSP execution via subpatches/connections to sorting messages via the [trigger] object. These are very similar (well, not the same, but they are the equivalents.) I didn't mean to compare s/r with s~/r~ here, which, as you correctly described, are different. But that's because message handling and signal handling are very different: signals are "always on" and execute parallel inside of a block and are executed in reverse connection order ("top" objects are executed first which is some kind of "depth-last") while messages are scheduled on demand, one-by-one and depth-first.
But if you need to sort, use connections with signals and trigger with messages. *When* you need to sort depends on what you want to do.
Ciao
Frank
Frank Barknecht escribió:
Hi Matteo,
On Sun, Apr 18, 2010 at 12:06:57PM +0200, Matteo Sisti Sette wrote:
If the only way to force execution order is by actually creating a "wired" path with subpatches, then it seems to me it is useless for [s~]s and [r~]s because if you can sort them in a wired way, then you can just replace them by wires, so you didn't need them in the first place.
As I wrote, for "simple" connections it's not useful, but as soon as you do "bigger" calculations where order matters, it's a technique you need to know. Also s~/r~ are often used where direct connections are inconvenient, for example if you want to pass the target name by argument or if you would have a large number of connections/outlets or so.
Exactly: that's the situation where I most use them.
*If* order matters to you (it may not always do) you can still use the subpatch approach with dummy inlet~/outlet~ objects.
That's the part I don't understand. I mean I can't figure out the trick. I can easily imagine (and actually tried) how to patch things to force the desired order, but then again, I see myself obliged to do the wired connections that the [s~]/[r~]s were meant to avoid.
May you please make an example of the technique? I would be so grateful.
And don't forget the other application of s~/r~ where you actually *want* to have a delay of one block: feedback algorithms.
Yeah but in that case I would rather use a [delread~]/[delwrite~] pair, ¿no?
For s~/r~ may be not so useful as for delays and tabsend~/tabreceive~,though. In my upcoming paper for the LAC2010 in Utrecht, I present a way to do "control-rate" computations with signal objects as an optimization technique.
Wow that sounds very interesting. I hope you will publish the paper on the internet so we can have a look
Thanks again cheers m.
Hi,
On Sun, Apr 18, 2010 at 01:07:21PM +0200, Matteo Sisti Sette wrote:
Frank Barknecht escribió:
*If* order matters to you (it may not always do) you can still use the subpatch approach with dummy inlet~/outlet~ objects.
That's the part I don't understand. I mean I can't figure out the trick. I can easily imagine (and actually tried) how to patch things to force the desired order, but then again, I see myself obliged to do the wired connections that the [s~]/[r~]s were meant to avoid.
May you please make an example of the technique? I would be so grateful.
Attached is a very stupid example, which should show what I mean: Here various abstractions are layed out in a way, that they execute in order. Only one connection is used for order forcing, but still many s~/r~ are active, all properly ordered.
Real life examples may not be so easy to sort, of course.
And don't forget the other application of s~/r~ where you actually *want* to have a delay of one block: feedback algorithms.
Yeah but in that case I would rather use a [delread~]/[delwrite~] pair, ¿no?
Well, you could, but s~/r~ is much easier to use. Also delread~/delwrite~ with a delay set to 0 won't have a delay of 0 in feedback situations, so it may even be more confusing.
Wow that sounds very interesting. I hope you will publish the paper on the internet so we can have a look
It will be in the LAC proceedings available on lac.linuxaudio.org soon.
Ciao
Frank
Frank Barknecht escribió:
Attached is a very stupid example, which should show what I mean: Here various abstractions are layed out in a way, that they execute in order. Only one connection is used for order forcing, but still many s~/r~ are active, all properly ordered.
Oh, I see, thank you. At least that reduces the number of necessary wires to one, but I'm not sure that is viable in "real life". I'll try to think of some example. You still have to enclose receives within a subpatch, and if you need to connect it to the "outside" of the main patch, you are again facing the same original problem.... i think.
I will think of some simple-but-near-to-real-life example and post it.
In any case, at the very least, if order matters and you're building some complex patch, I think it soon becomes quite awkward and unmantainable.
I think it would be a great improvement to be able to impose (when one needs it) some precedence restrictions, i.e. dsp dependencies, between non-wired objects. For example, having a second optional creation argument in send~ and receive~ indicating a priority - or something. Pd would simply have to treat them the same way it treats dependencies forced by wire connections - and in case a loop is detected it would give the "loop detected" error (or a warning and ignore the restriction).
Without that, if I think of some of the complex architectures I built, if I had to modify them so as to guarantee sample accuracy, I'm afraid i would just have to port everything to something other than Pd....
By the way a similar improvement in the message domain would be the possibility to force an order among [r]s of a given [s]. In this case the interface would be simpler: just a numeric argument for the [r], for example: [s xxx], [r xxx 0], [r xxx 1], etc. where receives with the same number would be executed in unpredictable order.
Hi,
On Sun, Apr 18, 2010 at 03:24:56PM +0200, Matteo Sisti Sette wrote:
By the way a similar improvement in the message domain would be the possibility to force an order among [r]s of a given [s]. In this case the interface would be simpler: just a numeric argument for the [r], for example: [s xxx], [r xxx 0], [r xxx 1], etc. where receives with the same number would be executed in unpredictable order.
Btw. [gemhead] has this in a way.
Ciao
Frank
On 2010-04-19 09:27, Frank Barknecht wrote:
Hi,
On Sun, Apr 18, 2010 at 03:24:56PM +0200, Matteo Sisti Sette wrote:
By the way a similar improvement in the message domain would be the possibility to force an order among [r]s of a given [s]. In this case the interface would be simpler: just a numeric argument for the [r], for example: [s xxx], [r xxx 0], [r xxx 1], etc. where receives with the same number would be executed in unpredictable order.
Btw. [gemhead] has this in a way.
and [gemreceive] has it exactly in this way.
(its [gemreceive] because i would like to replace [gemhead] with an abstraction, and don't depend on external libraries like iemguts where you have the [oreceive] ("Ordered RECEIVE") object, both of which are identically)
fgamsdr IOhannes
-
Frank Barknecht -
IOhannes m zmoelnig -
Matteo Sisti Sette