possible to prevent send and recieve to send messages all over the Live set?

Dec 11, 2009 at 6:21pm

possible to prevent send and recieve to send messages all over the Live set?

Hi,

I sometimes gets really loud surprises when I accidentally give a receive the same name as a receive on another channel.

Thank you :)

#47164
Dec 11, 2009 at 8:32pm

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.

mz

#169558
Dec 11, 2009 at 9:37pm

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

Thanks

#169559
Dec 12, 2009 at 8:30am

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 ?

best

#169560
Dec 12, 2009 at 10:25am
#169561
Dec 12, 2009 at 4:00pm

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.

#169562
Dec 12, 2009 at 4:09pm

@Emmanuel Jordan:

So I guess this new — feature is new to 5.1? Does it work in standard Max patches as well, giving us something like $0 in a top level Pd patch?

#169563
Dec 12, 2009 at 5:08pm

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.

#169564
Dec 12, 2009 at 5:18pm

It’s been in Max for at least 8 years. Yeah we need to document it more. It also works for buffer~ names.

So

buffer~ —foobarg

Will only be accessible within the enclosing top level patcher or device

-A

#169565
Dec 12, 2009 at 5:20pm

>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.

#169566
Dec 12, 2009 at 6:45pm
#169567
Dec 20, 2009 at 1:05pm

Thanks,

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 !

#169568
Dec 20, 2009 at 5:41pm

if they’re in different devices yes.

#169569
Jul 20, 2010 at 1:22pm

hi,

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

#169570
Nov 15, 2010 at 7:25am

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 ;)

#169571
Nov 15, 2010 at 10:00am

“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.”

a DC filter followed by *~ 0.89 and clip -0.9 0.9 in all of your installation patches
should fix that.

-110

#169572
Nov 15, 2010 at 5:26pm

@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.

#169573

You must be logged in to reply to this topic.