<div dir="ltr"><div>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.</div><div><br></div><div>[adc~]</div><div>| [pan control]<br></div><div>| |<br></div><div>[pan~ ]</div><div>| | ....<br></div><div>[effect1~] |</div><div>| [effect2~]</div><div>| |<br></div><div>[mixer~ ]</div><div>|</div><div>[dac~]</div><div><br></div><div><br></div><div>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.</div><div><br></div><div>though, maybe you don't have enough processing power for it? but.. maybe you do?<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 20, 2019 at 4:09 PM Miller Puckette <<a href="mailto:msp@ucsd.edu">msp@ucsd.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">actually I wrote that before I thought the whole thing out :)<br>
<br>
No, if you "tick" a pdlib instance you tick all the patches in it - so teh<br>
way to get different patches in different orders is to call up a separate<br>
Pd instance for each of them, and use "adc~" and "dac~" objects to get<br>
audio in and out - that incurs zero latency (once you've buffered 64<br>
samples in the first place).<br>
<br>
OR, within one pd instance, in libpd or in Pd, you can use switch~ objects,<br>
switched off, to control each sub-patch. Send the switch~ objects bangs in<br>
whatever orders you wish. In this scenario, tabsend~ and tabreceive~ would<br>
be the simplemt way to pass signals between them. In libpd you can do this<br>
zero-latency (just stuff your inpuits into arrays before sending all the<br>
tick messages and copy the results out afterward).<br>
<br>
Within the Pd app, you can do teh same thing but you incur one tick extra<br>
latency, because copying the autio into the tables has to happen on the<br>
previous tick form the one on which you get the outputs back.<br>
<br>
If you like danger, you can write an external tilde object that, for its<br>
"dsp" action, sends a message to teh patch that can "tick" the switch~<br>
objects right in the middle of Pd/s DSP tick. This is not part of Pd<br>
because it could cause major confusion if general-purpose Pd messages<br>
got sent around in mid-tick.<br>
<br>
cheers<br>
Miller<br>
<br>
On Tue, Aug 20, 2019 at 11:55:58PM +0200, Roman Haefeli wrote:<br>
> On Tue, 2019-08-20 at 12:09 -0700, Miller Puckette wrote:<br>
> > I think the way to do this in libpd is to open them all as separate<br>
> > patches<br>
> > within one instance of Pd (so that symbols are shared) and use<br>
> > "tabsend"<br>
> > and "tabreceive" to route signals to/from them, using shared names<br>
> > like<br>
> > "channel1" as both inputs and outputs so you can rearrange them in<br>
> > any<br>
> > order.<br>
> > <br>
> > (Beware of allowing patches to _write_ andy of their output channels<br>
> > before<br>
> > reading all the input channels, if you're re-using the same channels<br>
> > as <br>
> > inputs and outputs :)<br>
> <br>
> Do I understand right: When loading them as separate patches, you can<br>
> dynamically re-order the signal flow by using [tabsend~]/[tabreceive~]<br>
> (which you could with abstractions, too) _without_ adding latency?<br>
> <br>
> And: When changing the symbol of [tabsend~] or [tabreceive~], is the<br>
> DSP graph re-calculated?<br>
> <br>
> Roman<br>
<br>
<br>
<br>
> _______________________________________________<br>
> Pd-dev mailing list<br>
> <a href="mailto:Pd-dev@lists.iem.at" target="_blank">Pd-dev@lists.iem.at</a><br>
> <a href="https://lists.puredata.info/listinfo/pd-dev" rel="noreferrer" target="_blank">https://lists.puredata.info/listinfo/pd-dev</a><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Pd-dev mailing list<br>
<a href="mailto:Pd-dev@lists.iem.at" target="_blank">Pd-dev@lists.iem.at</a><br>
<a href="https://lists.puredata.info/listinfo/pd-dev" rel="noreferrer" target="_blank">https://lists.puredata.info/listinfo/pd-dev</a><br>
</blockquote></div>