possible to prevent send and recieve to send messages all over the Live set?
I sometimes gets really loud surprises when I accidentally give a receive the same name as a receive on another channel.
Thank you :)
While nobody can protect you from yourself in all cases, I believe if you use names like "send —someName" and "receive —someName", then those messages stay local to the device. The "—" at the beginning is what is important.
Protecting people from themselves is something usually done in more extreme situations than in those invloving max patching, I guess,
but what does — mean? I cant see anything about it in send help or reference
Well, I think with Max you come often enough to this point where something should protect you from yourself – if you do public installations you can get in quite extreme situations – imagine you boost a sound with full level out of Max/MSP – could so some damage.
Well, I think you know that you can name stuff. It might be not too bad to add the project to that and maybe even you initials (like we have jit.- cv.- etc.)
so ‘send meChorusIntensity’ – this way you could be halfway sure you will not run into receives that are not meant for you send :)
I mean, now with M4L we do not only have to think about our own Maxpatch but also about all the M4L devices from all the others … ws that considered ?
Yes, this — comes from nowhere… I’ve read it in an interview
It’s used all over the place in the devices which comes with Max for Live. We should probably but that somewhere else in the documentation though. Thanks for mentioning it.
The — will be replaced automatically by some unique random number, so if you put those before the name of a send/receive/coll/buffer~/table and others, this makes the object only communicate share data within the device.
It’s not really new, it’s the same trick we used in pluggo. The difference between #0 and — is that #0 only works in abstraction/subpatcher.
It’s been in Max for at least 8 years. Yeah we need to document it more. It also works for buffer~ names.
Will only be accessible within the enclosing top level patcher or device
>I mean, now with M4L we do not only have to think about our own Maxpatch but
>also about all the M4L devices from all the others … ws that considered ?
Sure was. The global namespace in Max [of which Max for Live is a subset] is a feature that allows you to share data across a large and complex patch or pair of patches. The — came along in a world in which people ran multiple pluggo devices. We’ll put lots of nice mentions in the help files and refpages, though.
maybe the forward command could help
Is — giving a unique name for each send-recieve step, so if I have 2 similar in a s r "chain" it will give a new unique number?
happy christmas !
if they’re in different devices yes.
on a slightly related note, is there an easy way of making sure parameters generated in the first m4l device in the chain get passed to the second m4l device, but not across channels?
I want to get in oscmessages from a javaApp, to control sounds, depending on the type of message (all similar) it needs to be forwarded to a synth(made with poly~). I have ex. 4 sphereobjects, these can be dragged around, the xyzCoordinates for the 1st instance need to access the first Voice of the SphereSynth, the 2nd the 2nd voice and so on. I just want 1 track for each of the type of objects.
or can his only be achieved using midi connections inbetween the chained m4l devices?
I hope this makes sense enough to be answered
I wish this popped up as a big flashing message the first time I opened M4L, would have saved me a lot of time…… ( or I could have read the documentation more carefully but we all know no one does ;)
"Well, I think with Max you come often enough to this point where something should
protect you from yourself – if you do public installations you can get in quite extreme
situations – imagine you boost a sound with full level out of Max/MSP – could so some
a DC filter followed by *~ 0.89 and clip -0.9 0.9 in all of your installation patches
should fix that.
@Marion: Most has already been answered but I’d still like to focus your attention on the ‘gate‘ object as well.
In a case where you have no other option to use the same send/receive name in several places (for example; to check a certain setting) and you need to be sure that it doesn’t trigger actions all over the place then this could come in very handy.
Of course; in the above scenario the value object is a much better solution. But; I learned about that one after I had already finished the patch where I used the ‘gate’ construction.