Re: [PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?
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 smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Send and receive execution order was Re: Zen Garden re-implementing the wheel in C++?
On Sat, Apr 17, 2010 at 08:53:12PM +0200, Matteo Sisti Sette wrote: Now the subpatch trick (btw thank you for pointing me to the documentation resources about it) doesn't help at all for [send~] and [receive~] does it? I mean it's applicable but if you can arrange the send and receive into subpatches that you have to connect physically, then you don't need the s~ and r~ in the first place... If you only have a s~/r~ in your subpatch, then indeed you should probably not use them anyway. But very often you have more stuff happening, so you can sort larger parts of your alorithm. As Tim wrote, the problem comes from Pd being a Max-like, two-dimensional programming language, where order can be ambigous, unless you employ one of the sorting mechanisms built into Pd. It's the same for messages, that's why I always keep telling newbies to use more [trigger] objects. It may come as a surprise that it also affects signals, but it's a closely related issue. Think of the patchcord as Pd's DSP way to say [t b a]. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
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. -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?
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. -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?
On Sun, Apr 18, 2010 at 02:47:05PM +0200, Frank Barknecht wrote: Attached is a very stupid example Now it is, stupid me. Ciao -- Frank #N canvas 0 0 450 300 10; #X obj 172 110 s~ \$1-sig; #X obj 172 61 noise~; #X obj 178 84 print~ \$1-send; #X obj 230 60 r PRINT; #X connect 1 0 2 0; #X connect 1 0 0 0; #X connect 3 0 2 0; #N canvas 0 0 450 300 10; #X obj 172 110 r~ \$1-sig; #X obj 172 180 print~ \$1-receive; #X obj 191 140 r PRINT; #X connect 0 0 1 0; #X connect 2 0 1 0; #N canvas 284 166 587 388 10; #N canvas 567 281 450 300 sends 0; #X obj 154 58 sendarg 0; #X obj 154 78 sendarg 1; #X obj 154 98 sendarg 2; #X obj 154 118 sendarg 3; #X obj 154 138 sendarg 4; #X obj 68 19 inlet~; #X obj 71 198 outlet~; #X restore 119 97 pd sends; #N canvas 0 0 450 300 receives 0; #X obj 86 64 recarg 0; #X obj 86 84 recarg 1; #X obj 86 104 recarg 2; #X obj 86 124 recarg 3; #X obj 86 144 recarg 4; #X obj 38 17 inlet~; #X obj 41 196 outlet~; #X restore 120 124 pd receives; #X text 43 33 Here all sends are executed before all receives resulting in a latency of 0; #N canvas 567 281 450 300 sends 0; #X obj 68 19 inlet~; #X obj 71 198 outlet~; #X obj 154 78 sendarg 11; #X obj 154 98 sendarg 21; #X obj 154 118 sendarg 31; #X obj 154 138 sendarg 41; #X restore 108 239 pd sends; #N canvas 0 0 450 300 receives 0; #X obj 38 17 inlet~; #X obj 41 196 outlet~; #X obj 86 84 recarg 11; #X obj 86 104 recarg 21; #X obj 86 125 recarg 31; #X obj 86 144 recarg 41; #X restore 108 218 pd receives; #X text 53 166 Here all sends are executed after all receives resulting in a latency of one block; #X connect 0 0 1 0; #X connect 4 0 3 0; #N canvas 284 166 573 378 10; #N canvas 567 281 450 300 sends 0; #X obj 154 58 sendarg 0; #X obj 68 19 inlet~; #X obj 71 198 outlet~; #X restore 119 97 pd sends; #N canvas 0 0 450 300 receives 0; #X obj 86 64 recarg 0; #X obj 38 17 inlet~; #X obj 41 196 outlet~; #X restore 120 124 pd receives; #X text 43 33 Here all sends are executed before all receives resulting in a latency of 0; #X obj 279 172 s PRINT; #X msg 279 147 bang; #N canvas 567 281 450 300 sends 0; #X obj 68 19 inlet~; #X obj 71 198 outlet~; #X obj 154 58 sendarg 10; #X restore 119 293 pd sends; #N canvas 0 0 450 300 receives 0; #X obj 38 17 inlet~; #X obj 41 196 outlet~; #X obj 86 63 recarg 10; #X restore 119 269 pd receives; #X text 62 244 Reversed order has a delay of 1 block.; #X connect 0 0 1 0; #X connect 4 0 3 0; #X connect 6 0 5 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?
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. -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?
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. Here's a relatively simple real-life example I posted a couple weeks ago: http://lists.puredata.info/pipermail/pd-list/2010-04/077392.html In this example I had an algebra problem that was complex enough that it would have been way too messy to draw wires for each term, so instead I named the terms and sent them via send~/receive~. However, because it was algebraic and not just an fx patch (where latency may or may not have mattered as much), I had to force execution order. It's really useful in cases where you have 10 send~s in one subpatch, because you can force order with just one connection -- sometimes a lot cleaner than 10 wires, especially when those wires would have gone to several different places. Matt PS -- I think my example has one unnecessary dummy outlet~/inlet~ pair, but I was being paranoid. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
