While investigating something else, I ran into this patch by user MZED:

cycle~

ezdac~

live.gain~

route

prepend

outlet

inlet

tri~

You can see the original post at https://cycling74.com/forums/many-outputs-for-poly-alternative-to-send-and-receive-for-poly/replies/1#reply-58ed21f543f50b22d4bbab77

This works, but I'm absolutely baffled as to why it works: it routes audio through the non-MSP object [route] and adds indexes on the front of audio signals using [prepend], as if the signal-rate data could be treated as if it were ordinary Max event-rate messages.

Why does this work? And are there more non-tilde objects that can work with signal-rate data?

While investigating something else, I ran into this patch by user MZED:
 
You can see the original post at https://cycling74.com/forums/many

how-on-earth-does-this-even-work

it works with almost all audio objects which let connections pass through.

for example you can bundle signal connections in abstractions and put a gate in between:

[prepend audioL] [prepend audioR]
[outlet]
[gate]
[inlet]
[route audioL audioR]

Thanks, Roman - that's helpful. What confuses me is why - having made the clear distinction between Max objects and MSP objects (~) - there are some objects that 'ignore' it! I'm happy to have learned this new trick (after 15 years of using Max!), but it seems SO counter-intuitive...

i think any object that can accept 'anything' or 'list' messages will work this way(under-the-hood, you can look at the 

, to see how the first inlet to many objects will be a special case including signal objects... involves 'proxies', etc...)...

it is, and it's not necessary to use it this way(although many in the past have used the non-signal 'send' and 'receive' to save a small bit of CPU for routing signals, Cycling74 has noted on these forums when people discover this, that they won't necessarily support this behavior ongoing into the future... but then again, they keep things backwards-compatible for as long as possible so i imagine it will be ok for a long time to come)

long ago, was wondering if i could use 'zl rot' to rotate signals across channels, luckily we now have MC to do this, but you can try stuff like that and you'll see it can get confusing quickly 😅(event messaging doesn't rebuild the dsp chain automatically, either)

if you use this, keep it simple, otherwise, in larger patches, it becomes harder to trace buggy behavior very quickly.

i think any object that can accept 'anything' or 'list' messages will work this way(under-the-hood, you can look at the API, to see how the first inlet to many objects will be a special case including signal objects... involves 'proxies', etc...)...

about a year ago i made a picture with "all possible cases" somewhere here but i cant find it back.

simply put: any connection has an identifier. so if you connect an audio or jitter cable, it will have a name like "u47110815" or whatever.

normal connections emit this name after the patch is loaded, signals connections whenever audio is turned on, and jitter connections with every frame.

[prepend] is able to ignore this identifier but prepend "foo" to it so that the connection name is no longer hidden to you, it is now known.

(i think) the name is now "foo u47110815" and since a list is illegal as name, it will remain a regular (non audio or jitter) connection until the "foo" is removed again, which is what [route] does.

route sees "foo u47110815" as a list of 2 symbols (because that is what it is), but as soon as foo is removed, that identifier is linked to an audio stream again.

(this is the most weird part of all - that [route] can output signal connections)

that is why it works for objects like inlet, gate, select, router to handle such phantom connections, and that is also why you can use the non-audio send/receive with signals and why you can freely combine multiple connections into one.

and otoh objects like [+ 5] or [sprintf %s.jpg] will 

be able to pass the phantom connection, because they attempt to 

an object like [+ ] will see "foo" and either complain that it cant use symbols - or interpret it as "0".

the correct technical explanation of what happens, i just made this up as a guideline for practical use. ;)

given that you are firm with "normal" patching, you can make some quite clever stuff with the "prepend trick".

route sees  "foo u47110815" as a list of 2 symbols (because that is what it is), but as soon as foo is removed, that identifier is linked to an audio stream again.

(this is the most weird part of all - that [route] can output signal connections)

that is why it works for objects like inlet, gate, select, router to handle such phantom connections, and that is also why you can use  the non-audio send/receive with signals and why you can freely combine multiple connections into one.

and otoh objects like [+ 5] or [sprintf %s.jpg] will not be able to pass the phantom connection, because they attempt to alter the content of " foo u47110815". 
an object like [+ ] will see "foo" and either complain that it cant use symbols - or interpret it as "0".

this was not the correct technical explanation of what happens, i just made this up as a guideline for practical use. ;)

given that you are firm with "normal" patching, you can make some quite clever stuff with the "prepend trick".


Thanks for such informative answers! This is really interesting and valuable to know. The trick with [route] etc. seems the most immediately useful, even if it offends the pedantic part of me that doesn't want to accept non-signal objects routing signals ;-)

Many thanks for the information about identifiers. I'm assuming that it's not possible within Max to use message-manipulating objects to strip away the identifier, do some processing, and then put the identifier back? (For instance, if you removed the identifier, used [if] on what was formerly an audio signal, and then added the identifier again to pass the signal back into the audio chain).

Thanks for such informative answers! This is really interesting and valuable to know. The trick with [route] etc. seems the most immediately useful, even if it offends the pedantic part of me that doesn't want to accept non-signal objects routing signals ;-) 

Many thanks for the information about identifiers. I'm assuming that it's not possible within Max to use message-manipulating objects to strip away the identifier, do some processing, and then put the identifier back? (For instance, if you removed the identifier, used [if] on what was formerly an audio signal, and then added the identifier again to pass the signal back into the audio chain). 

As an added bit of information, you may want to look at the [typeroute~] objet, which accepts any (?) kind of input and redistribute them to one of several outlets, according to what their detected nature is.

Yes, that's a very useful object! I use it a lot to reduce the number of inputs needed to subpatches etc. This coupled wtih route can make for a very effective routing system that minimises patch leads and other complexities.

What I was asking about in my previous email was a bit hacky, really, as it would involve stripping and adding parts of a message that we would not normally have access to in conventional Max usage - stuff that's normally under the hood (see Raja's link to the API). I don't think [typeroute~] would help, but then I wouldn't have guessed that [route] could route audio either :-)

haha, the name of the connection IS the connection. if you´d "remove it", the connection is gone. and "if" or "+"doesnt know shite about an audio vector.

it is all about patch design/organisation here, no new funky new processing options available.


haha, the name of the connection IS the connection. if you´d  "remove it", the connection is gone. and "if" or "+"doesnt know shite about an audio vector.

it is all about patch design/organisation here, no new funky new processing options available.


after i did not find it here, i just found it by accident on my ftp. :P

something was wrong in it, i think the "nan" is not coming out of the last outlet or something like that (route doesnt know more about numbers except their gender)

the slashes in the names for audio connections is just my personal style - which i probably copied from either @mzed or @jasch around y2k. if you also use OSC a lot, you might not like the look of it because it looks all the same then)

grafik.png


after i did not find it here, i just found it by accident on my ftp. :P

something was wrong in it, i think the "nan" is not coming out of the last outlet or something like that (route doesnt know more about numbers except their gender)

the slashes in the names for audio connections is just my personal style - which i probably copied from either @mzed or @jasch around y2k. if you also use OSC a lot, you might not like the look of it because it looks all the same then)


Connecting an MSP object to a print object and toggling audio on and off will help explain this. Here's another fun one:

ha, message must be the only object i never tried.

How on earth does this even work?