a "i wish this existed for the greater good of patching signals" object
this is more just needing to spooge out my ideas for an object, whether possible is another matter. but feel i need to share with the developers/public and the like to see if this could be done.
i use signals quite a lot, also things like normal data passing and handling. but the one problem with signal data is that it can get very BIIIIG, even with bpatchers and well thought out patches.
the 2 things that have a leg over the msp of max are [prepend] and [route], these 2 have made patching more elegant and looks good, rather than tons of inputs and outputs on abstractions and [patchers], theyre great, we all love them.
my one sole request that i could have and not ask for any other new externals forever would be a [prepend~] and [route~]. so things like HUGE bpatcher inputs and outputs could be a thing of the past.
think that you could just name your signal with a [prepend~] connect into your bpatcher, then you could [route~] that signal to where it needs to go.
the implications to your patches would free up so much landscape and you can see clearly what is plugged to what. patches would look slicker and should work quicker.
anyhow… phew. thats my spooging finished with. i just need to mop up now.
Like [send~] and [receive~]?
a little bit, but without the send and receive part ;)
Do you mean something like this?
----------begin_max5_patcher---------- 468.3ocyU0saCBBF8Z8ofv0tETo15taOGKMKVk1xhBFkl0eR6y9DDc1Eq0lZ c8BgvGeBmygCebvz.tfukjCAuA9.XXbvzvPERFvPO1.lDrMLNHWkFbU.kcBZ UNCaSBeiHlHTy4niVFRrKkTtvvb5JVPLzB.oLADLWmWZfHbMks5yLRnnLUWW +WQV.G7DUGR1ZiK5p+IZjBF7Ee8h8zF3fxpggL1QSSYi0yAqPnRVg6Cq7FLV wHeWrhUKmfrUgGXZFIkvh.K47kzkh0syaaczkblHmtWwZamBneA4nSE.iloH 8LWYmesNzp.fgM1ZVPhZGfumQkpcKRi8vIMg6BiIm.ddngQTzdj9HMST1BuY cJMt2nzLftlrBxQjdlq3abuUeik9qKQxwurtfco+YZmhjy+m+owUqQ3VkVUz 2plNoSUAMBpBYeTP3EpihtJOb8UL.W21FO7ez9bcI.Ld7JATcN1mR.36nBfZ 8fwT1eexWgIY7ykqb9lrvJdT8hK3WXEQxETVffxYMRp3DBXWmyZZTDg0z.jP iR4EOYpw.Xdqmc8FRnd.IYIgFI8vwD9IDSNmcrbALMc7wzU0IuwESd8zhOhP xsOxDdTwTub3n6.RECNZ9C.2PYti -----------end_max5_patcher-----------
holy shit balls with taco flavoured cat droppings. i never knew, but never thought it would work since they are max objects.
muchos thankos to you-os
…which goes to show that you can do some surprising things with mixing and matching Max and MSP objects. MSP patch cords are just normal Max patch cords passing a special kind of Max message. You can do most normal Max stuff with them.
The classic example is in subpatches: inlet and outlet objects are standard Max objects. You can connect signals, and they basically work. There are some anomalies, though (patch cords don’t always go stripey when you might expect). Using plain-vanilla send/receive objects with MSP signals is another trick that’s pretty well-known.
Caveat: mixing Max and MSP objects can have some unexpected results (depending on what you expect). But they often do work just fine.
thank you for your insight and words of wonder. this just makes me feel like i need to start from the beginning ;)
Yeah , it works, but it’s unsupported. At some point in the future we may change the way Max works behind the scenes and this sort of thing will stop working. If "some point in the future" isn’t on your radar, go for it.
arrrgh, cock beans. please dont do that.
or if you do. could be be replaced by something that is supported?
@Lewis: could you give us an example of what you’re trying to do with prepend and route? I suspect there may be another way of approaching what you’re trying to do that may be more idiomatic MSP.
The point I was trying to make is that you shouldn’t assume Max objects won’t process MSP signals… but (and it’s a very big but) it’s important to understand how the two worlds interact. (Kthozoid’s warnings are part of that ‘understanding’).
And, if you’re doing something that is explicitly "not supported" to take into account that Cycling ’74 may break what you’re doing in the future. Cycling ’74 has been very good about not breaking existing supported (ie documented, "official") behavior. But unsupported stuff can go.
@Andrew: I read (present tense, in the sense of ‘understand’) your comment about my example patch possibly breaking in the future. Would you be able to say a word about why, though? The prepend/route thing is basically only using the fact that MSP objects communicate with the Max world (and each) other by using a very few special reserved messages. It would seem that changing that would mean a gigantic change in the whole interaction between Max and MSP, as well as breaking the inlet/outlet and plain-vanilla send/receive communication. When I wrote the patch, I thought what I was trying was harmless. Or, at worst, ‘mostly harmless’.
to further illustrate the point Peter was making about the MSP-ableness of Max objects
----------begin_max5_patcher---------- 574.3ocyWt0TiBCEG+Y3SQl73Nc6jKb021OG633jBwZTHvTRGq5ne1WHD5h6 B1fUiNSKTNjC8e9ctjvS9dvMUG3MPvEfeC77dx2ySapyfm4ZOXI6PVAqQOLX IuogskCW0eOE+fRauQrUxJFLK2WVsWUvUZmvFqWWIUMhG4Zan0Hi49Qpdnl2 KDHDbo4V063MbohoDUxq1wyT8i.iosdCHnjtSHyg+5ESkciPtcVOB0tfiF4i HWOMp1b6OwQvQBVxJ05B9qchWMAExg4Goy1y99cGVYIGutnp8YLMuHKjWsOK lBtB.2vjaOI7nwZFDYM6nQoZGniPWxLnCuPzg+lhtIn.JxZJfb.Ej76a+u9u 5ve7xGSMnod9TISj.httJLz1rIRLpuRTmTQIqCmGjoNnPz0bbhdSI1SjjuNh rWVyxtCzOgFNgV29YZRErzt9q5+drjr+GVPNbrtnDSnuUUYrCJJ4OlyxlIyA c5LfTcKlfvgiSMMh9riy0rEDjOik1mObRGuV8bgS5BCmAebDJ6grB9KsqHfb VOBR.czpOouEXHecsHLfg3PvXxYrAL3y.L5mGrPH+2cKqkTm8WSqlp86xFlF ltO.5QUkyaTBodwzQioc4N.93XtQjmyki6bTJxqqDRkQBfKmLxsDEQNghRbt hvVvHjSUDxBF88RQcu.iCCaTKjTrSgDwBEQcJivVpH2wntWRwJIQbmjrkRTm IoTKTzBq1Hwoc6vmDg06xAGd7pyTqIVp02aNV6EO6+G.Ut3KtC -----------end_max5_patcher-----------
This is magic ! Thanks.
ooooh, youre just spoiling me now. utterly brilliant
Yeah, this sort of patching can exist because currently the signal compiler works by sending max signal messages around a patcher. However it’s not something which was designed as a feature to be used in programming max patchers.It’s something which people have figured out and are taking advantage of. It breaks in Max 6 with send and receive across patcher hierarchies and it may get broken in other ways down the line.
We do recognise that people like to patch this way. The example of an abstraction which can receive both messages and audio in the same inlet is really compelling. That’s a separate issue from the way the signal compiler works.
there is indeed an issue when using [prepend foo] with signals … connections
of this type are gone when they change … which happens with gate, switch,
forward, or with scripting.
in some of my "multicore" abstractions (such as a gate for up to 10 signals which are
merged into one connection) i am using an additional send as notifer to the [dac~]
in the mother patch, which makes it restart the audio by "0, 1", so whenever you
switch the gate from outputs 1 (destination channels 1-10) to output 2 (destinations
11-20), the symbolic connection is found again because of the restart.
for bigger systems it might even be worth to put the whole multicore DSP into a [poly~],
because restarting the DSP is not exactly the safest thing.
"also [prepend signal] doesn’t support feedback loops. same goes for [send/receive signal] as far as i know."
for the send/receive situation try implementing 2 (instead of the usual 1) vectors delay in the loop . ;)
and for the [prepend foo] situation you can just make a custom abstraction which
takes the connection and breaks it up into multiple signals inside in order to be able to
insert the vector delay. this of course only works when the number of signals in the
"foo" connection is known.
a variation on the theme, using funnel and route.
----------begin_max5_patcher---------- 519.3ocuV1saaBCE.9Z3ovxWmM4eBAXWts2fJ0applbA2F2QrQXiZZqZd1Gb 3mlNQJDUBWDiv14v24iiM9UeO7cl8RKF8CzMHOuW887ftp6vq8dO7Nw9jLgE lFV9RpH4.dUyP5xcJclzAiwZ6LW3R1pzO7mBYhqI1bB86jUn0wPaPWK511+h JEBt4tG+FibTvMkttnSp67Me+5lUSDVahIW1CadgzJ0NgSYzGw1lfM07vCA3 HsM8ncloHivquP4j9KCkkz3ENKCnP5wiHeorjtI5bxxnKUVN42JAmCtgyGtZ 4SUgrKdN4d.HbQUXkHBhhXci07fbOmKaPFiWczudNu2ncV0Kvjn0kZCHB5Xh fF1r1iBuEqKI9P70hcP7w+V9n35RzUBsE8KiNUpsxTzOMYo3AzVvvZa87os7 sBqo3PUIK8jZypdPKxNgvHCKrOsRuY8LXpPF3qn4wWqG1WzYzWJ8eOLql5SJ shidWTqIyonXWbQk7bRl7PUVuTkUsaHAxJHdNkE+hKq6K0ZYFheRWkortyaG K9Xlp4HCzlyLLSaXELtofmRU9n++SGAfV2+G0m0TVjzogtE4n2gMUZcJM7Q4 ilTEHHV+b1pRq3F9fSaO6To4Fk10x.51AeWNYjXSDI5xgDehHQVLjBl.QzkE I5jXJb4YhNFSQKOSrwXJ9KvT0Mu4+O.8VBAu -----------end_max5_patcher-----------