jaiserpe

Any tutorial explaining the implementation of the Model–view–controller in Max MSP?

Any tutorial explaining the implementation of the Model–view–controller in Max MSP?
Thanks

model–view–controller-design-pattern

Model-View-Controller separation in Max using Jamoma:

https://pdfs.semanticscholar.org/ed29/8f4adcca96709864e66caf4f9ffc2e15ab29.pdf

Design patterns | Doin' the Max - Msp Cafe:

http://mspcafe.g2312.de/tLb/framework/patchdesign/

 
Model-View-Controller separation in Max using Jamoma:
https://pdfs.semanticscholar.org/ed29/8f4adcca96709864e66caf4f9ffc2e15ab29.pdf 

Design patterns | Doin' the Max - Msp Cafe:
http://mspcafe.g2312.de/tLb/framework/patchdesign/ 

 has always looked like a powerful system, but it's an external with all associated risks. Instead, I prefer using the built-in object system for MVC. The second article shows how to do this using the [pattr] system. This technique litters patches with objects extraneous to the logic itself. This may not be too big a price to pay, but I wonder if it is necessary?

My solution is to simply use abstractions. Views can be implemented and called into the main program using a [bpatcher]. Models are abstractions without interface, and so can be instantiated directly. The [pattr] system can still be used as needed, to store and recall settings.

To initialise objects, a global message can dispatch to named objects. Personally I am not a fan of global solutions (send/receive etc.). Instead, each View abstraction can have an input designed to dispatch "set" messages to the interface elements. Of course a consistent naming scheme is important in this (or any) MVC implementation. 

MVC often implies a client/server architecture. This can be achieved with OSC communication between different Max applications. Isn't this how Jamoma works under the hood? Or, y'know, use Supercollider. :-)

 Jamoma has always looked like a powerful system, but it's an external with all associated risks. Instead, I prefer using the built-in object system for MVC.   The second article shows how to do this using the [pattr] system. This technique litters patches with objects extraneous to the logic itself. This may not be too big a price to pay, but I wonder if it is necessary?

My solution is to simply use abstractions. Views can be implemented and called into the main program using a [bpatcher]. Models are abstractions without interface, and so can be instantiated directly. The [pattr] system can still be used as needed, to store and recall settings.

To initialise objects, a global message can dispatch to named objects. Personally I am not a fan of global solutions (send/receive etc.). Instead, each View abstraction can have an input designed to dispatch "set" messages to the interface elements. Of course a consistent naming scheme is important in this (or any) MVC implementation. 

MVC often implies a client/server architecture. This can be achieved with OSC communication between different Max applications. Isn't this how Jamoma works under the hood? Or, y'know, use Supercollider. :-)

Model–view–controller design pattern