Lots of nice ideas! I will definitely look at your abstractions for
inspiration.
On 09.12.2021 16:34, Thomas Grill wrote:
Hi Christof,
i didn't know about the initiative, but good that this is on a todo list!
Many of your ideas listed here are implemented in my mc project.
One drawback is definitely that the send~/receive~ based architecture can't
cope with varying block sizes.
There are other problems concerning state preservation of mapped objects upon
changed in the signal graph which i think can't be solved within the
abstraction-based system.
FWIW, after talking to Winfried about Pd-snake a while ago, I worked out a
backwards compatible multichannel solution in my sketch book but never came
around making a proof of concept implementation (yet). AFAICT, it should be
possible to do.
It is possible to also implement a detection whether a signal has been
generated through mc._out (and represents a multichannel transport), or it is a
normal signal.
This can be done using some watermark, but clearly, this will not be 100% safe.
* [mc~ join <nchannels>] join several (single-channel) input signals into a
multi-channel output signal.
i named that mc.pack~
Currently, there is also mc.concat to join two multi-signals.
* [mc~ split <nchannels>] splits a multi-channel input signal into invidual
(single-channel) output signals
there is mc.unpack~, but also mc.index / mc.slice to select channels (for
example interleaved pairs) out of the multi-signal.
* [mc~ sig <nchannels>] creates a multi-channel signal from several float
inlets.
not implemented yet, but easy to do
* [mc~ <obj>] tells an object to operate in multi-channel mode. If the object
doesn't support it (or knows about it), it operates as if the inputs were
single-channel and Pd prints a warning.
mc.map maps (currently only mono) signal objects onto the multi-signal. Other
mappings (most notably stereo) should be possible.
mc.effect maps the mc multi-signal to an abstraction with many signal
inputs/outputs, like vstplugin~
best, Thomas
On 09.12.2021 09:41, Winfried Ritsch wrote:
Am Sonntag, 5. Dezember 2021, 17:22:44 CET schrieb Thomas Grill:
Hi all,
i'd like to make you aware of an abstraction library i have made because of
working more with multi-channel loudspeaker systems lately.
Dealing with many parallel signal connections was cumbersome, so i have come
up with the mc library in order to abstract multi-channel processing. It
consists of pure-Pd abstractions using dynamic object creation and it is
NOT related or compatible with the similarly named Max approach. I hope
there are no similar libraries out yet, i have not come across anything
related.
There was an discussion 2013 on a workshop with Miller on the IEM and a
solution was proposed:
"Pd-snake was an idea 2013 within a workshop with Miller Puckette at the IEM
to extend Pd with multichannel signal connection, which is backwards
compatible, but has not been implemented yet."
The main idea (trick) was to hold an parallel info about a signal which
multichannel or not... to be upward compatible and add some multichannel
natives object to collect and distribute.
In the meantime I did a sime multichannel objects for Ambisonics and other
purposes as abstraction library only, using dynamic patching and used it in
some projects (mainly Auditory Environments) until today:
- https://git.iem.at/pd/acre-amb
mfg winfried
Please check it out at
https://github.com/grrrr/mc <https://github.com/grrrr/mc>
It is definitely not more than alpha quality and currently has only basic
functionality (as much as i have needed so far). But i'd like to put it out
to the public since i don't know how much i will be able to work on it, and
i'd like to hear about your feedback and suggestions for further
functionality.
There are rough edges, for example message boxes popping up when closing
patches with dynamic modifications, but i am not sure to which extent these
effects can be handled on the patcher level.
A technical note:
The connection logic works both on signal and message connections (the
latter over send/receive). In principle message-only would be possible, but
signals seem to be necessary for the correct ordering of the message graph.
Right now the same information is sent on signals (2 integer numbers per
vector: ID and channel count) and messages. There is definitely a lot to
optimize, maybe the signal connections can be dummy, without any
information sent at all. However, the connection logic overhead seems to be
absolutely negligible compared to the DSP load.
Please let me know what you think.
best, Thomas
--
Thomas Grill
http://grrrr.org <http://grrrr.org/>
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
--
Thomas Grill
http://grrrr.org
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
