Re: [PD] simple dynamic instancing and connection of abstractions

[Dan Wilcox]

[spigot] in abstraction control inlet which also takes control float to 
[switch~]?

In general, I try to only send controls to things which are on, yes, but I have 
not had major issues when that still happens. This probably depends more on 
what the abstractions are doing and, in the case of readsf~ and spatialization 
algorithms, switch~ has a much greater impact.

Don't overly optimize at the beginning. :)

> On Dec 9, 2021, at 10:22 AM, pd-list-requ...@lists.iem.at wrote:
> 
> Message: 2
> Date: Thu, 9 Dec 2021 01:22:11 -0800
> From: "Scott R. Looney"  <mailto:scottrloo...@gmail.com>>
> To: Pd-List mailto:pd-list@lists.iem.at>>
> Subject: Re: [PD] simple dynamic instancing and connection of
>   abstractions
> Message-ID:
><mailto:caao07q2iv1wvbqd6pakbgirwat7xddmfe0kleyar4hvtv3g...@mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
> 
> 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


Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] simple dynamic instancing and connection of abstractions

[Claude Heiland-Allen]

On 09/12/2021 09:22, Scott R. Looney wrote:
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?


There's an issue where messages sent to a switched off vline~ pile up 
and CPU usage goes up:


https://lists.puredata.info/pipermail/pd-list/2017-06/118982.html
https://lists.puredata.info/pipermail/pd-list/2007-06/050999.html


Claude
--
https://mathr.co.uk




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] simple dynamic instancing and connection of abstractions

[Scott R. Looney]

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 
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 
> 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 `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-requ...@lists.iem.at wrote:
>>
>> Message: 1
>> Date: Wed, 8 Dec 2021 04:31:03 -0800
>> From: "Scott R. Looney" 
>> To: pd-list 
>> Subject: [PD] simple dynamic instancing and connection of abstractions
>> Message-ID:
>> 
>> 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 Cloj

Re: [PD] simple dynamic instancing and connection of abstractions

[Scott R. Looney]

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 
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 `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-requ...@lists.iem.at wrote:
>
> Message: 1
> Date: Wed, 8 Dec 2021 04:31:03 -0800
> From: "Scott R. Looney" 
> To: pd-list 
> Subject: [PD] simple dynamic instancing and connection of abstractions
> Message-ID:
> 
> 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 'ad

Re: [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-requ...@lists.iem.at wrote:

Message: 1
Date: Wed, 8 Dec 2021 04:31:03 -0800
From: "Scott R. Looney" 
To: pd-list 
Subject: [PD] simple dynamic instancing and connection of abstractions
Message-ID:

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 
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 -> 

Re: [PD] simple dynamic instancing and connection of abstractions

[Dan Wilcox]

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-requ...@lists.iem.at wrote:
> 
> Message: 1
> Date: Wed, 8 Dec 2021 04:31:03 -0800
> From: "Scott R. Looney"  >
> To: pd-list mailto:pd-list@lists.iem.at>>
> Subject: [PD] simple dynamic instancing and connection of abstractions
> Message-ID:
>>
> 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 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] simple dynamic instancing and connection of abstractions

[João Pais]

I'm not an expert, but here some loose pointers (no pun intended) on 
this topic which might or might not fit into your concept:


- I use only pd's internal messaging, not the iem libraries for it, 
which probably allow for more interesting things.


- have a look at [jmmmp/dacm~] (dynamic) and [jmmmp/dacc~] (not dynamic) 
for very simple concepts on connecting to audio output. The problem with 
internal messages is that you have to know exactly what is the number/ID 
of the object if you want to make connections between objects. I'm not 
sure now if the ID always increases in each session, even if objects 
created before are deleted, or if the ID adjusts to how many objects are 
active - probably the latter.


- I have deleted objects with dynamic messages by simulating mouse 
actions (click and drag, then delete). Not very user-friendly.


- when creating objects, I usually put them into a subpatch dedicated 
for that, which can be reset with [clear(. But won't be possible in your 
case, if you want to delete some objects and keep others.


- instead of using dynamic connections, consider using $x arguments in 
your abstractions for send/receive variables instead. Probably easier to 
manage.


- an option could be for the patch to have all objects inside it (no 
more dynamic patching needed), and make the connections by dynamic 
routing instead.


jmmmp


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


___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-manageme
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list