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:
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).
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.
I may make a simpler input -> id -> output example at some point as the Zirkonium server is admittedly overkill to learn from.
Message: 1Date: Wed, 8 Dec 2021 04:31:03 -0800From: "Scott R. Looney" <scottrlooney@gmail.com>To: pd-list <pd-list@lists.iem.at>Subject: [PD] simple dynamic instancing and connection of abstractionsMessage-ID: <CAAo07Q0CXKijqfpdnz=HeOajc25+pzcF2QeuDm=96q0ubLX-+g@mail.gmail.com>Content-Type: text/plain; charset="utf-8"hi folks, since Alexander was just covering dynamic patching in PD on thepuredata.info site i thought i might inquire about options for dynamicpatching. i've perused a few libraries like iemguts, and a new one calledclj-puredata using Clojure. i sent this to the dev about my use case and ithought i'd post it here for some advice:i want the player/user to be able to dynamically add or remove instrumentsfrom 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 instrumentswith approximately 10 control inlets and 2 signal outlets. i have currently3 unique instruments to load, and planning on more. all of the instrumentshave exactly the same amount of inlets/outlets. all i need to do is loadthem up, hook the I/O up to the slot, and delete them when desired. theinstruments will be abstractions, not subpatches.i would just need a way for the slot to know when an abstraction is loadedor deleted. i can uniquely name each slot if that would work better forthis, though i could probably have a flag, number or string indicating whatstate the slot is in - like 'add', 'remove', 'active' and 'disabled' orwhatever.i have briefly watched a bit of the Youtube video on dynamic patching, butrather than roll my own i thought i'd inquire about libraries or externalsthat could handle it. i think iemguts can handle the querying it seems, butthe docs don't make it clear how objects (abstractions) are instanced anddeleted or connected. i don't need to move anything - just load and connectan abstraction directly under a slot or delete it. any help appreciated!scott