An approach I've been using successfully is to put a [switch~] and some fade-in / fade-out mechanism (with appropriate delays to avoid audio artifacts) in all subpatches that need to be exclusively active. This way you can enable / disable them at will, and you will always only consume the processing power of the currently enabled subpatch. Going into the details, if you want to cross-fade between patches x and y (instead of fading patch x out, then switch it off, then switch patch y on, then fade it in), you might get some cpu peaks if both patches consume a lot. In many cases I don't need to cross-fade (sound continuity is not an issue), so this is a solution I've used in several systems. Hope this is relevant to the discussion and might be of some help.

Joseph

Le 21/08/2019 à 07:10, Alex Norman a écrit :

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@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@gmail.com
<mailto:x37v.alex@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@ucsd.edu
<mailto:msp@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@lists.iem.at <mailto:Pd-dev@lists.iem.at>
    > https://lists.puredata.info/listinfo/pd-dev




    _______________________________________________
    Pd-dev mailing list
    Pd-dev@lists.iem.at <mailto:Pd-dev@lists.iem.at>
    https://lists.puredata.info/listinfo/pd-dev

_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at <mailto:Pd-dev@lists.iem.at>
https://lists.puredata.info/listinfo/pd-dev

---

Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev