VOGONS


First post, by MusicallyInspired

User metadata
Rank Oldbie
Rank
Oldbie

Recently in a MUNT Github feature request thread that asked for full timbre editing capabilities for a possible MUNT VSTi plugin, I pitched to Falcosoft a possible collaboration of myself writing a timbre editor for his MuntVSTi plugin. He graciously supplied a test version which can utilize a separate Timbre Editing DLL to be integrated into MuntVSTi. I've started working on a DLL for this purpose and here's what it looks like at the moment. Still a lot of wiring to do under the hood to make sure it all works properly, and it's currently quite ugly using the generic Windows control scheme, but testing has been going very well and controls are starting to work exactly as intended.

The attachment muntvsti timbre editor.png is no longer available

It's built in Delphi and is currently only a Timbre Editor and only edits the instruments of the Timbre Temp Area (though it is multi-timbral so you can edit all 8 Parts separately). It currently doesn't go into the Patch Temp Areas or Rhythm Setup, Patch Memory, Timbre Memory, or System Area. But I do plan to extend its functionality later into a full MT-32 system editor so you can access every part of the MT-32. It's designed to stay in sync with MuntVSTi's internal memory which makes this the only way thus far that I have found to be able to receive data FROM Munt and not just send data to it via sysex (MUNT currently still has no MIDI output). Which means, as well as being a useful tool for composers and producers in a DAW setting, this could be a viable way to extract MT-32 sysex banks from games without needing an actual hardware MT-32.

This is in no way intended to step on the toes of sfryers and replace his wonderful MT-32 editor (programmed in .NET), which I've used very often! But it's long overdue that we have a patch editor with a fully integrated MUNT core as a viable VSTi plugin for DAWs so producers can customize their MT-32 sounds much more easily. When it gets to a functional state, I will be releasing it with the source on Github. For now, here's a sneak peek.

MT-32 Editor VSTi (wip)
FB-01 tools
Github
SC-55 Packs

Reply 1 of 4, by Falcosoft

User metadata
Rank l33t
Rank
l33t
MusicallyInspired wrote on Yesterday, 02:29:
Recently in a MUNT Github feature request thread that asked for full timbre editing capabilities for a possible MUNT VSTi plugin […]
Show full quote

Recently in a MUNT Github feature request thread that asked for full timbre editing capabilities for a possible MUNT VSTi plugin, I pitched to Falcosoft a possible collaboration of myself writing a timbre editor for his MuntVSTi plugin. He graciously supplied a test version which can utilize a separate Timbre Editing DLL to be integrated into MuntVSTi. I've started working on a DLL for this purpose and here's what it looks like at the moment. Still a lot of wiring to do under the hood to make sure it all works properly, and it's currently quite ugly using the generic Windows control scheme, but testing has been going very well and controls are starting to work exactly as intended.

The attachment muntvsti timbre editor.png is no longer available

It's built in Delphi and is currently only a Timbre Editor and only edits the instruments of the Timbre Temp Area (though it is multi-timbral so you can edit all 8 Parts separately). It currently doesn't go into the Patch Temp Areas or Rhythm Setup, Patch Memory, Timbre Memory, or System Area. But I do plan to extend its functionality later into a full MT-32 system editor so you can access every part of the MT-32. It's designed to stay in sync with MuntVSTi's internal memory which makes this the only way thus far that I have found to be able to receive data FROM Munt and not just send data to it via sysex (MUNT currently still has no MIDI output). Which means, as well as being a useful tool for composers and producers in a DAW setting, this could be a viable way to extract MT-32 sysex banks from games without needing an actual hardware MT-32.

This is in no way intended to step on the toes of sfryers and replace his wonderful MT-32 editor (programmed in .NET), which I've used very often! But it's long overdue that we have a patch editor with a fully integrated MUNT core as a viable VSTi plugin for DAWs so producers can customize their MT-32 sounds much more easily. When it gets to a functional state, I will be releasing it with the source on Github. For now, here's a sneak peek.

Hi, I have just replied to be able to get notifications on updates from this topic.
BTW, it's nice work and I do not think it's ugly. The only 'ugly' thing for me is the Windows 10/11 specific 'blue' handlers on trackbar controls but it's only personal taste.

Website, Youtube
Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
VST Midi Driver Midi Mapper
x86 microarchitecture benchmark (MandelX)

Reply 2 of 4, by MusicallyInspired

User metadata
Rank Oldbie
Rank
Oldbie
Falcosoft wrote on Yesterday, 04:52:

Hi, I have just replied to be able to get notifications on updates from this topic.
BTW, it's nice work and I do not think it's ugly. The only 'ugly' thing for me is the Windows 10/11 specific 'blue' handlers on trackbar controls but it's only personal taste.

Yeah. It would be nice to be able to colour code it how you wish. Perhaps a theme setting. But eventually I'll be replacing everything with graphics anyway....maybe.

Since you're here, I've been thinking ahead. One common element of VST plugins is the ability to map MIDI CCs to VST settings in a DAW (and sometimes standalone). Would there be any way for MuntVSTi to add VST control triggers that the Timbre Editor could hook into and map to so they could be controlled in the same way? I know digital synths controlled by sysex do not behave the same as a standard synth because when you send sysex to the MT-32 the changes don't always take effect until a new note is sounded. And sometimes a sysex timbre message can actually silence a note. But I still think it would be worth implementing.

Like I said, it's a future thing to worry about, but I can definitely see this being requested.

MT-32 Editor VSTi (wip)
FB-01 tools
Github
SC-55 Packs

Reply 3 of 4, by Falcosoft

User metadata
Rank l33t
Rank
l33t
MusicallyInspired wrote on Yesterday, 05:33:
Yeah. It would be nice to be able to colour code it how you wish. Perhaps a theme setting. But eventually I'll be replacing ever […]
Show full quote
Falcosoft wrote on Yesterday, 04:52:

Hi, I have just replied to be able to get notifications on updates from this topic.
BTW, it's nice work and I do not think it's ugly. The only 'ugly' thing for me is the Windows 10/11 specific 'blue' handlers on trackbar controls but it's only personal taste.

Yeah. It would be nice to be able to colour code it how you wish. Perhaps a theme setting. But eventually I'll be replacing everything with graphics anyway....maybe.

Since you're here, I've been thinking ahead. One common element of VST plugins is the ability to map MIDI CCs to VST settings in a DAW (and sometimes standalone). Would there be any way for MuntVSTi to add VST control triggers that the Timbre Editor could hook into and map to so they could be controlled in the same way? I know digital synths controlled by sysex do not behave the same as a standard synth because when you send sysex to the MT-32 the changes don't always take effect until a new note is sounded. And sometimes a sysex timbre message can actually silence a note. But I still think it would be worth implementing.

Like I said, it's a future thing to worry about, but I can definitely see this being requested.

Well, it would be a more tedious work to expose all editor controls as VST parameters and also it would require to extend the communication interface. What's more this kind of practice is more logical in case of plugins that do not react to Midi CC messages otherwise. But an emulator synth/plugin like Munt VSTi actually reacts to Midi CC messages like a normal synth so there is the problem of what should happen if you define overlapping settings.
Another problem is that I envisioned the editor plugin as an optional one so I do not need to maintain 2 versions of the main plugin. But VST parameters are fixed and cannot be modified runtime. So when the editor plugin is not present or cannot be loaded (notice that the 32-bit Munt VSTi plugin itself supports even Win9x, Win2000, Win XP that most likely will not be true for your editor plugin) then the fixed exposed parameters could cause troubles.
So maybe it could be added in the long run but I d not think this will be implemented in the 1st version.

Website, Youtube
Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
VST Midi Driver Midi Mapper
x86 microarchitecture benchmark (MandelX)

Reply 4 of 4, by MusicallyInspired

User metadata
Rank Oldbie
Rank
Oldbie

Yeah, I figured as much. It makes sense that those controls not respond to CC given that they won't always alter that timbre in real time anyway as I mentioned before. I think it's probably fine if it never does.
Actually, I believe this is why so many timbre settings can be tied to note velocity so that the harder you hit a note the more you change its sound. Kind of like a hacky way to simulate analog synth behaviour. If you have a loop of MIDI notes and you gradually change the velocity of those notes as it's playing it would give a similar effect. Though, it would only work on retriggered notes for the most part and not sustained notes.

Anyway, thanks for your insight!

MT-32 Editor VSTi (wip)
FB-01 tools
Github
SC-55 Packs