[PD] [clone] with individual signal inlets/outlets exposed ?

hans w. koch hansw.koch at gmail.com
Sat Jun 6 12:40:08 CEST 2020


+1 for dynamic change in instance numbers

has come up here before…

best
hans

> Am 06.06.2020 um 11:31 schrieb Dan Wilcox <danomatika at gmail.com>:
> 
> You are missing clone individual instance outlets and I’m missing dynamic clone instance numbers.
> 
> I’d like to be able send a message to clone to change the number of instances so the server could save a bit more resources beyond using [switch~]. This is important for performance scaling between working on a project on a Macbook Air then performing with it live on a Mac Pro in the studio. More importantly, we have older projects which use large multi-channel files, so it would be nice to dynamically change the sound file outputs individually up to 32 channels. My only thought for these is to have separate *light* and *heavy* server patches which load different instances of the main abstractions with more or less numbers. Eh, seems clunky too.
> 
> enohp ym morf tnes
> -----------
> Dan Wilcox
> danomatika.com
> robotcowboy.com
> 
> 
> On Jun 6, 2020, at 10:47 AM, baptiste chatel <baptiste.chatel at gmail.com> wrote:
> 
>> That looks like an impressive bit of work !
>> I did something along thoses lines a while ago, while at a smaller scale. In the end, i guess the "clunkiness" was too much for me to deal with.
>> But that was pre intelligent patching era ! That's why i can now think about simply connecting multi-i/os objects (IEM ambisonics plugins with [vstplugin~]) together in a blink, and scale the number of i/o as i need without resorting to workarounds, and more importantly without having to re-engineer what looks like a simple thing (in my head, that is). So now i feel that since we can connect a great number of cable easily, we should be able to multiply objects in the same way.
>> 
>> 
>> 
>> Le ven. 5 juin 2020 à 21:22, Dan Wilcox <danomatika at gmail.com> a écrit :
>> I think you can also be clever about the mixing and the outputs...
>> 
>> In my case, I usually end up with an output abstraction to [dac~]:
>> 
>> [receive~ out$1]
>> |
>> [*~] <--- some gain control input
>> |
>> [dac~ $1]
>> 
>> A use case would be the zirk_id -> zirk_speaker -> zirk_output handling in the ZKM Zirkonium server patches:
>> 
>> https://github.com/ZKM-IMA/ZirkoniumSpatializationServer
>> 
>> (It's currently macOS-only as it includes custom binaries for the spatialization algorithms. I will probably fix this by fall.)
>> 
>> In this case, Zirkonium has the following layout:
>> 
>> 64 live input channels
>> 64 input sound files (with 8 channels)
>> 64 IDs aka objects mapping between input channels (live or sound file) and spatialization algorithms to virtual speakers
>> 64 virtual speakers wich are mapped to outputs
>> 64 output dac~ wrappers
>> 
>> The ID objects & spat algo wrappers use additional clones internally to map each channel to all of the virtual speakers. I imagine a setup like this could work for you. A [zirk_vbap] object, for example, has an internal clone with [zirk_dispatcher]s which handle the connections between the named sends~/receives~. It's a little clunky but it works.
>> 
>> I think a bunch of giant 64-channel output objects would also be clunky and also work, but in a different way. :)
>> 
>>> On Jun 5, 2020, at 8:43 PM, baptiste chatel <baptiste.chatel at gmail.com> wrote:
>>> 
>>> Clever, but you have to do a repetitive error-prone lengthy clicky process either on the send side or on the receive side.
>>> Since in my case i have four 16-tracks sends to a 64 by 16 matrix (3rd order ambisonics monitoring), i mitigated the issue by making an abstraction containing 16 settable sends, taking a float as an argument for the first send number. On the other side, i still had to make 64 unique receives...
>>> 
>>> Le ven. 5 juin 2020 à 20:23, Dan Wilcox <danomatika at gmail.com> a écrit :
>>> Your abstraction can have a named [send~] which you can receive into your matrix. Use the $1 id assigned by clone to differentiate the sends, ie.
>>> 
>>> In abstraction:
>>> 
>>> |
>>> [send~ out$1]
>>> 
>>> For matrix:
>>> 
>>> [receive~ out1]  [receive~ out2] [receive~ out3]
>>> |                |               |
>>> [matrix          -               -          ...]
>>> 
>>> etc
>>> 
>>> In this way, the [clone] itself has no outputs, but you have all of the outputs via [send~]. I use this approach very often.
>>> 
>>>> On Jun 5, 2020, at 7:49 PM, pd-list-request at lists.iem.at wrote:
>>>> 
>>>> Message: 5
>>>> Date: Fri, 5 Jun 2020 19:20:36 +0200
>>>> From: baptiste chatel <baptiste.chatel at gmail.com>
>>>> To: Pd-List <pd-list at lists.iem.at>
>>>> Subject: [PD] [clone] with individual signal inlets/outlets exposed ?
>>>> Message-ID:
>>>> 	<CABrNpLyvGHrRV-+9wDj2p8NnZENQDwEgg-tO7yFHEjw5L1eV6Q at mail.gmail.com>
>>>> Content-Type: text/plain; charset="utf-8"
>>>> 
>>>> Would it be possible to have a [clone] option that allows clones individual
>>>> signal inlets/outlets to be exposed ?
>>>> 
>>>> An example : i need to make 64 of the following patch :
>>>> [receive~ thing-$1]
>>>> |
>>>> [outlet~]
>>>> that should go to a matrix, $1 in [1:64].
>>>> 
>>>> [clone] is useless because it will sum all outputs and expose only one,
>>>> since the cloned patch has one output.
>>>> 
>>>> I could do it with dynamic patching, but as practical as it could be, it is
>>>> pretty convoluted to use for such a simple need.
>>>> 
>>>> 
>>>> Baptiste
>>> 
>>> --------
>>> Dan Wilcox
>>> @danomatika
>>> danomatika.com
>>> robotcowboy.com
>>> 
>>> 
>>> 
>> 
>> --------
>> Dan Wilcox
>> @danomatika
>> danomatika.com
>> robotcowboy.com
>> 
>> 
>> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list






More information about the Pd-list mailing list