[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