[PD] simple dynamic instancing and connection of abstractions

[Christof Ressi]

> It is harder if you want true dynamic allocation
I made a PR which allows to set the number cloned instances at runtime 
with a [resize( message: https://github.com/pure-data/pure-data/pull/1069

Without reading the code, I guess it could also simplify Thomas' [mc~].

If you like it, please upvote (not that I think it would make a big 
difference, but at least I win some internet points)

Christof

On 08.12.2021 17:10, Dan Wilcox wrote:
> Howdy Scott,
>
> you can do this without dynamic patching using clone and 
> (send~/receive~) or (throw~/catch~) objects.
>
> I believe I sent someone an example some months ago but the use case 
> was dynamically routing 8 channel file output to dac~ channels randomly:
>
> https://github.com/danomatika/BangYourHead/tree/master/3.Audio/rand8player
>
> The idea is the same though: abstractions loaded in clone objects 
> which route input to output and apply gain and/or pan, etc in between. 
> To enable/disable, I generally use switch~ plus a gain ramp to avoid 
> clicks. When an abstraction is switched off, you save a good amount of 
> CPU so it's worth adding. You then send control messages into clone 
> with the id or all prepended. If you have gain fading and the timing 
> right, you can avoid clicks when configuring connections on the fly.
>
> This approach works well when you know the upper limit of the various 
> components, ie. you have a max of 64 outputs, etc. It is harder if you 
> want true dynamic allocation (although wrapper abstractions help).
>
> If you want a deployed example check out the Zirkonium spatialization 
> server: https://github.com/zkmkarlsruhe/ZirkoniumSpatializationServer
>
> It has multiple layers which can be dynamically configured:
> * inputs: adc~
> * sourcefiles: up to 8 channels each
> * ids: maps input or source file channel to spatialized location (ie. 
> vbap gains per speaker) or direct output channel
> * speaker: virtual speaker, receives spatialized id audio and maps to 
> output
> * outputs: dac~
>
> By default, there are 64 instances for each layer.
>
> There is also a `modularization` branch which abstracts the 
> zirk_server so you can pass the number of layer objects used by clone 
> via creation arguments. This allows for creating more or fewer 
> instances, as needed but not via dynamic patching, ala 
> zirk_server64.pd is just a wrapper for zirk_server.pd with 
> "[zirk_server 64 64 64 64 64]" inside.
>
> https://github.com/zkmkarlsruhe/ZirkoniumSpatializationServer/tree/modularization
>
> I may make a simpler input -> id -> output example at some point as 
> the Zirkonium server is admittedly overkill to learn from.
>
>> On Dec 8, 2021, at 3:16 PM, pd-list-request at lists.iem.at wrote:
>>
>> Message: 1
>> Date: Wed, 8 Dec 2021 04:31:03 -0800
>> From: "Scott R. Looney" <scottrlooney at gmail.com>
>> To: pd-list <pd-list at lists.iem.at>
>> Subject: [PD] simple dynamic instancing and connection of abstractions
>> Message-ID:
>> <CAAo07Q0CXKijqfpdnz=HeOajc25+pzcF2QeuDm=96q0ubLX-+g at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> hi folks, since Alexander was just covering dynamic patching in PD on the
>> puredata.info <http://puredata.info/>site i thought i might inquire 
>> about options for dynamic
>> patching. i've perused a few libraries like iemguts, and a new one called
>> clj-puredata using Clojure. i sent this to the dev about my use case 
>> and i
>> thought i'd post it here for some advice:
>>
>> i want the player/user to be able to dynamically add or remove 
>> instruments
>> from a patch that is already loaded, in a live performance situation.
>>
>> i'm planning to have a master module patch with 8 slots for 8 instruments
>> with approximately 10 control inlets and 2 signal outlets. i have 
>> currently
>> 3 unique instruments to load, and planning on more. all of the 
>> instruments
>> have exactly the same amount of inlets/outlets. all i need to do is load
>> them up, hook the I/O up to the slot, and delete them when desired. the
>> instruments will be abstractions, not subpatches.
>>
>> i would just need a way for the slot to know when an abstraction is 
>> loaded
>> or deleted. i can uniquely name each slot if that would work better for
>> this, though i could probably have a flag, number or string 
>> indicating what
>> state the slot is in - like 'add', 'remove', 'active' and 'disabled' or
>> whatever.
>>
>> i have briefly watched a bit of the Youtube video on dynamic 
>> patching, but
>> rather than roll my own i thought i'd inquire about libraries or 
>> externals
>> that could handle it. i think iemguts can handle the querying it 
>> seems, but
>> the docs don't make it clear how objects (abstractions) are instanced and
>> deleted or connected. i don't need to move anything - just load and 
>> connect
>> an abstraction directly under a slot or delete it. any help appreciated!
>>
>> scott
>
> --------
> Dan Wilcox
> @danomatika <http://twitter.com/danomatika>
> danomatika.com <http://danomatika.com>
> robotcowboy.com <http://robotcowboy.com>
>
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at  mailing list
> UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20211208/49d7dddd/attachment-0001.htm>