Re: [PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?

2010-04-19 Thread Frank Barknecht
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:

Re: [PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?

2010-04-19 Thread IOhannes m zmoelnig
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

Re: [PD] Send and receive execution order was Re: Zen Garden re-implementing the wheel in C++?

2010-04-18 Thread Frank Barknecht
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

Re: [PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?

2010-04-18 Thread Matteo Sisti Sette
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

Re: [PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?

2010-04-18 Thread Frank Barknecht
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

Re: [PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?

2010-04-18 Thread Matteo Sisti Sette
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

Re: [PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?

2010-04-18 Thread Frank Barknecht
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

Re: [PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?

2010-04-18 Thread Frank Barknecht
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

Re: [PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?

2010-04-18 Thread Matteo Sisti Sette
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

Re: [PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?

2010-04-18 Thread Matt Barber
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