Iterative Design Process:

An Iterative Design Process has 6 major steps:
  1. Conceptualization
  2. Analysis
  3. Design
  4. Implementation
  5. Testing
  6. Rollout
Normally, you will repeat steps 2,3,4 and 5 before going on to step 6.


Decide what your goal is. What do you want to be able to support? Often you will only know this after the analysis of the synth's documentation, or in other words, you probably want to support anything you can, so you have to know what is supported by the sysex specs of your synth, and what can be done with JSynthLib.


In this phase, you'll make a list of the different sysex messages, and the type of information they describe.
You can divide the messages in two main groups:
  1. Requests : To get info from the device, variables are written between asterixes.
  2. Replies : Write down the size, and any info you have about the bytes.
Here are some types of subgroups of requests I could think of, your device may or may not understand messages of each type:
  • Single parameter : only for editors
  • Single performance/program/voice/patch/drumsound/patch-settings/general-settings/...
  • Single bank/drumkit
  • Multiple banks
  • Full dump
For library support, you need this info about the replies:
  • size: the number of bytes in the message (e.g. 'F7' is one byte)
  • header: the part of the message that is always the same for "that type of data" from "that type of synth".
  • the offset of important bytes (offset of first byte F7 = 0, the next offset = 1, etc.)
Important bytes for library support are deviceID, patchnumber, banknumber and checksum.
Other variables can also be used. (e.g. "data" if there's a byte that defines the data type).

AnalysisTable : an attempt to make a template to help you get started.


When you have a clear understanding of the sysex specs, it's time to decide how to organize it in different types of JSynthLib patches and corresponding drivers.
For editors, it's a good idea to make some sketches.


With the information from the analysis and design steps, you can now use parts of other drivers as examples to build your own driver.


Now use a sysex monitor to check if the driver works.
There's a part in the official programmer's guide about testing, check it out there, (and add whatever is missing here.)


Check the contribute page for more info.