Re: [PD] Sum of delays...
Hi Mario, On Mon, Sep 23, 2013 at 08:44:15PM -0300, Mario Mey wrote: Your router.pd is the one I was looking for for the router connection. Because I had done a dozens-of-wires connection... a mess. I use that technics, now, it is beautifull. Thank you. Great to hear! Is it better to have controls outside the audio-working abstracts and subpatches? I mean, having abstracts and subpatches without GOP and having all the buttons connected with send and receive from properties? I hate this method... but, if it is better... GUI objects that don't receive any input through their inlets, their receives or by mouse don't use any CPU ressources. So feel free to keep them wherever you want. But when you control the patch via tablet, make sure you completly bypass the GUI objects for maximum performance. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Sum of delays...
On Sun, Sep 22, 2013 at 12:09:53AM +0100, Ed Kelly wrote: 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. Oh yes they are. If you send the audio you want to feed back into a [delwrite~ feedbuf 10] object, and then take the audio back into the feedback loop using a [delread~ feedbuf 0] object, you can bypass the problem with feedback loops (stack overflow) and can create audio feedback networks. Yeah, but actually the goal here was to avoid introducing any delays and that's only possible if you avoid feedback as well. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Sum of delays...
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
Re: [PD] Sum of delays...
On Thu, Sep 19, 2013 at 01:52:37PM -0300, Mario Mey wrote: I was guessing... if I made a sum of delays using so many send~ / receive~ and throw~ / catch~... For a full use of my patch (mic input - FX-A - FX-B - output), I have this structure (inside subpatches and abstracts): ... Does every send~ / receive~ and throw~ / catch~ adds a 1 block delay? No, not at all. They only need to add a block of delay, if you use a feedback path, which you are not as far as I see. However you have to force the order of execution of your non-local signal connections with s~/r~ and throw~/catch~ to avoid delays that Pd might introduce when doing its own ordering. Do this by adding some subpatches as described in the help file: 3.audio.examples/G05.execution.order.pd or use direct connections where possible. I'm using 48000, so, do I have 1.333ms * 10 = 13ms of delay because of using that objects? Block delays with non-local connections will only happen if you don't do order forcing. But if you are careful, you will have zero delay. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Sum of delays...
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. Does the sorting include creation of abstracts? I mean, should I cut-paste from the objects (s/r, throw/catch AND abstracts) at the start of the pipeline (mic) to the last (output)? And so inside each abstract? I'm confused... and I'll be more if I would have to do it. Thanks. Mensaje original Asunto: Sum of delays... Fecha: Thu, 19 Sep 2013 13:52:37 -0300 De: Mario Mey mario...@gmail.com Para: pd-list pd-list@iem.at I was guessing... if I made a sum of delays using so many send~ / receive~ and throw~ / catch~... For a full use of my patch (mic input - FX-A - FX-B - output), I have this structure (inside subpatches and abstracts): adc~ s~ mic r~ mic s~ console-in-a r~ console-in-a s~ pre-fx-a r~ pre-fx-a throw~ post-fx-a catch~ post-fx-a s~ console-out-a r~ console-out-a s~ console-in-b r~ console-in-b s~ pre-fx-b r~ pre-fx-b throw~ post-fx-b catch~ post-fx-b s~ console-out-b r~ console-out-b s~ out r~ out dac~ Does every send~ / receive~ and throw~ / catch~ adds a 1 block delay? I'm using 48000, so, do I have 1.333ms * 10 = 13ms of delay because of using that objects? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Sum of delays...
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 -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
