On Wed, 3 Jan 2007, [EMAIL PROTECTED] 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
_______________________________________________
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
