notes.txt : Added section on "Language Notes" and "New Design Notes".

doc/notes.txt

@@ -12,6 +12,64 @@ SPAT LAB SETUP:
     a. TotalMix - select 'DTS_24ch'
     b. mixer: Recall preset 96 ('24ch firecac ufx')
 
+LANGUAGE NOTES:
+The primary goal of the language is to initialize a dataflow system.
+Sub-goals:
+1) Avoid describing domain specific computation in the language. As much as possible constrain the 
+language to describe initialization tasks (e.g. object allocation, object connection, initialization
+parameters, preset grouping, thread/process allocation, UI layout, ...)
+
+2) Network Distrubution
+3) UI Layout
+
+Runtime:
++ Extensible data-object system.
++ Library organization (application objects, simple objects, vector library)
+  
+
+NEW DESIGN NOTES:
++ The current designs fundamental weakness is that it uses callbacks to communicate where sequential program 
+  flow would produce a more comprehensible program.
+
++ Dataflow is a natural way to express DSP programs but if it is implemented in a textual, rather than 
+  graphical language, then their are some design princles that must be followed in order
+  to produce comprehensible programs.
+  1) Limit the number of connections as much as possible.
+     - There are many simple UI->param connections - these should be made automatically and UI
+     objects should not have to be explicitely created - they should be created by the runtime 
+     environment.
+     - If multiple pieces of data are part of a single message then they should be sent as a unit
+     rather than separately. This decreases the number of connections and also removes timing
+     dependencies - where the application programmer has to know the order of transmission of the
+     individual pieces. (e.g. MIDI messages always contain {status,d0,d1} rather than having to
+     send d0 and d1 followed by status to indicate the end of the message {status,d0,d1} should
+     be sent as a single record.
+  2) Eliminate as many event ordering issues as possible 
+     See the example in 1).
+  3) Alllow the connections between objects to be made as part of the object allocation.
+  4) Allow subprograms to be made. This decreases the complexity of the programs and because
+  it allows the programs to be organized hierarchically.  It also allows the subprograms to
+     be tested idenpendently.
+  5) A natural way to express object multiplicity is required. (e.g. multiple channels).
+     This leads to a way to naturally create parallel/fan-in/fan-out connections.
+  
++ One way to solve some of the problems of the current program would be to add debugging tools.
+  - Generate dataflow diagrams that show execution order and the order of connections.
+    The actual sending order of the outputs is not accessible to a static network analyzer because it is
+    implementation dependent. 
+  - Generate reports of network activity that show the timed order of events.
++  The audio system (cmAudioSys) needs to be able to support multiple parallel DSP chains in separate threads.
++  UI Related Issues:
+   - Automatic UI's should be generated by scanning the objects parameters.
+   - Custom UI's should be created by explicitily naming object variables along with layout info.
++  Processors should be able to contain their own processing chains - embeddding processors should be possible.
+   This naturally leads to a tree address space.  (e.g. fx.filter.param1)
++  Communication between threads should not necessarily require serialization. 
+   - Use a blackboard approach where object values are read/written from a blackboard. Objects on the same
+     thread use the same physical blackboard. Blackboards on remote processes stream data in the background.
+   - This scheme may require double buffering of complex objects to prevent accessing invalid data states.  
++  Objects that send multiple valued messages should use 'record' based data so that only one connection
+   is necessary.
 
 STRATEGY:
 + implement highly parallel version - which can take advantage of multiple processors