okay, pursuant to this idea, i'm starting into working on this design overhaul and i'm considering routing the non-audio signals to all of the instruments in a slot at once. since there will only ever be audio coming from one instrument in a slot, there certainly won't be audio conflicts, but i am a bit concerned at data going everywhere and if that creates a significant amount of overhead load for PD.
so, if i use switch~ to turn off an inactive instrument's audio output, does the control data matter if it ends up in a 'dead letter office' so to speak? or is it better to route control signals away from inactive instruments as well? for this example assume the MIDI note triggering only routes to the active instrument as well, so no audio is even triggered.
scott
On Wed, Dec 8, 2021 at 12:21 PM Scott R. Looney scottrlooney@gmail.com wrote:
hmm - well i'm not against the concept of NOT using dynamic patching and doing [clone] instead, or something else, but to my mind it would then require a mega object with all of the instruments to be present at every slot and then to switch off all the rest. this means a much more complex switching mechanism and i've not had the best luck getting switch~ to really cooperate. currently there looks like 4 unique instruments so it's not really that 'mega' at the moment - my concern is that i somehow won't be able manage the DSP or possibly that the routing itself might add some overhead. i have best results keeping the load under 30%. once it goes over 60 i start getting dropouts and glitches.
thanks for the advice folks! i'll try the static switched route and see what happens.
best, scott
On Wed, Dec 8, 2021 at 8:54 AM Christof Ressi info@christofressi.com wrote:
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
modularizationbranch 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/modulariz...
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@lists.iem.at wrote:
Message: 1 Date: Wed, 8 Dec 2021 04:31:03 -0800 From: "Scott R. Looney" scottrlooney@gmail.com To: pd-list pd-list@lists.iem.at Subject: [PD] simple dynamic instancing and connection of abstractions Message-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 the 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 robotcowboy.com
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list