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

[baptiste chatel]

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 <http://twitter.com/danomatika>
>> danomatika.com
>> robotcowboy.com
>>
>>
>>
>>
> --------
> Dan Wilcox
> @danomatika <http://twitter.com/danomatika>
> danomatika.com
> robotcowboy.com
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20200606/f812a619/attachment-0001.html>