patrice, I am not sure if we are talking about the same thing... a dollar sign in an object will get replaced by the argument you give to the patch on creation. lets say you have a patch "volume" and it multiplies input by $1
[inlet~] | [*~ $1] | [outlet~] then you can create that abstraction in your patch like [volume 0.7] and $1 is replaced by 0.7. but in a [message $1( the $1 is not replaced by 0.7 but by whatever you send to its inlet. that is really not the same behaviour in my opinion. marius. Patrice Colet wrote: > Hello, > indeed, in message boxes, if the variable after the dollar sign doesn't > match a number corresponding to the number of arguments given at it's > input, it outputs directly the variable, if the variable is a number, it > ignores the dollarsign, if the number is greater than the number of > variables only, it outputs an error message. > > It just doesn't make easy to find errors. > > In object boxes such attempts would result into different error > messages like "$2: argument number out of range", or "$-1: bad type", > that might help for debugging a patch. > > For me, dollar sign has exactly the same behavior in objects and > messages, it's just objects and messages that don't do the same things, > and I would think that $0 would decrease performances reached by message > boxes if it would have to give the patch ID instead of ignoring dollar > sign like it actually does. > > > marius schebella a écrit : >> Hi, >> the problem is, that $1 (and $<) has a different behaviour in objects >> and in messages. >> I think that was taken as reason, not to make $0 having the same >> behaviour in messages, but giving it no behaviour at all and also no >> alternative solution. >> but maybe there is another motivation I have not taken into >> consideration. and I am also not able to implement any of the >> discussed possibilities. I am just trying to find a lobby for either >> solution. >> >> marius >> >> Patrice Colet wrote: >>> You know what, all along the hundreds of lines I've been reading in >>> the list about $0, I don't get a single consistent reason why it >>> hasn't the same behavior in object and message boxes. >>> >>> Matteo Sisti Sette a écrit : >>>> Mathieu Bouchard wrote >>>> (and a few other people wrote something similar): >>>> >>>>> $0 in objectboxes is already inconsistent with $1,$2,$3,... in >>>>> objectboxes, so, it's not clear that $0 in messagebox has to be >>>>> consistent >>>>> with anything at all. >>>> >>>> >>>> $0 is inconsistent with $1, $2 etc strictly speaking, but you may >>>> think of $0 as of an "implicit creation argument". The name $0 has >>>> the same scope of the names $1,$2, in the sense that: in any two >>>> places where two $0's would have the same value, two $1's would have >>>> the same value. Both are values that are generated at the time of >>>> creating the object (semantically I mean, I don't know if it is so >>>> in implementation and it is irrelevant) and don't change later. >>>> So it is not *so* inconsistent. >>>> >>>> Making $0 mean in a message the same it means in an object box, >>>> would make it *a lot* more inconsistent with $1,$2 in messages than >>>> $0 is with $1,$2 in object boxes. >>>> $1,$2... in messages are evaluated at the time the message box >>>> receives its input and generates its output; they are arguments of >>>> the message it receives. The "natural" object-counterpart of $0 >>>> would be a number that is unique to that particular message event >>>> (not message box) or message tree, though that would be of little or >>>> no use..... or wouldn't it? >>>> >>>> Also, consider the following goal: >>>> (*) give direct access to (implicit and explicit) creation arguments >>>> ($n) of the patch within a message >>>> >>>> Making $0 mean the same in a message box than outside it would >>>> address goal (*) only for the particular case of $0 and not for n>0, >>>> and I personally think this isn't an elegant approach. >>>> Also, any future attempt to address (*) for n>0, would probably >>>> result more difficult or have to be more inconsistend if the $0 case >>>> has been treated this way. >>>> >>>> >>>> I am personally strongly against implementing $0 in messages meaning >>>> the same as $0 outside them. It would introduce further >>>> inconsistence. If there actually is some inconsistence now, it is >>>> not a good reason imho to deliberately introduce more inconsistence. >>>> >>>> >>>> -- >>>> Email.it, the professional e-mail, gratis per te: >>>> http://www.email.it/f >>>> >>>> Sponsor: >>>> >>>> Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6905&d=17-8 >>>> >>>> _______________________________________________ >>>> [email protected] mailing list >>>> UNSUBSCRIBE and account-management -> >>>> http://lists.puredata.info/listinfo/pd-list >>>> >>> >>> _______________________________________________ >>> [email protected] mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >> >> > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
