Re: Complex preset/automation data structure with mxj. Alternatives to preset/pattr?
This is how *I* have things laid out. As I said I’m self taught and there are many more professional programmers. But this is how I figured out how to work. I’d probably check with someone else to make sure I’m not totally insane. It may seem a bit bureaucratic at first but it stays almost exactly this simple as it scales up.
The reason I think that get and set should be avoided is because the word "get" is a misnomer. it’s far to easy and tempting to say
Also, it’s far to easy to fall into the habit of a.getB().getC()…getD();
Set, in this context is event worse because you could go directly to your model, change something and no event is fired and your view will end up out of sync. To fire an event for ever set message seems a little extreme. Maybe that’s the way other people work.
So this example shows how you can show the same data in various contexts. In extreme cases is if you want to display a big complex model, I would send the view a path, have the view "get" the model and make a seperate copy in the view object. So, for instance, say you want to have a seperate module name editor dialog. You would call some function that creates a nameEditDialog object and feed it a ModuleSoup, then it would copy all the module names into the nameEditDialog.
So, yes, you have the same data in two places but the strength is that if you stick to the concept (MVC) your object will always work even if things get out of sync.
Another strength of this way of working is that it makes it easy to work in one place and not worry about the rest. If you’re working on the interface all you do is send events "into the ether" when the user clicks, and update the interface when they come back.
It also means that you can control and view your data from anywhere in the patch. Just write a subclass the View object and all the other views update.
In your case, you might write a View for audio and a view for GUI.
Let me know what you think. Also, I wouldn’t suggest using this example for your patch… It’s just something generic to get you thinking like I do about this.