On Wed, 17 May 2006, Hans-Christoph Steiner wrote:
Max/MSP is a very high quality production tool without strict adherence to the Max paradigm. For example, JavaScript for GUIs instead of graphical programming,
The old MAX doesn't strictly adhere to the Max paradigm either. Externals are coded in C and C is not dataflow. Just because C is C doesn't mean you have to ignore that a lot of things get written in C just because there is no alternative (perceived or real). There's this double-standard by which C doesn't count as violating the paradigm while anything else may.
and the use of threads rather than trying to stick with the real-time scheduling.
how do you find the difference between a principle of the paradigm, and a limitation of an implementation? Why do threads necessarily fall outside of the Max paradigm? Would the "Max paradigm" be any different in your eyes if Miller didn't hate threads? How are threads necessarily non-realtime scheduling? How is realtime scheduling necessarily non-threaded? Have you ever looked at a realtime operating system like QNX which handles threads/processes in a thoroughly realtime way? What is the status of that kind of feature in Linux, OSX and Win32? What can Pd's scheduler do about priorities, time limits and preemption without getting itself to use the OS's threads?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada