Building a QSR Synth Editor
This is my second Max project. I just started using Max seriously about 10 weeks ago. I was an audio engineer for public television, and a computer programmer since the late '70s. I worked in a university environment with all the plusses and minuses that provides.
I'm writing an editor for an Alesis QSR synth, which I "inherited" from a university research project.
So far I have done a lot of the "grunt" work of coding all the parameter info included in the User Manual as well as the MIDI Sysex Specification. Right now my QSR_Params.js has over 1200 lines of code. (BTW, if anyone out there has a QS6, 7, 8 or R I'm happy to share my code!)
I've got communication with the synth working. I have retrieved the various Program, Effects, Mix and Global data dumps, saved them to disk, and retrieved them from disk. I've verified that I can read and write parameter settings to the synth.
A word or two about the QSR might help make sense of the UI issues I'm facing.
A "Program" on the QSR consists of four "Sounds." Each Sound can be either a Keyboard Sound or a Drum Sound. Keyboard sounds have a bunch of properties that are different from the Drum Sounds. If a Sound.type = "Drum Sound", then it contains within it 10 Drum Sounds, each with a bunch of properties. The QSR also has a bunch of Effects settings and Mix settings.
My question at the moment is about how to arrange the UI elements, and how to best communicate changed UI settings back to my QSR_Ctls.js (the Javascript that currently uses ParameterListeners for each control). I'm beginning to think this is a job for pattr and the pattr family. There are many hundreds of settings to manage, so I'm hopeful this can be done programatically.
I eagerly solicit ideas!
After reviewing the pattr tutorials, it looks like autopattr object will do what I need. Much less to deal with in Javascript. ("The man with a hammer sees everything as a nail.")
Glad you figured out something that will work. But I can go and mention a few other things.
One other way you can communicate changed UI settings in JS is by the MaxobjListener object in JavaScript. Every time a value changes, it will execute a specific function.
For the UI elements, I would say, if you have hundreds of settings, hopefully you don't have hundreds of Max objects. Using fewer objects that send data out in lists is better. For example, rather than have 800 toggle objects, you could use a single matrixctrl object; or instead of 200 metros, you might prefer a single mc.gen object with the internal metronome on. Then afterwards, JavaScript is pretty great at managing arrays.
Thanks for the comments!
I was able to load huge portions of my Javascript into a Max dict object. I had a few days scratching my head before I figured out how to handle a Dictionary of Dictionaries, but I was getting confused with syntax differences between current Javascript and the version in Max. (Along with a Max bug that shows up when you have a dictionary with a single key. Along with my lack of experience in using Javascript in Max!)
I'm imagining that I won't need more than a few dozen UI controls at any given moment. I should be able to map their values to appropriate variables based on context. Of course if I do that I lose the convenience of data binding that (I think) pattr offers. More news as it develops.