Peter Reid

Dear Max list, as soon as I start coding for multi channel stuff I find myself getting bored of connecting 8 outputs to eight inputs. I think a kind of pack~ and unpack~ for audio would be amazing. I don't know if this has already been suggested or if it would be fundamentally impossible.

Dear Max list, as soon as I start coding for multi channel stuff I find myself getting bored of connecting 8 outputs to eight inputs.  I think a kind of pack~ and unpack~ for audio would be amazing.  I don't know if this has already been suggested or if it would be fundamentally impossible.

feature-request-multiple-signals-on-one-signal-cable

i think this is not a good idea, because you would need much mor CPU power to en- and decode "list~", if you're just lazy, as me ;-) download the max toolbox, then your problems will disappear with one key!

i think this is not a good idea, because  you would  need much mor CPU power to en- and decode "list~", if you're just lazy, as me ;-) download the max toolbox, then your problems will disappear with one key!

>Dear Max list, as soon as I start coding for multi channel stuff I find myself getting bored of connecting 8 outputs to eight inputs. I think a kind of pack~ and unpack~ for audio would be amazing. I don't know if this has already been suggested or if it would be fundamentally impossible.

Try this, I've found it somewhere on the net. I can't remember where, sorry:

>Dear Max list, as soon as I start coding for multi channel stuff I find myself getting bored of connecting 8 outputs to eight inputs.  I think a kind of pack~ and unpack~ for audio would be amazing.  I don't know if this has already been suggested or if it would be fundamentally impossible.
>

-- 
HomePage: http://www.giri.it
Computer Music Italian Forum http://www.virtual-sound.com


Quote: Maurizio Giri wrote on Wed, 18 April 2007 14:53

----------------------------------------------------

> Try this, I've found it somewhere on the net. I can't remember where, sorry:

Interesting, I didn't know this was possible!

As to the original feature request, I've also been wishing for a multicable system with a pack~ and unpack~ where every object connected to a multicable would automatically be instantiated multiple times to match the amount of signals in the cable. That would rock!

Quote: Maurizio Giri wrote on Wed, 18 April 2007 14:53
----------------------------------------------------

>> Dear Max list, as soon as I start coding for multi channel stuff I find

>> myself getting bored of connecting 8 outputs to eight inputs. I think a kind

>> of pack~ and unpack~ for audio would be amazing. I don't know if this has

>> already been suggested or if it would be fundamentally impossible.

>> Dear Max list, as soon as I start coding for multi channel stuff I find
>> myself getting bored of connecting 8 outputs to eight inputs.  I think a kind
>> of pack~ and unpack~ for audio would be amazing.  I don't know if this has
>> already been suggested or if it would be fundamentally impossible.
>>
>
> Try this, I've found it somewhere on the net. I can't remember where, sorry:
>
Excellent. I had never seen this one!

i think what he means is that only the graphical representation

just like the multicore cables on my analog mixing desk.

it is not a bad idea at all, and could be done by introducing

a new connection class ... "tunnel connection" or "packed core"

the rtl order system might be a little problem here but 

i think what he means is that only the graphical representation
should be "one connection".
just like the multicore cables on my analog mixing desk.

it is not a bad idea at all, and could be done by introducing
a new connection class ... "tunnel connection" or "packed core"
or so. :)

the rtl order system might be a little problem here but 
otherwise its a good idea.

Quote: Roman Thilenius wrote on Wed, 18 April 2007 17:22

> i think what he means is that only the graphical representation

> just like the multicore cables on my analog mixing desk.

> it is not a bad idea at all, and could be done by introducing

> a new connection class ... "tunnel connection" or "packed core"

But simply letting objects make multiple (invisible) instances of themselves. Wouldn't that be great? Shouldn't even be that hard to program, I think. A few checks for unequal cable sizes, but that's about it. Non-signal messages sent equally to all instances.. Kinda the same as poly~ but without the advanced stuff and without the thinking.

> the rtl order system might be a little problem here but 

Quote: Roman Thilenius wrote on Wed, 18 April 2007 17:22
----------------------------------------------------
>
> i think what he means is that only the graphical representation
> should be "one connection".
> just like the multicore cables on my analog mixing desk.
>
> it is not a bad idea at all, and could be done by introducing
> a new connection class ... "tunnel connection" or "packed core"
> or so. :)

>
> the rtl order system might be a little problem here but 
> otherwise its a good idea.
>
>
>
> -110
>
----------------------------------------------------


Wow, that's interesting... didn't know it was possible.

I am very tempted to code a pack~ and unpack~ external.

Does someone care to explain why and how this works?

...and above all, is this gonna be reliable in a performance situation?

It seems to go into the realm of hacking Max/MSP.

> Quote: Roman Thilenius wrote on Wed, 18 April 2007 17:22

> ----------------------------------------------------

> > i think what he means is that only the graphical representation

> > just like the multicore cables on my analog mixing desk.

> > it is not a bad idea at all, and could be done by introducing

> > a new connection class ... "tunnel connection" or "packed core"

> But simply letting objects make multiple (invisible) instances of

> themselves. Wouldn't that be great? Shouldn't even be that hard to

> program, I think. A few checks for unequal cable sizes, but that's

> about it. Non-signal messages sent equally to all instances.. Kinda

> the same as poly~ but without the advanced stuff and without the

> > the rtl order system might be a little problem here but 

> Hard- and software for interactive audiovisual sampling

------------------------------------------------------------

THIS E-MAIL MESSAGE IS FOR THE SOLE USE OF THE INTENDED RECIPIENT AND MAY CONTAIN CONFIDENTIAL AND/OR PRIVILEGED INFORMATION. ANY UNAUTHORIZED REVIEW, USE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, CONTACT THE SENDER BY E-MAIL AT SUPERBIGIO@YAHOO.COM AND DESTROY ALL COPIES OF THE ORIGINAL MESSAGE. WITHOUT PREJUDICE UCC1-207.

Tired of spam? Yahoo! Mail has the best spam protection around 

...and above all, is this gonna be reliable in a performance situation?
It seems to go into the realm of hacking Max/MSP.

>
> Quote: Roman Thilenius wrote on Wed, 18 April 2007 17:22
> ----------------------------------------------------
> >
> > i think what he means is that only the graphical representation
> > should be "one connection".
> > just like the multicore cables on my analog mixing desk.
> >
> > it is not a bad idea at all, and could be done by introducing
> > a new connection class ... "tunnel connection" or "packed core"
> > or so. :)
>
> But simply letting objects make multiple (invisible) instances of
> themselves. Wouldn't that be great? Shouldn't even be that hard to
> program, I think. A few checks for unequal cable sizes, but that's
> about it. Non-signal messages sent equally to all instances.. Kinda
> the same as poly~ but without the advanced stuff and without the
> thinking.
>
> >
> > the rtl order system might be a little problem here but 
> > otherwise its a good idea.
> >
> >
> >
> > -110
> >
> ----------------------------------------------------
>
>
> --
> SmadSteck - http://www.smadsteck.nl
> Hard- and software for interactive audiovisual sampling
>

------------------------------------------------------------
THIS E-MAIL MESSAGE IS FOR THE SOLE USE OF THE INTENDED RECIPIENT AND MAY CONTAIN CONFIDENTIAL AND/OR PRIVILEGED INFORMATION.  ANY UNAUTHORIZED REVIEW, USE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED.  IF YOU ARE NOT THE INTENDED RECIPIENT, CONTACT THE SENDER BY E-MAIL AT SUPERBIGIO@YAHOO.COM AND DESTROY ALL COPIES OF THE ORIGINAL MESSAGE. WITHOUT PREJUDICE UCC1-207.
------------------------------------------------------------

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com


> But simply letting objects make multiple (invisible) instances of 

> themselves. Wouldn't that be great? Shouldn't even be that hard to 

> program, I think. A few checks for unequal cable sizes, but that's 

> about it. Non-signal messages sent equally to all instances.. Kinda 

> the same as poly~ but without the advanced stuff and without the thinking.

I have a love-hate relationship with this way of working. Yes, 

polyphonic objects and connections like that can be wonderfully easy - 

its the same paradigm used in Reaktor, actually, where each module can 

be set to mono/poly, but on the other hand it really needs to backed up 

Mattijs Kneppers skrev:
> But simply letting objects make multiple (invisible) instances of 
> themselves. Wouldn't that be great? Shouldn't even be that hard to 
> program, I think. A few checks for unequal cable sizes, but that's 
> about it. Non-signal messages sent equally to all instances.. Kinda 
> the same as poly~ but without the advanced stuff and without the thinking.
>
I have a love-hate relationship with this way of working. Yes, 
polyphonic objects and connections like that can be wonderfully easy - 
its the same paradigm used in Reaktor, actually, where each module can 
be set to mono/poly, but on the other hand it really needs to backed up 
visually by the application.

Quote: Luigi Castelli wrote on Wed, 18 April 2007 19:21

> Wow, that's interesting... didn't know it was possible.

> I am very tempted to code a pack~ and unpack~ external.

> Does someone care to explain why and how this works?

> ...and above all, is this gonna be reliable in a performance situation?

I don't see how this is any less reliable then using s/r for signals instead of send~/receive~.

It works because MSP causes "signal" messages to be sent through signal outlets whenever you turn audio on. You can connect an MSP outlet to the print object to see this for yourself. MSP then does some magic when a "signal" message arrives at the inlet of an MSP object... somehow the message is transfigurated so that it calls your DSP method (which is an A_CANT method).

The idea is very clever invention; someone deserves a round of applause and it's too bad we don't know who!

Maybe looking at the following variant on the patch will make the technique seem less unreliable. I just replaced the s/r pair with a patch cord and de-encapsulated the two patcher objects.

Quote: Luigi Castelli wrote on Wed, 18 April 2007 19:21
----------------------------------------------------
> Wow, that's interesting... didn't know it was possible.
>
> I am very tempted to code a pack~ and unpack~ external.
>
> Does someone care to explain why and how this works?
>
> ...and above all, is this gonna be reliable in a performance situation?

I don't see how this is any less reliable then using s/r for signals instead of send~/receive~. 

It works because MSP causes "signal" messages to be sent through signal outlets whenever you turn audio on. You can connect an MSP outlet to the print object to see this for yourself. MSP then does some magic when a "signal" message arrives at the inlet of an MSP object... somehow the message is transfigurated so that it calls your DSP method (which is an A_CANT method). 

> It seems to go into the realm of hacking Max/MSP.

for messages you?d only need new type of outlet object

you know how to connect tapin tapout: it looks like a 

the whole thing will of course only work with patces and

not with externals. it will probably also not help to exceed

i also wonder where to use it besides multichannel abstractions

such as b-format ambisonics or suurround 7.1 ?

> I am very tempted to code a pack~ and unpack~ external.
>
> Does someone care to explain why and how this works?
>
> ...and above all, is this gonna be reliable in a performance situation?
> It seems to go into the realm of hacking Max/MSP.
>
> Thanks.
>
> - Luigi

for messages you?d only need new type of outlet object
and a correspoding connection class.

you know how to connect tapin tapout: it looks like a 
a connection - but does something else.

the whole thing will of course only work with patces and
not with externals. it will probably also not help to exceed
the 64-connections limit.

i also wonder where to use it besides multichannel abstractions
such as b-format ambisonics or suurround 7.1 ?


reading peter above just made me finding another drawback.

if you had 2 subpatches where 8 message connection are 

conneted using one special connection will only work

when ALL 8 connections in BOTH patches, the sending one and

the recieving one, are connected to our [multiin] and 

[multiout] objects - otherwise the [multiin] object does

not know which 5 of the incoming 7 messages it should take.

if you had 2 subpatches where 8 message connection are 
conneted using one special connection will only work
when ALL 8 connections in BOTH patches, the sending one and
the recieving one, are connected to our [multiin] and 
[multiout] objects - otherwise the [multiin] object does
not know which 5 of the incoming 7 messages it should take.


yeah, would be neato. I mean, just for its own sake it would be awesome.

yeah, would be neato.  I mean, just for its own sake it would be awesome.


> Dear Max list, as soon as I start coding for multi channel stuff I

> find myself getting bored of connecting 8 outputs to eight inputs. I

> think a kind of pack~ and unpack~ for audio would be amazing. I

> don't know if this has already been suggested or if it would be

It is even possible already, the Jamoma package has an object which does 

it... (Its like one cord that contains multiple audio streams, and its 

done with straight (sort of secret/undocumented) Max messages...)

You can also look at my St.ools there are some multiple sends~ which can 

Peter Reid schrieb:
> Dear Max list, as soon as I start coding for multi channel stuff I
> find myself getting bored of connecting 8 outputs to eight inputs.  I
> think a kind of pack~ and unpack~ for audio would be amazing.  I
> don't know if this has already been suggested or if it would be
> fundamentally impossible.

It is even possible already, the Jamoma package has an object which does 
it... (Its like one cord that contains multiple audio streams, and its 
done with straight (sort of secret/undocumented) Max messages...)
You can also look at my St.ools there are some multiple sends~ which can 
help out in a different way...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


this is the system we developed for multicable signals in Jamoma, and 

used for the various spatialisation modules. In Jamoma the multicable is 

set up to accept up to 32 channels, but that could easily be expanded if 

It is no problem connecting patch cords from several multicable.in 

The one important limitation of the system is that you are not able to 

pass signals into or out of poly~ this way, as poly~ maintains its own 

dsp chain. If you try, Max tend to crash.

I would like to see something similar being added as a supported feature 

to a future version of MaxMSP, with some additions that are beyond what 

I am able to do as a 3rd party developer:

- general support through the SDK for multicable signals in MSP 

externals, so that if a multicable is connected to e.g. a biquad~, the 

same filtering would be applied to all channels

- a slightly different variant of poly~ embedding a patch with only one 

signal inlet and outlet, and then applying the processing to all 

channels connected to the poly~-variant either through parallell patch 

>> Dear Max list, as soon as I start coding for multi channel stuff I find myself getting bored of connecting 8 outputs to eight inputs. I think a kind of pack~ and unpack~ for audio would be amazing. I don't know if this has already been suggested or if it would be fundamentally impossible.

> #P newex 334 22 73 196617 r manysignals;

> #P newex 104 72 73 196617 s manysignals;

> #P message 528 34 67 196617 startwindow;

> #P user number~ 469 72 508 87 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;

> #P user number~ 424 72 463 87 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;

> #P user number~ 379 72 418 87 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;

> #P user number~ 334 72 373 87 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;

> #P newex 50 84 222 196617 route /signal/1 /signal/2 /signal/3 /signal/4;

> #P newobj 334 43 169 196617 p multicable.out;

> #P newex 353 50 92 196617 prepend /signal/4;

> #P newex 252 50 92 196617 prepend /signal/3;

> #P newex 151 50 92 196617 prepend /signal/2;

> #P newex 50 50 92 196617 prepend /signal/1;

this is the system we developed for multicable signals in Jamoma, and 
used for the various spatialisation modules. In Jamoma the multicable is 
set up to accept up to 32 channels, but that could easily be expanded if 
required:

It is no problem connecting patch cords from several multicable.in 
instances to the same multicable.out.

The one important limitation of the system is that you are not able to 
pass signals into or out of poly~ this way, as poly~ maintains its own 
dsp chain. If you try, Max tend to crash.

I would like to see something similar being added as a supported feature 
to a future version of MaxMSP, with some additions that are beyond what 
I am able to do as a 3rd party developer:

- general support through the SDK for multicable signals in MSP 
externals, so that if a multicable is connected to e.g. a biquad~, the 
same filtering would be applied to all channels
- a slightly different variant of poly~ embedding a patch with only one 
signal inlet and outlet, and then applying the processing to all 
channels connected to the poly~-variant either through parallell patch 
chords or a multicable.

Maurizio Giri wrote:
>> Dear Max list, as soon as I start coding for multi channel stuff I find myself getting bored of connecting 8 outputs to eight inputs.  I think a kind of pack~ and unpack~ for audio would be amazing.  I don't know if this has already been suggested or if it would be fundamentally impossible.
>>
>
> Try this, I've found it somewhere on the net. I can't remember where, sorry:
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 334 22 73 196617 r manysignals;
> #P newex 104 72 73 196617 s manysignals;
> #P message 539 52 27 196617 stop;
> #P message 528 34 67 196617 startwindow;
> #P newex 528 70 29 196617 dac~;
> #P user number~ 469 72 508 87 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
> #P user number~ 424 72 463 87 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
> #P user number~ 379 72 418 87 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
> #P user number~ 334 72 373 87 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
> #N vpatcher 154 261 676 499;
> #P outlet 353 129 15 0;
> #P outlet 252 129 15 0;
> #P outlet 151 129 15 0;
> #P outlet 50 129 15 0;
> #P window setfont "Sans Serif" 9.;
> #P newex 50 84 222 196617 route /signal/1 /signal/2 /signal/3 /signal/4;
> #P inlet 50 30 15 0;
> #P connect 0 0 1 0;
> #P connect 1 0 2 0;
> #P connect 1 1 3 0;
> #P connect 1 2 4 0;
> #P connect 1 3 5 0;
> #P pop;
> #P newobj 334 43 169 196617 p multicable.out;
> #N vpatcher 43 74 579 316;
> #P window setfont "Sans Serif" 9.;
> #P newex 353 50 92 196617 prepend /signal/4;
> #P newex 252 50 92 196617 prepend /signal/3;
> #P newex 151 50 92 196617 prepend /signal/2;
> #P newex 50 50 92 196617 prepend /signal/1;
> #P inlet 50 30 15 0;
> #P inlet 151 30 15 0;
> #P inlet 252 30 15 0;
> #P inlet 353 30 15 0;
> #P outlet 50 125 15 0;
> #P connect 4 0 5 0;
> #P connect 8 0 0 0;
> #P connect 7 0 0 0;
> #P connect 6 0 0 0;
> #P connect 5 0 0 0;
> #P connect 3 0 6 0;
> #P connect 2 0 7 0;
> #P connect 1 0 8 0;
> #P pop;
> #P newobj 104 50 145 196617 p multicable.in;
> #P newex 239 24 38 196617 sig~ 8;
> #P newex 194 24 38 196617 sig~ 4;
> #P newex 149 24 38 196617 sig~ 2;
> #P newex 104 24 38 196617 sig~ 1;
> #P connect 11 0 10 0;
> #P connect 12 0 10 0;
> #P connect 5 3 9 0;
> #P connect 5 2 8 0;
> #P connect 5 1 7 0;
> #P connect 5 0 6 0;
> #P connect 14 0 5 0;
> #P connect 3 0 4 3;
> #P connect 2 0 4 2;
> #P connect 1 0 4 1;
> #P connect 4 0 13 0;
> #P connect 0 0 4 0;
> #P window clipboard copycount 15;
>


Well this has been a remarkable thread. Seeing an audio signal connected to a prepend was quite magic. Next time I'm making a surround sound patch it's going to be ten times easier. Why have I never seen this before?! Is it a magic undocumented feature that might disappear one day?

Introducing a new multi signal class to max/msp was kinda what I was imagining originally. Being able to connect a multi cable to a dsp object to have a kind of [vexpr~] type thing happen to all the signals simultaneously is probably the 'killer app' for this idea that I hadn't thought of.

Well this has been a remarkable thread.  Seeing an audio signal connected to a prepend was quite magic. Next time I'm making a surround sound patch it's going to be ten times easier.  Why have I never seen this before?! Is it a magic undocumented feature that might disappear one day? 

Introducing a new multi signal class to max/msp was kinda what I was imagining originally. Being able to connect a multi cable to a dsp object to have a kind of [vexpr~] type thing happen to all the signals simultaneously is probably the 'killer app' for this idea that I hadn't thought of.  

feature request - multiple signals on one signal cable