Edisyn, a Java patch editor library for hardware synthesizers

A patch editor written as a pure-Java library

Edisyn calls itself a synthesizer patch editor and librarian, and the word library is literal rather than marketing. The sources live under edisyn/ as Java files with a Makefile at the top level, not as a packaged desktop application. The About section states that Edisyn is a synthesizer patch editor library written in pure Java, and that it runs on MacOS, Linux and Windows. Portability comes from the platform-specific work being pushed into one dependency, DerekCook's CoreMidi4J, which the project credits with fixing critical bugs in MacOS's sysex handling. Anyone who wants to drive patch handling from their own Java code can call the same classes the desktop front end uses. The trade-off is that library and application are a single tree, so nothing is published as a stable artifact for reuse and every consumer builds from source.

Building and running Edisyn from the Makefile

There is no installer script at the top level of the repository. The build path runs through javac and the jar bundled in libraries/, and the Makefile's all target compiles the whole edisyn/ tree against it in one invocation:

	${JAVAC} -cp libraries/coremidi4j-1.6.jar:edisyn $$(find edisyn -name '*.java')

Starting it is the run target, which puts the compiled classes and the same jar on the classpath and launches the edisyn.Edisyn entry point:

	java -cp libraries/coremidi4j-1.6.jar:. edisyn.Edisyn

Both steps assume a JDK on the path and the repository checked out with libraries/ intact. A third target, indent, rewrites the Java sources through Emacs to normalise whitespace, which tells you the project treats the source tree itself as something to tidy rather than relying on an external formatter.

One editor per synth family, and a mode switch inside each

The supported instrument list is the clearest statement of scope, and it runs long: Alesis D4 and DM5, the ASM Hydrasynth family in single mode only, the Casio CZ series, DSI Prophet '08 and the Mopho variants, E-Mu Proteus and Orbit models, Kawai K1 through K5000, Korg SG Rack and MicroKorg, the Novation A Station and Drumstation, Roland D-110 and JV series, Sequential Prophet Rev2, Waldorf Blofeld, Kyra, M, Microwave and Rocket, and the Yamaha DX7 and 4-Op FM families. Inside a family, Edisyn exposes the instrument's own modes, such as single, multi, drum and global modes for the Kawai K4. The repository carries catalogue data such as edisyn/synth/synths.txt and edisyn/Manufacturers.txt, so the synth list is data-driven rather than buried in the interface code.

Patch exploration tools that go past parameter editing

The README claims Edisyn has the most sophisticated set of general-purpose patch-exploration tools of any patch editor available, and it then says what that means. Randomization is weighted patch mutation. Merging is weighted recombination of two patches you pick. Mixing is bulk recombination of many patches into one. Blending recombines two randomly chosen patches on the synth. Nudging pushes the current patch toward or away from one of four other patches. Morphing interpolates four patches in real time to form a new one. Two entries go further. Hill-Climbing and Constriction describe an evolutionary search in which Edisyn offers candidate patches, you grade them, and it proposes new ones from those grades. Deep-Learned Models applies a deep-learned Variational Autoencoder to Randomization and Hill-Climbing, credited to the contributor V. Hoyle.

The CoreMidi4J dependency and what it papers over

The classpath entry libraries/coremidi4j-1.6.jar is not an optional extra. The project gives special thanks to DerekCook's CoreMidi4J and says Edisyn uses it to fix critical bugs in MacOS's sysex handling. On Linux and Windows that jar travels along unused, and on macOS it is the layer between Edisyn and the operating system MIDI stack, where SysEx delivery is unreliable without it. This is the cost of a pure-Java core: the body of the code is portable, but one vendor-specific bridge library has to come along with it. The jar target shows the consequence, since it has to unpack the uk/ and META-INF/ contents of that jar and move them to the top level of the built archive before repacking.

Packaging one archive with a hand-written manifest

The jar target does not take metadata from a separate build description. It writes the manifest entry itself and hands it to jar -cvfm:

	echo "Main-Class: edisyn.Edisyn" > /tmp/manifest.add

The archive then bundles the compiled classes with the data the interface needs at runtime, including edisyn/synth/synths.txt, edisyn/gui/wordlist.txt, edisyn/Manufacturers.txt, wavetable data under edisyn/synth/, and edisyn/synth/kawaik5000/kharmonics.out for the K5000 editors. The install target goes further and assembles a macOS application bundle and a jnlp launch file, after removing earlier output from the install directory. The practical point is that one archive can be dropped onto a machine, but everything the editor knows about a given synth depends on those packaged text files being present and current.

Where Edisyn is the wrong tool

Several limits are visible in the support list itself. The ASM Hydrasynth family is covered in single mode only, and the Korg Volca support is described as a joint editor rather than separate per-instrument editors, so a synth whose firmware reorganises its parameter layout will not be fully reachable. Firmware drift is a recurring cost: the What's New notes record a new version of the Waldorf M editor with revision to match the M's current firmware, which shows these editors are revised by hand against hardware releases. The repository publishes no GitHub releases, so there is no release history to track and no changelog beyond the README, and the application describes itself as Version 37 without a dated trail. If your instrument is absent from the list, Edisyn cannot help you.

How Edisyn differs from vendor editors and raw SysEx tools

The usual alternative is the editor the instrument maker ships, which is guaranteed to match the firmware and often exposes hardware-only functions. Edisyn takes the opposite approach, reimplementing each synth's parameter map in Java and adding a layer a vendor editor does not offer: infinite levels of undo, CC and NRPN mapping and learning, offline modes, per-parameter customization, real-time parameter updates, test notes and chords, and Pseudo-MPE support. The other common alternative is a raw SysEx utility that reads and writes hex dumps without understanding them. Edisyn sits between the two. It knows what the bytes mean, so it can randomise, recombine and morph patches instead of only moving them, but it depends on the manufacturer not having put a proprietary locking layer in the way. The same author's related projects, including Flow, a modular software synthesizer, and the Seq sequencer, push in related directions.

Editorial conclusion

Edisyn suits people who own one of the listed hardware synths, work in Java, and want to explore patches rather than merely move them. It does not suit a musician who needs the newest firmware features of one instrument, or anyone who wants a packaged binary without a JDK and javac on the machine. Before adopting it, check that your exact model and its mode appear in the supported list, confirm the CoreMidi4J dependency travels with the jar you distribute, and expect to rebuild when hardware firmware changes, as the revised Waldorf M editor shows.

Frequently asked questions

Official sources

1. eclab/edisyn on GitHub
2. Issues
3. License: Apache-2.0
4. README