Hi Mario, if you can I would prefer to patch with direct connections as it may make things clearer. Attach is a little sketch (router.pd) which uses no signal-sends and -receives at all, so you can be sure to have no delays introduced. Still you can route all over - but of course feedback paths are not possible.
Ciao -- Frank On Fri, Sep 20, 2013 at 09:04:03AM -0300, Mario Mey wrote: > 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 > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list -- Frank Barknecht _ ______footils.org__
router.pd
Description: application/puredata
routing.pd
Description: application/puredata
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list