<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Miller, et. al:<br class=""><br class=""><br class="">I think I see the problem, this code would appear to tick ALL the patches<br class="">in the pd instance:<br class=""><br class=""><font face="Courier New" class="">for (each buffer from the audio callback) {<br class=""> for (a smaller buffer that’s the pd block size (eg 64)) {<br class=""> pd->processFloat (oneTick, smallBufferIn, smallBufferOut);<br class=""> }<br class="">}<br class=""><br class=""></font><br class="">So maybe it should be like this:<br class=""><br class=""><br class=""><font face="Courier New" class="">for (each buffer from the audio callback) {<br class=""> for (a smaller buffer that’s the pd block size (eg 64)) {<br class=""> // Do something here to disable the patches that are not active<br class=""> // eg :</font><div class=""><font face="Courier New" class=""> for (patches that are not this one) {<br class=""></font><div class=""><font face="Courier New" class=""> pd->sendFloat(“/patchName/enable",0);</font></div><div class=""><font face="Courier New" class=""> }<br class=""> pd->processFloat (oneTick, smallBufferIn, smallBufferOut);<br class=""> }<br class="">}<br class=""></font><br class="">The code above is a member function of a C++ class that encapsulates a patch.<br class="">I just realized as I was falling asleep for the night that this line is NOT specific<br class="">to any patch!<br class=""><br class=""> pd->processFloat (oneTick, smallBufferIn, smallBufferOut);<br class=""><br class="">I’ll try something first thing tomorrow and I’ll let you all know what happens.</div><div class=""><br class=""></div><div class=""><br class="">- Nick<br class=""><br class=""><blockquote type="cite" class="">On Sep 12, 2019, at 4:56 AM, Nick Porcaro <<a href="mailto:nick@ccrma.Stanford.EDU" class="">nick@ccrma.Stanford.EDU</a>> wrote:<br class=""><br class="">Hi Miller-<br class=""><br class=""><blockquote type="cite" class="">On Aug 20, 2019, at 7:08 PM, Miller Puckette <<a href="mailto:msp@ucsd.edu" class="">msp@ucsd.edu</a>> wrote:<br class=""><br class="">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=""></blockquote><br class="">I tried this two ways: <br class=""><br class="">- Create separate Pd instances for each patch wrapped in adc~ and dac~<br class=""><br class="">- Use a single Pd instance with multiple patches, with each patch wrapped in adc~ and dac~<br class=""><br class="">Then I have a simple JUCE app (based on the sampler example) that drives<br class="">these pd patches.<br class=""><br class="">There is no problem with doing switch~ and such, but I am <br class="">getting distortion that seems like clipping in both cases (one pd instance with many patches<br class="">or multiple pd instances with one patch)<br class=""><br class="">To be more clear these wrapper patches are like:<br class=""><br class="">Patch 1: [adc~] -> [lop~ 200] -> [dac~]<br class="">Patch 2: [adc~] -> [hip~ 200] -> [dac~]<br class=""><br class="">These wrapper patches also have a loadbang to pd dsp 1;<br class=""><br class="">Then the code that calls these patches does something like this calling libpd:<br class=""><br class="">for (each buffer from the audio callback) {<br class=""> for (a smaller buffer that’s the pd block size (eg 64)) {<br class=""> pd->processFloat (oneTick, smallBufferIn, smallBufferOut);<br class=""> }<br class="">}<br class=""><br class="">I tried scaling the input and output to these wrapper patches after the adc~ and before the dac~<br class="">and that does not solve the distortion/clipping problem either.<br class=""><br class="">There are a couple of more things I can try:<br class=""><br class=""> - make the wrapper patches even simpler, just scaling instead of the filters.<br class=""> - dump the samples to a file and maybe that will shed some light on the problem.<br class=""> - making a much simpler example program that I can share will you all.<br class=""><br class="">I have libpd and pd source directly compiled into my example<br class=""><br class="">Any other ideas would be greatly appreciated!<br class=""><br class=""><br class=""><blockquote type="cite" 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=""></blockquote><br class="">This approach works well, but the problem is I can’t insert non-Pd signal processing<br class="">anywhere I’d like in the Pd patch so that’s why I went with the first approach.<br class=""><br class=""><blockquote type="cite" 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=""><blockquote type="cite" class="">On Tue, 2019-08-20 at 12:09 -0700, Miller Puckette wrote:<br class=""><blockquote type="cite" 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=""></blockquote><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=""></blockquote><br class=""><br class=""><br class=""><blockquote type="cite" class="">_______________________________________________<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="">https://lists.puredata.info/listinfo/pd-dev<br class=""></blockquote><br class=""><br class=""><br class=""><br class="">_______________________________________________<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="">https://lists.puredata.info/listinfo/pd-dev<br class=""><br class=""><br class=""></blockquote><br class=""><br class=""><br class=""><br class=""></blockquote><br class=""></div></div></body></html>