[PD] [*] vs [*~]

[Mathieu Bouchard]

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