[PD-dev] dynamic patching - is iemguts the way to go?
Joseph Larralde
joseph.larralde at gmail.com
Wed Aug 21 13:38:27 CEST 2019
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 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
>> <mailto: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
>>
>>
>>
>>
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at lists.iem.at <mailto:Pd-dev at lists.iem.at>
>> 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
>
>
> _______________________________________________
> 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/20190821/90ee669f/attachment.html>
More information about the Pd-dev
mailing list