[PD] constants

Jonathan Wilkes jancsika at yahoo.com
Thu Feb 16 20:53:19 CET 2012

----- Original Message -----

> From: Martin Peach <martin.peach at sympatico.ca>
> To: Mathieu Bouchard <matju at artengine.ca>
> Cc: Jonathan Wilkes <jancsika at yahoo.com>; "pd-list at iem.at" <pd-list at iem.at>; IOhannes m zmoelnig <zmoelnig at iem.at>
> Sent: Thursday, February 16, 2012 1:58 PM
> Subject: Re: [PD] constants
> On 2012-02-16 13:39, Mathieu Bouchard wrote:
>>  Le 2012-02-15 à 13:11:00, Jonathan Wilkes a écrit :
>>>  Instead of time units, let's take the incoming single-selector 
> "pi"
>>>  and replace it with the float value of pi for any object that 
> doesn't
>>>  have a "pi" method or an "anything" method (but 
> does have a float
>>>  method).  Furthermore, if a class defines a float argument but the
>>>  argument provided isn't a float, then check first if what it 
> received
>>>  was A_SYMBOL 'pi' and if so replace with the float value of pi. 
> Is
>>>  what I wrote above possible to do without causing huge problems to
>>>  performance or creating ambiguities?
>>  Compared to any code that checks whether something is A_FLOAT or not,
>>  and branches accordingly, it makes absolutely no speed difference for
>>  the case of A_FLOAT.
>>  And for the other case... the difference is that if you rely on A_SYMBOL
>>  from being a type completely separate from A_FLOAT, for any reason, then
>>  you're toasted. It's actually the same issue as the auto-convert
>>  discussion from a while ago in which the symbol \123 would be regarded
>>  as float 123 if you look at it this way, or as symbol \123 if you look
>>  at it this way.

But, for example, [route float pi] would still work the same because [route] has an 
anything method defined and takes A_GIMME.  So the problem would be limited 
to users who need to rely on objects that don't have a method for anythings or, 
specifically, don't have a method for "pi", or take float arguments.  And by 'rely' 
I mean they _need_ the object to give them an error in order for the patch to work 
correctly, so that would be typos and runtime errors when you're sending one of 
a subset of anythings to a float processing object or signal object.


> That's why I think it's better to insert filter objects in front of just 
> the appropriate objects, to prevent unintended conversions and not waste time 
> checking to see if something might be convertible for no reason. IMHO pdlua is 
> really good for symbol parsing, as it doesn't use the symbol table, and the 
> script can be edited without needing to compile it, and it's just easier to 
> manipulate strings in lua.
> Martin

More information about the Pd-list mailing list