Functionality of the #0- tag.
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?
The syntax you are using is correct.
It’ll be helpful if you could show us the patch in question.
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
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?
Thanks for the insight Roth. I’ve been using it in top level patchers such as this:
----------begin_max5_patcher---------- 677.3ocyW00jaBBE8Y8WgC80rY.+L125uiNcxPhDWRUvEIezty9eu.pMtahI lsTm7BFtf2bNmKbuWe00ArhejTC79p228bbd00wwXRavoctCnDebcAt1rM.i bfuZKXVyRRxQowrv6KvmJ46ojtkX6JorBhz7ZvVia3LYM82DsMj+7NyUX45m or7kBxZYCZVfTq5EFEqeDmnG8gygd+3j646jc9G0Zswj7WUjFu..+8EnYFfp .+SnTPO7vvklcC9lfhK.5Edy0UOL6eSSpOSSpDjZBShkTNqGWQwoZ9ghizOf sC8o5IkDc2JYm2SLNtYxUjR3EzqE1Uu1Rky2TUmuiBFMECFwgEjQ+VX3YPxf LzevCKyF3.SHztBvlBtBRVh7nffSzNxL5itI4qvBEMjDwRBCupfzOzelvnvK VpUmUXV9EUnfD6pPkj5ZbN476TRd0E0M+6V27WD263h42nTakgwepjCrPZK8 PckIp+0GapGnoQODDblkjCTJ58YSrobX47IRdddA4p4SFLqYCA8girB6ck2f xjWj+KrXU1WTnQv8BfVJt2nJHn4xPB5FoSGLtOXlx3Io2CcI1WjyGtirOaQ1 11HRBGYclyDFExVVhkB5wAK2FY+1MpNPYY7C2nQrjvnl64lf+3ZDa31QRizd wOssjb3M0pU30+LWv2wxtdJkgzMenkjm6innzvIlnHTRelZ1Bnfx93mxXfr1 96oeMemXc2eR2GD3cBzYjZIkYNbzaSJ0s+ldllkQX8S+kQq0YDMvDdw.wXwS zHfito7IBNH3HvSzzAGzCFbRFAdBmtSO5lOefzmfwHOpphdnGm6VeHj9+DOw OTAqEiLV8YPSSZZbU0dhnt0kFfnpGskKzSimYlRYMSMdT0T+dZ29Cb0d6M2+ .buFK8C -----------end_max5_patcher-----------
(load up two instances and you will see my problem)
would simply encapsulating all send and receive objects make them work properly?
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.
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.
if you use the — prefix, the send object will look like —test is that correct?
edit – yes this works with Max4live. Thankyou!
Forums > MaxMSP