On Wed, 3 Jan 2007, Cyrille.Damez@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