Initial version addressing a myriad of architectural design decisions.
No issues for this version
- MVC architecture (views vs. models)
- NodeLib (communication backbone and tree traversal)
- Multicore (realtime dsp and audio graph, including matrix mixer)
- Dataspaces (complete implementation and integration of dataspaces)
- User Preferences (see User_Preference_Menu)
- Network exposure and access
- minor specifications
Jamoma 0.6 : La Vigne Mythique¶
Jamoma 0.6 will focus on clarifying structural aspects of the framework according to the MVC design pattern. This will allow for future work to add functionality or features while limiting the disturbance to the rest of the system.One prominent effect of clarifying the MVC structure in Jamoma is the notion of multiple views of a module. A module in Jamoma 0.6 will be able to exist with 1 or more views of any given model. Some example views might be:
- a message-based interface using OSC
- a message-based interface using nOSC
- a message-based interface using JSON
- a graphical user interface on a local machine
- a graphical user interface on a remote machine
To accomplish this, Jamoma 0.6 will implement every model such that it can be its own server (in the server-client sense that is understood analogizing SuperCollider).
Thus the model has parameters, messages, etc. Then one or more views will use a controller (the client) to interact with the model (the server). This is partially diagramed in the active branch Resources/Documents folder with an !OmniGraffle file.
The above proposed implementation is much more closely in-line with the way that other MVC systems are implemented, including Apple's Cocoa.
To this end, we need to discern how to properly separate model, view, and controller. Currently they are bleeding into each other.
Below are some additional notes extracted from Skype transcript between Tim and Trond on 11 July 2008.
The nOSC thing could be really interesting.
That was the conversation that Pascal and I had on the plane from Toulouse to Paris.
Instinctly I'm just asking myself, why bother about OSC at all. Would it make more sense to go all JSON in the first place?
I'm asking the same question.
The big thing offered by JSON is that it is structured.
and it also has a huge community behind it
If I had never used OSC before and saw this for the first time, I'd feel that it is very awkward to start out using one protocol, and then have to embed another because the first one is not good enough.
Would make more sense to make a JSON<->OSC mapping module, so that Jamoma can communicate with OSC apps, and then internally go JSON.
What would this message look like in JSON syntax?
/filtermodule/frequency 400 Hz
I'm not sure -- it could maybe be done a few different ways?
and a bigger question:
why does the end user have to communicate with the module using the low-level (behind-the-scenes) protocol to send a message to a module?
I'm not really proposing anything specific, I'm just asking questions.
But why does the user need to know OSC, nOSC, JSON, etc.
We have to make an interface of some kind in order for the user to be able to communicate settings to the system in a text format.
So a syntax of one kind or another is required
It seems like there should be a way to interact with a module that is higher-level than whatever the internal mechanism
it's like a separation of the controller and the view, except that the view is a messaging syntax at a higher-level than the low-level syntax.
so you could send a simple (and normal looking any user) message to the filter module: frequency 1000 Hz
and behind the scenes the controller does whatever it is that it needs to do
But when preparing syntax for the user, or providing points of access to setting parameters in a text format, user-friendliness and readability would be important
One of the disadvantages of that is that it is not necessarily obvious where the address of the parameter ends and the value of the parameter starts... That would need some kind of divider
I've never been very comfortable with the way we are using OSC in the naming of things directly. It seems like it should be used for representation of a system, not necessarily for the system itself. JSON can also be a way of representing the system without directly inject JSON syntax into the system components.
The point is that Jamoma has remained very modular:
We don't say much about where it can be accessed from, so you can communicate directly to a module, via a meta-module such as the mappers or cuelist, or by remote messaging.
And also, any parameter remains accessible to the outside world.
Yes. I'm not challenging any of that.
Maybe I'm wrong here, but would a distinguishing between a representation of a system, and the system itself, require some kinds of assumptions that might counter-act the modularity?
I don't think so
I'm reading a couple of books right now about debugging
And they are further advancing my understanding of the MVC architecture
And how testing systems that are automated are ideally implemented by creating a different view of a given unit, without that unit knowing anything about it.
To extrapolate from that to Jamoma, we could say that we are trying to achieve the case where have the model (some little audio engine like a filter), and we have two views:
1. the graphical view
2. the messaging view
#2 happens to use OSC
but OSC should be limited to the view and not be mucking up the model
A parallel example of the is the Mac OS.
On a larger scale, the windows and menus are accessible using a graphical user interface
but they are implemented with multiple views -- one of which is AppleScript
"Destroy nothing; Destroy the most important thing."
But I think that we would still need a way for views and controllers to connect.
Yes. Otherwise it's a broken system.
By calling methods, setting properties or in one or another way pass messages to each other.
And that might just as well be using OSC as anything else as long as it serves our needs.
I think that, yes, it shouldn't matter what the controller layer is using -- whatever it is the user shouldn't even have to know about it.
Because the user should only be interacting with one of several possible views
even if some of the views aren't actually graphical interfaces
But to me, if the view is text-based, it has to be based on a syntax of one kind or anther.
It should be easy to read and work with, but I believe that it's very hard to avoid the assumption that the user need to know the syntax, both in terms of how it is structured, and what parameters exist and how the have to be addressed
This means that one standard way of communicating exists between controller and views, and viewss might prepare them in a number of different ways for the world to interact with?
If so, for the time being, the critical thing for us is to sort out the communication between controller and views.
and the nOSC <-> JSON would be a kind of view that translates into something else.
I think so. We should sort out what is going on anyway, but this would make it much easier to add on functions in the future while limiting the damage to the rest of the system.
Yes, on the other hand I'm concerned about the overhead that it might introduce.
For example, when the next great thing comes along that we have to use. It would be nice to be able to create a view for that great thing and then not have to touch the controller or the model. At least this is the theory.
I'm not terribly convinced that overhead will be a problem. OSC introduces a bit of overhead, and I don't think we would be introducing much in addition to that.
But that's just my gut feeling.
Other Relevant Resources¶
- http://andrzejonsoftware.blogspot.com/2008/07/mvc-how-to-write-controllers.html (note: Fat Model, Skinny Controller)