[PD] Sum of delays...

[Mario Mey]

Thanks Frank, I understand the way Pd uses the sort. But I have to tell 
you that my patch has a Sound Router, as the attached file shows. With 
that router, I have different possibilities (The FX consoles are 
abstracts, also the Sample Banks):

*Mic ----------> FX console A -> FX console B -> Output
Sample Banks /

Mic ---> FX console A -> FX console B -> Output
                          Sample Banks /

Sample Banks ---> FX console A -> FX console B -> Output
                                            Mic /

Mic -> FX console A ----------> Output
Sample Banks -> FX console B /

Sample Banks -> FX console A --> Output
           Mic -> FX console B /**
***
And, with RESAMPLE FUNCTION (only one example):

*Mic ----------> FX console A -> FX console B -> Output**
**Sample Banks /                               \ Sample **Banks (resample)
*
The Sound Router is a subpatch in the main patch.

How about using s~ in the Sound Router (subpatch) and r~ in the main 
patch and, then, cord-connecting to the abstracts? (Instead of using r~ 
inside the abstract).

The default use of this patch (when I use the mic to talk to the people) 
is the first example (although the FX consoles are off). Maybe, if I 
need to sort only in one way, I should sort following these example.

Thanks again.


PD: I have to say that I'm having a good latency using this patch, but 
maybe it could be better, only sorting in the right way. In other words, 
I'm not desperate to improve this.







El 19/09/13 16:35, Frank Barknecht escribió:
> Hi,
>
> On Thu, Sep 19, 2013 at 02:20:28PM -0300, Mario Mey wrote:
>> I think most of s/r and throw/catch are between abstracts. If I want
>> to sort that objects (as Theory of Operation says: creating receive~
>> after send~)... I don't know how to do it.
> To trick Pd into sorting signal objects, that are not directly connected with
> some patchcords (like sends), you must put them into subpatches or abstractions
> and then connect these.
>
> For example this here will be unsorted:
>
>
>   [sig~ 1]
>   
>   [sig~ 2]
>   
>   [sig~ 3]
>
> But this will be sorted:
>
>   [sig~ 1]
>   |
>   [sig~ 2]
>   |
>   [sig~ 3]
>
> and this will also be sorted:
>   
>   [pd sig~1-inside]
>   |
>   [pd sig~2-inside]
>   |
>   [pd sig~3-inside]
>
> where each subpatch has something like this inside:
>
>   [inlet~] [outlet~] [sig~ 1]
>
> The 3 objects inside the subpatch don't need do be connected at all, only the
> subpatches have to be connected to force an order.
>
> In the end, you have now tricked Pd to execute signals in the order 1, 2 and 3,
> although they aren't connected to anything. The order, in which these objects
> have been created doesn't matter and you should never rely on creation order
> anyway.
>
> Instead of subpatches you can use abstraction, but you have to connect these
> just as you have connected the subpatches.
>
> Ciao

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130920/212bd9b0/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sound router.png
Type: image/png
Size: 74821 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130920/212bd9b0/attachment-0001.png>