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

Jamie Bullock jamie at jamiebullock.com
Wed Aug 21 16:01:53 CEST 2019



> On 20 Aug 2019, at 18:09, Nick Porcaro <nick at ccrma.stanford.edu> wrote:
> 
> Thanks Jamie - have you been able to get it to run on iOS?
> 


iOS isn’t currently supported (only Windows and macOS). Other platforms are theoretically possible but there is no build system set up for them. In the case of iOS, it’s more a question of building the dependencies for iOS.

The benefits of using libIntegra over lower-level options are state saving and module introspection. You can automate the building of UI, for example by querying it for module attributes etc

Cheers,

Jamie

> 
>> On Aug 20, 2019, at 4:57 AM, Jamie Bullock <jamie at jamiebullock.com <mailto: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 <https://lists.puredata.info/listinfo/pd-dev>
>> 
> 

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


More information about the Pd-dev mailing list