Forums > MaxMSP

Functionality of the #0- tag.

February 15, 2012 | 8:42 pm

Hi guys, I’ve implemented the #0- in a patch. I’ve used it for [send] and [receive] objects as well as [buffer~] [groove] and [waveform~]

So I load up two instances of the patch and they both seem to be getting conflicting data from eachother as if the #0- tags aren’t there.

To confirm I write it like this – [buffer~ #0-sample 2 2]

Am I misunderstanding the functionality of the #0- tag here?



yp
February 15, 2012 | 10:12 pm

The syntax you are using is correct.
It’ll be helpful if you could show us the patch in question.

cheers,
yp


February 16, 2012 | 1:37 am

As far as I know #0 only works the way you want when it is used in an abstraction (not in a top level patch or a subpatcher). The fact that this does not behave like $0 in Pd is the only thing I regular miss about Pd now that Max got new object key commands in Max5.

There is also teh --- prefix that works like #0 in the top level of a Max4Live device. According to Andrew Pask’s post in this thread (http://cycling74.com/forums/topic.php?id=23379) it seems like --- should work in Max as well, but it doesn’t seem to for me in the latest version of Max5 or Max6. I seem to remember when that thread came up a couple years ago trying --- in Max and finding it worked for some things and not others (either send/receive or buffer~) but now it seems to not do anything useful.

Feature Request (if any Cycling74 developers see this): I’ve always been a little confused about why #0 wasn’t designed to work in top level patches, but I imagine it will stay that way since for Pluggo/Max4Live --- was added instead. Did --- ever work for top level patches in Max (not Pluggo or Max4Live)? If so can we have it back and if not can we have it as it seems like a good feature? Also, the thread I linked above seems to imply that #0 should work in subpatchers, but my testing in the latest Max5 and Max6 seem to show that it doesn’t—did this ever work and if it did can this functionality be restored?


February 16, 2012 | 5:34 pm

Thanks for the insight Roth. I’ve been using it in top level patchers such as this:

– Pasted Max Patch, click to expand. –

(load up two instances and you will see my problem)

would simply encapsulating all send and receive objects make them work properly?



yp
February 16, 2012 | 6:00 pm

It’s not enough to just encapsulate them. You’ll have to save the encapsulation as an abstraction (just a normal patch) and then use the abstraction in the top-level patch.


February 16, 2012 | 7:48 pm

Ah I see. My plan was to make a modular live video mixing environment.

The idea was to have each module able to be called up multiple times without conflict.

I guess I"m gonna have to make each module an Abstraction then have the top level patch call them up.


September 30, 2013 | 7:50 am

if you use the — prefix, the send object will look like —test is that correct?

edit – yes this works with Max4live. Thankyou!


Viewing 7 posts - 1 through 7 (of 7 total)