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 simple
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
> 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 fi
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
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
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
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
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 ju
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 w
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
> > Please anybody correct me if I am wrong, but I think _unless
> > there are
> > loops in the graph_ there is _always_ an order that ensures no added
> > latency, and finding out that order is all what dsp-graph computing
> > is
> > about!!! I always thought Pd would take care of that
> > pe
11 matches
Mail list logo
