[PD] difference send and using msg with ";"
marius schebella
marius.schebella at gmail.com
Fri Aug 17 17:39:26 CEST 2007
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
>>>>
>>>> _______________________________________________
>>>> PD-list at iem.at mailing list
>>>> UNSUBSCRIBE and account-management ->
>>>> http://lists.puredata.info/listinfo/pd-list
>>>>
>>>
>>> _______________________________________________
>>> PD-list at iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
More information about the Pd-list
mailing list