feature request - multiple signals on one signal cable
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.
thanks
Peter
Hi,
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!
Gerald
>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:
--
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!
Mattijs
>> 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
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
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
>
----------------------------------------------------
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.
Thanks.
- Luigi
--- Mattijs Kneppers wrote:
>
> 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
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.
Andreas.
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.
> 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.
yeah, would be neato. I mean, just for its own sake it would be awesome.
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
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
Hi,
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.
Best,
Trond
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.
Thanks everyone,
Pete
Just for those who have read this to the end and don't know, Max now has full support for multi-channel cords and processing, just as Peter suggested 17 years ago.
and some still prefer [prepend], mostly because you can mix different data types / connection types with it.