[PD] [*] vs [*~]
Mathieu Bouchard
matju at artengine.ca
Thu Jan 4 21:54:15 CET 2007
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
More information about the Pd-list
mailing list