[PD] [*] vs [*~]

[Mathieu Bouchard]

On Wed, 3 Jan 2007, Cyrille.Damez at laposte.net wrote:

> Le Samedi 30 Décembre 2006 23:27, Mathieu Bouchard a écrit :
>> But how does the type of those cords represent anything else than
>> limitations of the implementation?
> Why should all the limitations of the implementation be hidden ?

If each limitation, individually, is worth hiding. Each limitation that 
is visible is worthy of a separate question.

In the case of the signals vs messages distinction: there isn't much of a 
difference between a signal cord, and a message cord that would carry a 
list of floats, which we'd call a "dsp block", and then there would be 
some kind of hidden [metro] to drive all of this. I say that there isn't 
much of a difference, because none of the existing patches would notice, 
and because the speed difference that exists between messages and signals 
can be (mostly) ironed out.

> Be it under the guise of unexplainable behavior or inefficient patches, 
> the Law of Leaky Abstractions will bite those who venture too far along 
> the road of "We have to hide this because the user really don't want to 
> know."

Yes, yes, but how far is too far? and why?

Abstraction (implementation) leakage hasn't so much stopped anyone from 
using abstractions, does it? And I don't see how my proposal is any more 
outrageously sweep-under-the-carpet than what pd already is.

> Would [bang( -> [dac] produce any sound if pd was automagically 
> converting types ?

most likely nothing: if a signal-inlet isn't already defining bang for a 
specific purpose, it will default to doing the same as an empty list, 
which would be treated as a block of size 0.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada