[Feature] Integrate a patch editor into the Qt GUI
TheMisterE opened this issue · comments
The pitch
I've been bashing my head against the wall for months now trying to make MT-32 patches by routing the handful of patch editors that support the MT-32 into MUNT (both the Qt Standalone or Falcosoft's VSTi), and all I've gotten from it was lost hours and clumps of hair.
Figuring out how to send SYSEX commands... How to formulate a MT-32 SYSEX command... Trying to send anything from the editor to the software usually to no avail... And that's when it hit me.
The execution
If MUNT is emulating the MT-32, wouldn't it be trivial to directly modify the registers without jumping through any hoops at all? I can imagine a GUI function of double clicking a channel, seeing a nice and fancy editing screen, and editing the memory itself all in real time. No fuss, no muss, no MIDI commands at all.
In fact, I could also see a part of that GUI neatly providing a means of exporting well... anything as a SYSEX MIDI/.syx file.
It would read the state of the timbre/patch/bank in the editor, but not in the MT-32's memory itself (unless you want to take such an approach), and provide a choice of exporting the parameters in a singular SYSEX by itself or as a string of SYSEX commands for initializing and writing multiple timbres into the MT-32's memory for a whole song, everything all ready to go and waiting to be sequenced.
The summary
However you slice it, making patches for the MT-32 these days, especially internally in software using MUNT, is an exercise in convolutedness and futility. There's already a perfectly good Qt GUI interfacing MUNT as a whole, and an earlier suggestion of using the Qt GUI to select the preset timbres was received well. Why not go whole hog?
Hmm, I would agree that getting a MT-32 patch editor working nowadays is a bit of pain as most of them are created for Windows 3.1, others for DOS. Still, I don't think it's impossible, albeit having a tool that would work on modern machines would be nice, of course.
I need to say that the mt32emu-qt has no way to hack on the internals of the emulated MT-32 hardware, no. This is not foreseen by design of the library mt32emu. As we're emulating hardware, we normally provide interfaces of that hardware. Therefore, MIDI is the only way of adding custom patches and retrieving them back. I guess, this is unlikely to change.
Also, I doubt everyone would benefit of adding this feature to the synthesizer application. There are too many users not interested in creation of custom timbres, so this should rather be a new project within munt, to my mind.
Do you think it could be the case that it's less nobody's interested in making timbres and more that there's no good way to make timbres in the first place?
Anyway, it's a shame the Qt doesn't have access to the registers of the emulated MT-32. Skipping all the preamble and particulars of controlling the MT-32 through SYSEX by directly altering memory sounded like such a clean and straightforward way... Do you think such a feat could even be possible? Say, instead of integrating this timbre editor into the Qt back end (which as we've already established wouldn't work anyhow), someone were to create a program with MUNT built in to it expressly for the purpose of creating timbres and exporting SYSEX as described above would it all work smoothly?
I can't program at all, but maybe one day someone who does will stumble across this feature request and use it as a blueprint for their implementation. Would it bear fruit?
I suppose, creating a tool that accesses mt32emu's internals directly is well possible, because it's open source :)
But doing so in such a hacky way implies that the result can't be used with real hardware. Trust me, there is no particular simplification one might gain by doing so; the existing SysEx format is well documented, and creation of a compatible MIDI message is barely easier than calling some invented API from the UI code. But anyway, an effort has to be spent for such a tool.
I was just thinking that there would be no MIDI command overflow risk during real time editing, like knob adjusting during playback, if the commands aren't flooding in on the same line as the rest of the commands.
Anyway, here's hoping somebody saves us (and more specifically me) from the Sisyphean effort of making MT-32 timbres on modern hardware, much less all in-system with MUNT.
...Guess now this means I have no choice but to see if I can do such a thing in ReaLearn. Ugh.
@TheMisterE, I feel your pain— having gone fairly deep down this rabbit hole over the past couple years myself. What I have found to work best, is the last stable release of the abandoned SoundDiver. It is easy to find on archive.org and will run stably on modern Windows or WINE; It comes with a well designed adaptation (SD name for editor panel) for the MT-32, including librarian functions and drum mapping. There is some jank, but works pretty reliably, once you get to know the quirks. See img below for an example of the UI.
The archived ver. of Seald's Deep Synthesis has an alternate, simplified adaptation; it is faster to use, but more limited. This is helpful in another way though, because it includes default patch / setup configs, so you can begin as though the editor received an initial dump from the synth— Since MUNT does not report the current patches or parameter settings in memory, the connection is unidirectional. To mitigate that, just keep the auto-update function enabled, then MUNT will always match your editor state.
Planning to make a video/tutorial for this workflow pretty soon!
———
Regarding the question of whether there is a real desire to edit this device in general— from what I've seen online, people typically regard the MT-32 as a barebones, proto-GM rompler with limited creative potential in terms of sound design. Presumably, this is due to having no contemporary software editor or on-device editing capabilities and the amount of cheesy presets onboard.
Having spent some time editing it now, I think it is severely underestimated as a synthesizer. The depth of the voice architecture and level of configurability are really impressive in that form-factor, especially for a device from the late 80's.
Wow that was lengthy, hope it is helpful information for you and anyone else who stumbles onto this discussion.
Right, that's all fair enough. I myself have been using an abandoned LA-SYNTH editor running in a VM (as that's a win16 thing) to play with some edge cases which is not a way to go for professional work. Definitely, these synths feature great configurability, else we'd not bother with the emulation. So, as I said above, a good modern patch editor is needed, but rather as a stand-alone app. IMHO, such an editor would support whatever you connect: either munt or a real device via MIDI.
@sergm Yep that makes total sense! An editing capability would be a pretty distinct use-case from the PC gaming crowd. I wasn't trying to propose anything development-wise, just outlining a relatively modern and usable way to edit it currently, for the sake of anyone who is looking for one. Not a topic that comes up too often, so seemed worthwhile to explain these findings.
I also took a deeper look into the synthesis features, and I even was not aware that the MT-32 is a kind of smaller sibling to the legendary D-50, even though the samples are limited/worse and I think there was just one LFO instead of 3, but the MT-32 is multi-timbral on the other side while the D-50 can only play 2 different sounds at one time. Therefore, it could also e.g. very interesting to the demo scene where GM/GS is too limited, FM too bad and samples too memory hungry.
One of the main issues I discovered and checked with the source code (sorry, I am just able to partly understand source code, but I am not able to fix it myself) is that a lot of tested editors fail because MUNT only supports the DT1 command but none of the other commands (WSD, RQD, DAT, EOD...), so using commands where handshaking is involved does not work. Therefore, as written by someone before, even getting a memory dump right at the start of an editor causes an error message.
If this could be fixed, one might use at any editor out there, but I did fail with the ones I found in DOSBox (DOS and Windows 3.x) apart from SoundDiver that I did not check yet, so thanks for this hint. However, adding the missing MIDI functionality could at least be a great opportunity to get more people interested, especially if they knew that the MT-32 is not only a "stupid sample player"...
I had a look at ctrlr from www.ctrlr.org. It could be a great solution because it is not only a stand-alone controller for MIDI devices, but can also be used as VST3 instrument in a DAW. It is open-source and platform independent.
But: It is kind-of undocumented - apart from 9 year old examples, the C++ source code and discussions on the forum (closed) and GitHub. There is no Wiki (yet) and only <10 basic tutorials on YouTube. The UI for creating panels is awful, and for sending the required syx commands, you would have to use LUA commands and not something more common nowadays like Python. Maybe doing some copy & paste from the example panels might help here creating something.
On the other hand, I am sure that is possible to create an MT32 panel witih ctrlr - if there was not that deep learning curve... And the ctrlr project is not dead (yet) after all those years.
Good new, BTW! A new project appeared on the scene quite recently called MT32Editor. I suppose, this is more or less what one needs to unleash creativity with MT-32 (at least @now-its-dark seems happy with it, heh). There is just one thing to note, this is Windows-only atm.
FYI, there is also a thread at VOGONS dedicated on this nice tool.
Oh my god. It works with MUNT! It really works! It's not even done and it works!!
Send out the good word far and wide, christen https://github.com/sfryers with a medal or something! WE HAVE AN EDITOR THAT WORKS WITH MUNT!!
WE HAVE AN EDITOR THAT WORKS WITH MUNT!!
Well, on Windows at least 🙂