Hello,
i wonder how you guys approach making big templates, like for a synth with a lot of pages & parameters.
for example, the Korg Prophecy has well over 200 parameters to tweak, besides the obvious space needed for controls on the lemur i wonder how to make such a template in the most economic way regarding scripting.
one idea is to work with a sort of classes, to write a script containing the basic sysex stuff and use variables for the controls and just call them with faders and buttons, like on expression cutoff();
but from what i learned those scripts are not (obviously) comparable to classes, it seems not possible to instantiate such a script as often as you want at the same time with different variables used at this point.
for example:
fader one: on expression Sysex(); (variable would be cutoff)
fader one: on expression Sysex(); (variable would be resonance)
the idea is to have basically a handfull of such scripts and pass the data needed with variables instead of having to tie scripts to each and every object.
hope my thoughts understandable in some way
this thread has not to be about the prophecy but at least to me it´s interestign to find out how others approach making their templates.
cheers,
Martin
programming techniques for huge templates
Re: programming techniques for huge templates
Hi
Yes, I think a class/object oriented approach is probably the best way to go about it . . .
Scripts which get and set variables, scripts to deal with input/output, vectors/arrays of data etc . . .
Good planning of problem domain, namespace, psuedo-code etc probably helps too . . . // And comments . . .
Using a consistent approach to naming as well - stuff like init(), onLoad(), (), process() etc globally
And then amongst objects more process descriptive names so you can read it and understand easily
And consistent naming for types of objects as well so you know what something represents easily
Work modularly, completing sub-units and testing them, before integrating more. And lots of comments
Look for processes that can be handled globally and repeated object processes that can be sent to them.
Look through as many projects as possible for ideas and approaches to gain some insight . . .
Many projects seem quite well coded, with a lot of those sorts of features; check out AB's work . . .
As you look through the projects you will also get a feel for those that fail in this regard . . .
There are numerous ways to approach any given problem and often not a single best approach
Oh and you will probably end up with more than just a handful of scripts and data
It is an interesting topic and I also look forward to hearing other people take on it
It would be good to gather up some of this info to publish in the end . . ..
Cheers
MM
Yes, I think a class/object oriented approach is probably the best way to go about it . . .
Scripts which get and set variables, scripts to deal with input/output, vectors/arrays of data etc . . .
Good planning of problem domain, namespace, psuedo-code etc probably helps too . . . // And comments . . .
Using a consistent approach to naming as well - stuff like init(), onLoad(), (), process() etc globally
And then amongst objects more process descriptive names so you can read it and understand easily
And consistent naming for types of objects as well so you know what something represents easily
Work modularly, completing sub-units and testing them, before integrating more. And lots of comments
Look for processes that can be handled globally and repeated object processes that can be sent to them.
Look through as many projects as possible for ideas and approaches to gain some insight . . .
Many projects seem quite well coded, with a lot of those sorts of features; check out AB's work . . .
As you look through the projects you will also get a feel for those that fail in this regard . . .
There are numerous ways to approach any given problem and often not a single best approach
Oh and you will probably end up with more than just a handful of scripts and data
It is an interesting topic and I also look forward to hearing other people take on it
It would be good to gather up some of this info to publish in the end . . ..
Cheers
MM
iMac 2.8G i7 12G 10.6.8/10.7.2, Legacy Dexter/Lemur, Liine Lemur/iPad2, KMI SoftStep, 12Step & QuNeo , B-Controls, Mackie C4 etc
MaxMSP, Live Suite, Native Instrument stuff, etc Modified Virtual Guitar System etc All Projects/Modules © CC-BY-NC-SA[*][/b]
MaxMSP, Live Suite, Native Instrument stuff, etc Modified Virtual Guitar System etc All Projects/Modules © CC-BY-NC-SA[*][/b]