[PD-dev] dynamic patching - is iemguts the way to go?

[Nick Porcaro]

Thanks Jamie - have you been able to get it to run on iOS?


> On Aug 20, 2019, at 4:57 AM, Jamie Bullock <jamie at jamiebullock.com> wrote:
> 
> 
> This is possibly a bit more heavyweight solution than you’re looking for, but you might want to look into the Integra Framework: https://github.com/BirminghamConservatoire/integra-framework <https://github.com/BirminghamConservatoire/integra-framework>
> 
> It was specifically designed as module management layer to sit between libPd (which it wraps) and an application, e.g. JUCE. An Integra “module” is basically a collection of Pd patches with some metadata wrapped in a ZIP file.
> 
> Happy to answer any questions.
> 
> Cheers,
> 
> Jamie
> 
> 
>> On 20 Aug 2019, at 09:18, Nick Porcaro <nick at ccrma.stanford.edu <mailto:nick at ccrma.stanford.edu>> wrote:
>> 
>> My setup is a JUCE app that uses libpd.  I load a patch that’s an effects chain,
>> with each effect in it’s own abstraction that can be switch~’d to zero so it does not
>> comsume processing when not in use.
>> 
>> The solution I have now is to rename the abstractions to reflect a new processing
>> order and then I reload the patch.  This works, but it’s a hack.  What’d really be
>> slick is if there was api in libpd for inspecting and editng a running patch.
>> 
>> The goal is to minimize glitches on reloading the patch.  We do a similar thing in 
>> GeoShred http://www,moforte.com <http://www,moforte.com/> in the effects chain.  We use Faust for the signal processing
>> in GeoShred.  There we essentially reorder a table of function pointers to accomplish the reordering.
>> 
>> - Nick
>> 
>> 
>>> On Aug 20, 2019, at 3:47 AM, Nick Porcaro <nick at ccrma.Stanford.EDU <mailto:nick at ccrma.Stanford.EDU>> wrote:
>>> 
>>> Hey Folks,
>>> 
>>> It’s been a while since I’ve done any hard core work with Pd but that time has come again,
>>> and I’m glad to be back on the scene!
>>> 
>>> In the project I’m working on I need to be able to reconfigure the processing order
>>> of  DSP objects in a given patch on the fly:
>>> 
>>> For example, from this: 
>>> 
>>> [noise~]
>>> [lop~]
>>> [hip~]
>>> [dac~’
>>> 
>>> To this: 
>>> 
>>> [noise~]
>>> [hip~]
>>> [lop~]
>>> [dac~]
>>> 
>>> Of course this is a trivial example, but it’s not if you wanted to arbitrarily reorder
>>> an effects chain with 30 objects in it.
>>> 
>>> I stumbled across this paper:
>>> 
>>> https://lac.linuxaudio.org/2009/cdm/Saturday/18_Zmoelnig/zmoelnig_pdreflection.pdf <https://lac.linuxaudio.org/2009/cdm/Saturday/18_Zmoelnig/zmoelnig_pdreflection.pdf>
>>> 
>>> and this GitHub repo https://github.com/iem-projects/pd-iemguts <https://github.com/iem-projects/pd-iemguts>
>>> 
>>> and it appears that iemguts might do what I need -
>>> 
>>> What do you all think?  
>>> 
>>> (I posted this to the patch~ section of the Pd forum as well, and there’s some discussion going on).
>>> 
>>> - Nick
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Pd-dev mailing list
>>> Pd-dev at lists.iem.at <mailto:Pd-dev at lists.iem.at>
>>> https://lists.puredata.info/listinfo/pd-dev <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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20190820/8b4c886e/attachment-0001.html>