Re: [PD] mc – multichannel extension for Pd

[Miller Puckette via Pd-list]

I'm hoping to make this part of a major change that will have to introduce
a new version of t_signal to hold extra info (overlap factor for sub-blocked
windows; separate sample rate and number-of-samples-per-second; at least one
additional dimension for multichannel signals and/or images; some sort of
control by which objects can specify whether they require the same sizes
of input and output signals, )

Not for 0.52 though...

cheers
M

On Thu, Dec 09, 2021 at 06:22:33PM +0100, Winfried Ritsch wrote:
> Hello,
> 
> Yes, thank you Christof for your notices,there are a lot of ideas about 
> PdSnake  ( 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.iem.at_pd_pdsnake_-2D_blob_master_docs_&d=DwICAg&c=-35OiAkTchMrZOngvJPOeA&r=XprZV3Fxus2L1LCw80hE4Q&m=FHyiZea0TQQHi-c8JicPAalOfO_9XMXhmhxsnmN7P0xA3uFhfF4Gg7Kkf4qx1aRs&s=_fc1CYUxloktEjjWR0XonNafTenxp_VB2uPhCQHo7_M&e=
>  
> , which Miller can laugh about sometimes  ;-)
> 
> We started this repository in case someone want to implement it, maybe a 
> place 
> also for ideas  ideas in there...:
> 
> - 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.iem.at_pd_pdsnake&d=DwICAg&c=-35OiAkTchMrZOngvJPOeA&r=XprZV3Fxus2L1LCw80hE4Q&m=FHyiZea0TQQHi-c8JicPAalOfO_9XMXhmhxsnmN7P0xA3uFhfF4Gg7Kkf4qx1aRs&s=BIBlqd_xWxkn1fV7w3udY6bIkmfCCT27GUvTl1fZBqk&e=
>  
> 
> mfg winfried
> 
> 
> Am Donnerstag, 9. Dezember 2021, 16:44:33 CET schrieb Christof Ressi:
> > 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 ] 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 ] 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 ] creates a multi-channel signal from several float
> > >> inlets.> 
> > > not implemented yet, but easy to do
> > > 
> > >> * [mc~ ] 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 an

Re: [PD] mc – multichannel extension for Pd

[Winfried Ritsch]

Hello,

Yes, thank you Christof for your notices,there are a lot of ideas about 
PdSnake  ( https://git.iem.at/pd/pdsnake/-/blob/master/docs/
, which Miller can laugh about sometimes  ;-)

We started this repository in case someone want to implement it, maybe a place 
also for ideas  ideas in there...:

- https://git.iem.at/pd/pdsnake

mfg winfried


Am Donnerstag, 9. Dezember 2021, 16:44:33 CET schrieb Christof Ressi:
> 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 ] 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 ] 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 ] creates a multi-channel signal from several float
> >> inlets.> 
> > not implemented yet, but easy to do
> > 
> >> * [mc~ ] 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/g/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 con

Re: [PD] mc – multichannel extension for Pd

[Christof Ressi]

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 ] 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 ] 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 ] creates a multi-channel signal from several float 
inlets.


not implemented yet, but easy to do


* [mc~ ] 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/g/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://g.org 



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

--
Thomas Grill
http://g.org






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

Re: [PD] mc – multichannel extension for Pd

[Thomas Grill]

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 ] 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 ] 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 ] creates a multi-channel signal from several float 
> inlets.
> 

not implemented yet, but easy to do

> * [mc~ ] 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/g/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://g.org 
>> 
> 
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list

--
Thomas Grill
http://g

Re: [PD] mc – multichannel extension for Pd

[Christof Ressi]

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.


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.


Some things I wrote down:

* [mc~ join ] join several (single-channel) input signals 
into a multi-channel output signal.


* [mc~ split ] splits a multi-channel input signal into 
invidual (single-channel) output signals


* [mc~ sig ] creates a multi-channel signal from several 
float inlets.


* [mc~ ] 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.


* [clone] accepts multi-channel inputs and forwards them to the 
abstractions.


* [clone -m], on the other hand, takes several multi-channel inputs and 
distributes them channel-wise over abstraction instances, i.e. instead 
of passing the same input to every abstraction, abstraction1 only gets 
the first channel of each input, abstraction2 only the second channel of 
each input, etc. The resulting outputs are not summed but rather joined 
into multi-channel signals. If there are no signal inputs, [clone -m] 
effectively *generates* multi-channel signals. The number of cloned 
instances can be changed dynamically.


* only few objects, like [mc~ join] or [clone -m], require the user to 
explicitly specify the number of channels, most other objects in the 
chain would simply infer the number of output channels from the input 
channels in the "dsp" method. In practice, this means you can just 
change the creation argument of [mc~ join] or [mc~ sig] and all the 
following objects will update automatically. Most existing objects would 
simply have as many output channels as input channels, but new 
(external) objects can follow their own rules. One example would be a 
matrix multiplication object.


* Actually, [mc~ ] wouldn't even be necessary, as we can simply 
infer from the inputs if the object should operate in multi-channel 
mode. But I can imagine that in this case explicit might be better than 
implicit.


* in "t_signal", multiple channels are contained in a single buffer 
consecutively (non-interleaved). We can simply add a new "s_channels" 
member to the "t_signal" struct. Objects that are not aware of 
multi-channel-processing would just ignore the "s_channels" member and 
operate on a single channel. One problem arises if a multi-channel-aware 
external is loaded into an older Pd version which doesn't have the 
"s_channel" member yet. There a several ways to avoid this situation. 
One easy solution is to require the external to call a new API function, 
so it would simply refuse to load in older Pd versions.


Maybe I have some time next year to come up with a PoC. Or someone else 
wants to pick up those ideas.


Christof


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/g/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 exte

Re: [PD] mc – multichannel extension for Pd

[Winfried Ritsch]

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/g/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://g.org 


-- 
- ao.Univ.Prof. DI Winfried Ritsch 
- rit...@iem.at - http://iem.at/ritsch
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171 




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

Re: [PD] mc – multichannel extension for Pd

[Thomas Grill]

Hi Roman,
here is a short description about the mechanics:

The key are the mc._in and mc._out abstractions which are present in each 
mc-object.

The source object sends its signal data though send~ objects with the naming 
convention $0-mc-0 $0-mc-n, where n equals channel-count-1.
The object informs a sink object by use of a simple two float message 
[$0-of-source channel-count( .
This message flows through a signal connection which has the two floats at the 
beginning of each signal block (implemented using tabsend~ and tabreceive~).
The sink in turn uses the $0-of-source to dynamically create or set receive~s 
to connect to the source send~s.

The signal connection is doubled by a send/receive message connection in order 
to also transmit the data in the message domain.
Otherwise there would be warnings about missing send~/receive~ connection when 
the graph changes.

Currently, i am working on making the dynamic generation process modular for 
the various functionalities needed (see the mc.map object for starters).
When this overhaul has been completed, the general mechanics should be better 
understandable. I admit that the whole thing is pretty involved.

best, Thomas


> Am 08.12.2021 um 16:34 schrieb Roman Haefeli :
> 
> Signierter PGP-Teil
> Hey Thomas
> 
> On Sun, 2021-12-05 at 17:22 +0100, Thomas Grill wrote:
>> 
>> i'd like to make you aware of an abstraction library i have made
>> because of working more with multi-channel loudspeaker systems
>> lately.
> 
> Quite a few times I thought it would practical to pack many audio
> cables into one. It wouldn't have occurred to me how to actually
> implement it. This is really interesting. I had only a close look at it
> and, frankly, I failed to understand how it works. I'll check this out
> to some more detail for sure.
> 
> Roman
> 
> 
> 
> 

--
Thomas Grill
http://g.org




signature.asc
Description: Message signed with OpenPGP
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] mc – multichannel extension for Pd

[Roman Haefeli]

On Wed, 2021-12-08 at 16:34 +0100, Roman Haefeli wrote:
>  I had only a close look at it

I meant: I had only a quick glance at it [...]


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] mc – multichannel extension for Pd

[Roman Haefeli]

Hey Thomas

On Sun, 2021-12-05 at 17:22 +0100, Thomas Grill wrote:
> 
> i'd like to make you aware of an abstraction library i have made
> because of working more with multi-channel loudspeaker systems
> lately.

Quite a few times I thought it would practical to pack many audio
cables into one. It wouldn't have occurred to me how to actually
implement it. This is really interesting. I had only a close look at it
and, frankly, I failed to understand how it works. I'll check this out
to some more detail for sure.

Roman




signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list