[PD] Sum of delays...

Ed Kelly morph_2016 at yahoo.co.uk
Sun Sep 22 01:09:53 CEST 2013



>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.

Kim Taylor demonstrated this with the waveguide synthesis objects. I've posted before, but here they are again...

Ed

>
>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 at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
>
>-- 
>Frank Barknecht                                     _ ______footils.org__
>
>_______________________________________________
>Pd-list at iem.at mailing list
>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
>
>  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KimsWaveguides.zip
Type: application/octet-stream
Size: 52994 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130922/2a834b7d/attachment-0001.obj>


More information about the Pd-list mailing list