On Sat, 30 Dec 2006, David NG McCallum wrote:
If we're to think about the metaphor of dataflow languages, which is essentially modelled after electronics and circuits (and I'm thinking about analogue circuits, although I'm sure a similar argument could be made for digital), then there should be no difference between "control" and "audio," because they're the exact same thing.
If pd's message system was designed while thinking of any kind of hardware, it must've been MIDI hardware (nevermind "undo the MIDI revolution"...)
while analogue circuits can transmit float-like messages by sending appropriate events (either in the data wire or as an auxiliary wire), they lack the dynamic range and the precision of the floats or even the integers. Fixing that requires a digital protocol, which is also what is required for supporting symbols. G-Pointers (at the heart of so-called Data Structures) require more than just a digital protocol, they require a common digital memory accessible by any object that is supposed to work on them.
The main differences between messages and signals, is that messages have a very variable rate, an execution order, and more flexible feedback than signals. Also, the variable rate can convey meaning: there's a big difference between getting no message, and getting an empty (bang) message.
Dataflow as a concept is not limited to a metaphor of electronic circuits, though lots of dataflow systems limit themselves like that. IMHO, dataflow is about outlets and inlets being connected and something (possibly anything) getting sent from outlet to inlet.
[...] because we've learned to think within the dataflow paradigm.
Actually you may call it the Miller paradigm instead: afaik, it's very appropriate to do so (factually speaking).
If this distinction never existed, we wouldn't think twice about mixing the types, because there wouldn't be any types.
Mostly agreed.
As far as I understand, the difference between control and audio data exists purely for computational efficiency, and has no real conceptual basis. (Maybe I'm asking for a beatdown with that statement?)
Trouble comes when you try to emulate messages using signals... efficiently... and without making things much more complicated than using messages. In the end, what's important is not so much to make the system simple, it's about making the system such that it makes the problem-solving simple.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada