[PD-dev] dynamic patching - is iemguts the way to go?

[Alex Norman]

Yeah, maybe that is positive (reverb tails etc) but if not, you could put the control on the other end, send your signal into every effect in parallel and then mix in the one you want to hear selectively.

Alex

On August 20, 2019 7:06:10 PM PDT, Nick Porcaro <nick at porcaro.org> wrote:
>Hey x_nor,
>
>The problem with this approach is that you still have active signal
>processing going in
>each effect even if they are panned to zero (I assume) and you couldn’t
>change the running
>order of effect1 and effect2.
>
>Thanks for thinking on it though.  I’m going to study Miller’s
>responses and let you all know it goes-
>
>- Nick
>
>> On Aug 20, 2019, at 7:26 PM, x nor <x37v.alex at gmail.com> wrote:
>> 
>> another approach could be to generate all the permutations of your
>effects as abstractions and simply route audio to a permutation
>selectively like you would with a speaker with  an N-channel panner.
>> 
>> [adc~]
>> |     [pan control]
>> |      |
>> [pan~             ]
>> |                   | ....
>> [effect1~]     |
>> |                  [effect2~]
>> |                   |
>> [mixer~          ]
>> |
>> [dac~]
>> 
>> 
>> generating abstraction by editing files as text is pretty simple,
>patching each abstraction to a panner is probably pretty simple with
>your text editor as well.
>> 
>> though, maybe you don't have enough processing power for it?  but..
>maybe you do?
>> 
>> 
>> On Tue, Aug 20, 2019 at 4:09 PM Miller Puckette <msp at ucsd.edu
><mailto:msp at ucsd.edu>> wrote:
>> actually I wrote that before I thought the whole thing out :)
>> 
>> No, if you "tick" a pdlib instance you tick all the patches in it -
>so teh
>> way to get different patches in different orders is to call up a
>separate
>> Pd instance for each of them, and use "adc~" and "dac~" objects to
>get
>> audio in and out - that incurs zero latency (once you've buffered 64
>> samples in the first place).
>> 
>> OR, within one pd instance, in libpd or in Pd, you can use switch~
>objects,
>> switched off, to control each sub-patch.  Send the switch~ objects
>bangs in
>> whatever orders you wish.  In this scenario, tabsend~ and tabreceive~
>would
>> be the simplemt way to pass signals between them.  In libpd you can
>do this
>> zero-latency (just stuff your inpuits into arrays before sending all
>the
>> tick messages and copy the results out afterward).
>> 
>> Within the Pd app, you can do teh same thing but you incur one tick
>extra
>> latency, because copying the autio into the tables has to happen on
>the
>> previous tick form the one on which you get the outputs back.
>> 
>> If you like danger, you can write an external tilde object that, for
>its
>> "dsp" action, sends a message to teh patch that can "tick" the
>switch~
>> objects right in the middle of Pd/s DSP tick.  This is not part of Pd
>> because it could cause major confusion if general-purpose Pd messages
>> got sent around in mid-tick.
>> 
>> cheers
>> Miller
>> 
>> On Tue, Aug 20, 2019 at 11:55:58PM +0200, Roman Haefeli wrote:
>> > On Tue, 2019-08-20 at 12:09 -0700, Miller Puckette wrote:
>> > > I think the way to do this in libpd is to open them all as
>separate
>> > > patches
>> > > within one instance of Pd (so that symbols are shared) and use
>> > > "tabsend"
>> > > and "tabreceive" to route signals to/from them, using shared
>names
>> > > like
>> > > "channel1" as both inputs and outputs so you can rearrange them
>in
>> > > any
>> > > order.
>> > > 
>> > > (Beware of allowing patches to _write_ andy of their output
>channels
>> > > before
>> > > reading all the input channels, if you're re-using the same
>channels
>> > > as 
>> > > inputs and outputs :)
>> > 
>> > Do I understand right: When loading them as separate patches, you
>can
>> > dynamically re-order the signal flow by using
>[tabsend~]/[tabreceive~]
>> > (which you could with abstractions, too) _without_ adding latency?
>> > 
>> > And: When changing the symbol of [tabsend~] or [tabreceive~], is
>the
>> > DSP graph re-calculated?
>> > 
>> > Roman
>> 
>> 
>> 
>> > _______________________________________________
>> > Pd-dev mailing list
>> > Pd-dev at lists.iem.at <mailto:Pd-dev at lists.iem.at>
>> > https://lists.puredata.info/listinfo/pd-dev
><https://lists.puredata.info/listinfo/pd-dev>
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at lists.iem.at <mailto:Pd-dev at lists.iem.at>
>> https://lists.puredata.info/listinfo/pd-dev
><https://lists.puredata.info/listinfo/pd-dev>
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20190820/837a5074/attachment.html>