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
_______________________________________________
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
