Editors, rants and ideas

[Benzebub]

I am the proud owner of a bunch of hardware synths and really enjoy the hands-on programming approach found on the majority of the ones I own. However, I also often use an editor with synths mostly to get a good overview of how the patch is set up since the knobs do not show the actual value of the parameter. Some synths have very good capabilities to get a good overview on the patch built in (Tempest is the one of all I own that is closest to perfect in this regard with the Pro 2 being a close second) and others are not as good (Sub Phatty for instance with all of it's hidden parameters) meaning the editor is quite necessary.
Now, Moog has made their own editor for the Sub Phatty (which in my opinion is very good) and Soundtower makes editor for most of the DSI synths, however there is still some problems and potential for a good solution.
One issue is that of platform compatibility meaning that the editor needs to be developed for the intended platform and a few years down the road when new operating systems are released they may not work.
However, synths usually use standard MIDI to communicate and use SysEx for sending patches. Wouldn't it be a lot easier if there was a standard way to describe a synths panel and it's parameters so that applications can be developed that read the data of how a synth is designed and maps it to controls on the screen that also easily can be mapped to a DAW?
There is a good controller editor available, ctrlr, that has good platform compatability but it is slightly awkward (in my opinion) to make panels for it.

What I am envisioning could be achieved with an XML standard file that describes which parameters are available on a synth, which CC or NRPN number that corresponds to the parameter and how the SysEx file format is structured to allow dumping of programs and reading it's settings. This way a synth manufacturer (or a person with knowledge about the synths SysEx specification) can easily create a specification file that can be published and the client application can import it.

How hard would this be to implement?

[Razmo]

Lets just say, that it will be more complicated than most would think...

Many companies these days have begun using just NRPNs for parameter changes... DSI do not give you any SysEx structure descriptions anymore, simply because all controllers try to only take on NRPN or CC for parameter changes, and basicaly that is all you need to edit all parameters... the device only need to maybe scale the NRPN/CC value.

But this is only good for one way communication in most cases, and never lets you get at the memory locations... this is where SysEx is needed every single time.

The problem is, that if it is to be capable of handling SysEx, it gets complicated, as SysEx allow for basicaly anything the manufacturer decides... there are no rules, no specific protocol for how to represent the parameters... some use bytes, some use words, and again, others use totaly different approaches... also how the parameter values are used are varied... many digital synths with FX, usualy have a parameter (a byte in the structure) that will be used differently depending on what FX type you have selected... so a universal editor should be capable of differenciating on one byte, depending on what another byte is, to fascilitate this, and also be capable of showing different parameters on the screen, depending on what FX has been chosen etc...

Then there is the checksum nightmare... you have to account for any god damned type available, and all those not yet thought up.

Yes... it can be done, but if you thik it will be easy to setup an editor without knowledge of bits, bytes and what have you, I think you'll be disappointed. especialy if you want to be able to include all past synths end devices out there.

On the other hand, if you made a COMPLETELY specified protocol for SysEx, that EVERY synth manufacturer adhered to from now on, then it shoudl most definitely be possible, and not even that complicated... but you will eventualy run into the problem, that at some point, someone will find the protocol unsatisfying, and they will add on it, change something and then things start to get out of hand again.

Another aspect you have to consider is, that even if a common protocol were made, then what the parameters represent will always change... you could have a simple ADSR envelope graphic representation ... but then what about the Blofelds multistage envelopes?... that would also have to be custom accounted for... even if you could make one that would catch almost all types of multistage envelopes, at some point, someone will come up with an envelope it cannot hande in it's graphical representation.... same goes for other graphical representations... wavetable editors? ... some have 64 bytes, some 128... future ones may have more, you do not know what will come, and thus the protocal and interface would have to be constantly updated with new support.

It's a daunting task... just look at how comprehensive the custom editor is in the old SoundDiver application... before you know of it, a universal editor will be so complicated to create for, that you'll have to have some kind of programing eperience... many times so much, that you could as well code the enitre editor from scratch for that ONE synth instead.

[DavidDever]

Anyone remember when MIDI Name Documents http://dev.midi.org/dtds/midi_xml.php were first rolled out (OS X 10.2)? It was a potentially good idea for the time, though in practice, the syntax was a bit overbearing when creating your own patch lists.

SSDP service descriptions for UPnP / DLNA devices seem to work along similar lines, and I'm sure that a modern equivalent, based on JSON objects, would be quite easy to roll (and far more efficient).

Anything is possible, though manufacturer assistance is far preferable to unstructured data dumps alone.