<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hey x_nor,<div class=""><br class=""></div><div class="">The problem with this approach is that you still have active signal processing going in</div><div class="">each effect even if they are panned to zero (I assume) and you couldn’t change the running</div><div class="">order of effect1 and effect2.</div><div class=""><br class=""></div><div class="">Thanks for thinking on it though. I’m going to study Miller’s responses and let you all know it goes-</div><div class=""><br class=""></div><div class="">- Nick<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Aug 20, 2019, at 7:26 PM, x nor <<a href="mailto:x37v.alex@gmail.com" class="">x37v.alex@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">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 class=""><br class=""></div><div class="">[adc~]</div><div class="">| [pan control]<br class=""></div><div class="">| |<br class=""></div><div class="">[pan~ ]</div><div class="">| | ....<br class=""></div><div class="">[effect1~] |</div><div class="">| [effect2~]</div><div class="">| |<br class=""></div><div class="">[mixer~ ]</div><div class="">|</div><div class="">[dac~]</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">though, maybe you don't have enough processing power for it? but.. maybe you do?<br class=""></div><div class=""><br class=""></div></div><br class=""><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" class="">msp@ucsd.edu</a>> wrote:<br class=""></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 class="">
<br class="">
No, if you "tick" a pdlib instance you tick all the patches in it - so teh<br class="">
way to get different patches in different orders is to call up a separate<br class="">
Pd instance for each of them, and use "adc~" and "dac~" objects to get<br class="">
audio in and out - that incurs zero latency (once you've buffered 64<br class="">
samples in the first place).<br class="">
<br class="">
OR, within one pd instance, in libpd or in Pd, you can use switch~ objects,<br class="">
switched off, to control each sub-patch. Send the switch~ objects bangs in<br class="">
whatever orders you wish. In this scenario, tabsend~ and tabreceive~ would<br class="">
be the simplemt way to pass signals between them. In libpd you can do this<br class="">
zero-latency (just stuff your inpuits into arrays before sending all the<br class="">
tick messages and copy the results out afterward).<br class="">
<br class="">
Within the Pd app, you can do teh same thing but you incur one tick extra<br class="">
latency, because copying the autio into the tables has to happen on the<br class="">
previous tick form the one on which you get the outputs back.<br class="">
<br class="">
If you like danger, you can write an external tilde object that, for its<br class="">
"dsp" action, sends a message to teh patch that can "tick" the switch~<br class="">
objects right in the middle of Pd/s DSP tick. This is not part of Pd<br class="">
because it could cause major confusion if general-purpose Pd messages<br class="">
got sent around in mid-tick.<br class="">
<br class="">
cheers<br class="">
Miller<br class="">
<br class="">
On Tue, Aug 20, 2019 at 11:55:58PM +0200, Roman Haefeli wrote:<br class="">
> On Tue, 2019-08-20 at 12:09 -0700, Miller Puckette wrote:<br class="">
> > I think the way to do this in libpd is to open them all as separate<br class="">
> > patches<br class="">
> > within one instance of Pd (so that symbols are shared) and use<br class="">
> > "tabsend"<br class="">
> > and "tabreceive" to route signals to/from them, using shared names<br class="">
> > like<br class="">
> > "channel1" as both inputs and outputs so you can rearrange them in<br class="">
> > any<br class="">
> > order.<br class="">
> > <br class="">
> > (Beware of allowing patches to _write_ andy of their output channels<br class="">
> > before<br class="">
> > reading all the input channels, if you're re-using the same channels<br class="">
> > as <br class="">
> > inputs and outputs :)<br class="">
> <br class="">
> Do I understand right: When loading them as separate patches, you can<br class="">
> dynamically re-order the signal flow by using [tabsend~]/[tabreceive~]<br class="">
> (which you could with abstractions, too) _without_ adding latency?<br class="">
> <br class="">
> And: When changing the symbol of [tabsend~] or [tabreceive~], is the<br class="">
> DSP graph re-calculated?<br class="">
> <br class="">
> Roman<br class="">
<br class="">
<br class="">
<br class="">
> _______________________________________________<br class="">
> Pd-dev mailing list<br class="">
> <a href="mailto:Pd-dev@lists.iem.at" target="_blank" class="">Pd-dev@lists.iem.at</a><br class="">
> <a href="https://lists.puredata.info/listinfo/pd-dev" rel="noreferrer" target="_blank" class="">https://lists.puredata.info/listinfo/pd-dev</a><br class="">
<br class="">
<br class="">
<br class="">
<br class="">
_______________________________________________<br class="">
Pd-dev mailing list<br class="">
<a href="mailto:Pd-dev@lists.iem.at" target="_blank" class="">Pd-dev@lists.iem.at</a><br class="">
<a href="https://lists.puredata.info/listinfo/pd-dev" rel="noreferrer" target="_blank" class="">https://lists.puredata.info/listinfo/pd-dev</a><br class="">
</blockquote></div>
_______________________________________________<br class="">Pd-dev mailing list<br class=""><a href="mailto:Pd-dev@lists.iem.at" class="">Pd-dev@lists.iem.at</a><br class=""><a href="https://lists.puredata.info/listinfo/pd-dev" class="">https://lists.puredata.info/listinfo/pd-dev</a><br class=""></div></blockquote></div><br class=""></div></div></body></html>