Sophia

This idea came out of a discussion where I brought up comparisons between Max and Functional Reactive Programming and got some great information from Graham Wakefield and others about the history of functional programming for artists, particularly the work of Paul Hudak and Conal Elliott. I figured it warranted a new thread.

After reading a lot of Elliott describing animation environments for Haskell like Fran and Eros, which he intended primarily for use by artists, I became interested in some particular aspects of how Max interprets visual syntax into something that can be compiled natively. Frankly, I'm also continually impressed with each release in C74's ability to optimize a 30 year old visual language for radical advances in hardware design to the point it runs pretty much as fast as anything I personally could code in a lower level language (I know because I've tried and ran comparisons...).

Now, obviously we know from writing externals that Max objects map rather simply to C++ objects. It seems the difficult part is how they’re *scheduled.* There seems to be two ways to parse a patch's order of operations: one based on an xy grid like scan lines in television, but then in order to make sure each instance has its input available at the time of execution there needs to be another order based on patch cords.

I imagine patch cords would be implemented as streams, or discrete lists sampled from what is presented to the Max user as a continuous data flow. These streams would then take three forms likely overloaded on top of each other: simple streams of scalars using mutable typing, streams fixed to audio rate, and streams of matrices. Then of course there's messaging, but I like to pretend that doesn't exist :)

So at that point you have two orders of operation you could diff for error checking, but ideally allowing for flexibility in execution. I’m guessing this flexibility is what made it so seamless for C74 to optimize code for hardware advances, for instance implementing implicit multithreading and moving all Jitter objects to the GPU without the user explicitly digging into OpenGL. At least I really hope the operations in my patches aren't being executed strictly in the order I specify, but rather being optimized without me having to think about it.

I don't think I'm asking for any secret sauce here, but I’d love to see some kind of article discussing this part of Max’s codebase on an abstract level. I’m not sure if it would reveal any new best practices for patching, but I think it would help to situate Max among similar efforts we don’t often compare it to.

This idea came out of a discussion where I brought up comparisons between Max and Functional Reactive Programming and got some great information from Graham Wakefield and others about the history of functional programming for artists, particularly the work of Paul Hudak and Conal Elliott. I figured it warranted a new thread. 

After reading a lot of Elliott describing animation environments for Haskell like Fran and Eros, which he intended primarily for use by artists, I became interested in some particular aspects of how Max interprets visual syntax into something that can be compiled natively. Frankly, I'm also continually impressed with each release in C74's ability to optimize a 30 year old visual language for radical advances in hardware design to the point it runs pretty much as fast as anything I personally could code in a lower level language (I know because I've tried and ran comparisons...). 

Now, obviously we know from writing externals that Max objects map rather simply to C++ objects. It seems the difficult part is how they’re *scheduled.* There seems to be two ways to parse a patch's order of operations: one based on an xy grid like scan lines in television, but then in order to make sure each instance has its input available at the time of execution there needs to be another order based on patch cords. 

So at that point you have two orders of operation you could diff for error checking, but ideally allowing for flexibility in execution. I’m guessing this flexibility is what made it so seamless for C74 to optimize code for hardware advances, for instance implementing implicit multithreading and moving all Jitter objects to the GPU without the user explicitly digging into OpenGL. At least I really hope the operations in my patches aren't being executed strictly in the order I specify, but rather being optimized without me having to think about it. 

Suggestion For Blog Post About How Max Handles Scheduling Under the Hood