[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