I was using MUNT (the mt32emu_qt GUI interface). Haven't tried with my hardware MT-32 yet because I cannibalized the cables I use to connect it to my interface in favour of my guitar pedalboard connections I was experimenting with. I will hook it back up perhaps tonight and see if it continues.

EDIT: Side note, you probably don't have plans for this but this would be amazing as a VSTi plugin. 😀

MusicallyInspired wrote on 2024-04-12, 13:26:

I was using MUNT (the mt32emu_qt GUI interface). Haven't tried with my hardware MT-32 yet because I cannibalized the cables I use to connect it to my interface in favour of my guitar pedalboard connections I was experimenting with. I will hook it back up perhaps tonight and see if it continues.

I'm really not sure what could be causing this issue for you. Before you confirmed that you're using MUNT, I suspected it might have been down to a flaky USB MIDI interface. I've been using both MUNT and Roland hardware throughout the development process; other than an issue in the early releases where virtual MIDI connections were being constantly closed and reopened, it's all been working pretty well.

It's good news that the .NET 4.7.2 version works for you, but it's going to be tricky to figure out why that version does but the .NET6.0 version doesn't. The code for the .NET6.0 and .NET4.7.2 versions is almost identical aside from five or six lines of code- in fact some of the work I've been doing for the next release has involved making it possible to compile either version from a single code base by using some compile-time IF statements. Still, other than the slightly more polished look of the .NET 6.0 release, you're not missing out on any functionality with the .NET 4.7.2 version.

EDIT: Side note, you probably don't have plans for this but this would be amazing as a VSTi plugin. 😀

I've not spent much time looking into VST plugins, however I believe the development platform I've chosen for this project (C#/.NET/WinForms) is not well-suited for that purpose.

Version 0.9.9b is now available- please see the link in my original post.

This version includes an undo/redo feature within the timbre editor section. I don't plan on adding any further new features ahead of v1.0.0, so I've marked this release as a beta.

sfryers wrote:

I've not spent much time looking into VST plugins, however I believe the development platform I've chosen for this project (C#/.NET/WinForms) is not well-suited for that purpose.

Actually, it is suited. There are two paths:

- entry points for native callers, but your code remains compiled to machine code from the IL (bytecode) at runtime. Manageable.
- compile your code to native code. This is called NativeAOT. Doable, but it can be a pain in the butt. Especially with WinForms. Although it can be done. The entire project will have to be compiled to NativeAOT. You can't reference NativeAOT assemblies from IL assemblies and vice-versa.

Some more explanations:

If VSTi plugins must be compiled to machine code (and not bytecode, as the vast majority of .NET projects are), you can expose end points to native code callers, and then let this do its magic: https://github.com/AaronRobinsonMSFT/DNNE

DNNE lets you use the UnmanagedCallersOnlyAttribute outside of a NativeAOT scenario.

This avoids having to compile your project as native (with Native AOT), which is currently limited (it introduces trimming, and limits the capabilities of some reflection APIs and other APis, and it can make your code behave differently. New warnings will have to be taken into consideration carefully!)

With the first solution, your project stays fully managed, you only introduce endpoints for native code, and a Nuget (DNNE) package to your code base. Hurrah! 😀

Some links of interest:

https://github.com/dotnet/runtime/issues/90126
https://joeysenna.com/posts/nativeaot-in-c-plus-plus
https://devblogs.microsoft.com/dotnet/improve … rop-in-net-5-0/

And the other way around can be done too. If from your .NET code, you have to call native ABIs, this is done with P/Invoke:
https://learn.microsoft.com/en-us/dotnet/stan … interop/pinvoke
https://github.com/microsoft/CsWin32
https://learn.microsoft.com/en-us/dotnet/stan … urce-generation (this last link talks about a recent new attribute that replaces DllImport for better performance)

Nice. Although, it would also have to have MUNT compiled into it as well to be useful as a VSTi since it doesn't output sound on its own.

Currently I use Falcosoft's MUNT VSTi plugin which is fantastic. But having timbre editing tools built in to a MUNT VSTi as well would be the icing on the cake. Especially (and ironically) for Cakewalk because it cannot send sysex to VSTis for no good reason at all. They just never bothered to implement that.

xcomcmdr wrote on 2024-04-13, 15:39:

Actually, it is suited. There are two paths:

Thanks- lots of new (to me) concepts to consider!

MusicallyInspired wrote on 2024-04-13, 17:24:

Nice. Although, it would also have to have MUNT compiled into it as well to be useful as a VSTi since it doesn't output sound on its own.

Currently I use Falcosoft's MUNT VSTi plugin which is fantastic. But having timbre editing tools built in to a MUNT VSTi as well would be the icing on the cake. Especially (and ironically) for Cakewalk because it cannot send sysex to VSTis for no good reason at all. They just never bothered to implement that.

It would definitely be useful to have a plugin with similar functionality to Dexed but using the MT-32 engine. I use the modern Cakewalk from time to time and hadn't actually noticed the VSTi SysEx limitation. I've always either been using a hardware MT-32 or Falcosoft's MUNT VSTi set up as a MIDI device, both of which allow me to use SysEx without any problem.

For their simple layout and lack of clutter, I prefer using the 1990s versions of Cakewalk for pure MIDI projects- but that might be the nostalgia talking!

Luckily, Falcosoft implemented a drag-and-drop solution for SYX files in the MUNT VSTi which works very well when used in Cakewalk. But still. Editing the timbres with MT32 Editor, saving, and redragging the SYX to the VSTi is just a couple extra steps when it could be much more streamlined.

But don't feel pressured to take on something you're not ready for yet! Just having a librarian software that works at all in modern Windows without OTVDM or DOSBox is a godsend! You've already made things twice as easy. 😀

MusicallyInspired wrote on 2024-04-17, 15:15:

But don't feel pressured to take on something you're not ready for yet! Just having a librarian software that works at all in modern Windows without OTVDM or DOSBox is a godsend! You've already made things twice as easy. 😀

Good to know it's proving useful! No pressure at all- I'll continue to muddle along at my own pace and see what works out.

On a separate note, I've managed to build a test version for .NET4.0, which seems to run without any major problems on my Windows XP SP3 machine. Apart from the UI not being designed to fit on a sub-1080p display, the only functional issue I've found with this build is that when changing to a different timbre, you need to click on the Refresh button in order to properly update the MIDI device.

This didn't actually require many changes to the code, other than adapting the Midi class to interface with an older library, Sanford.Multimedia.Midi, in place of NAudio.Midi. Even though .NET4.0 doesn't officially support C# version 10, it compiles without too many complaints.

I've made some refinements to the .NET 4.0 build, including shrinking the UI to fit 1024x768 and 1280x720 displays whilst retaining the full functionality of the main .NET 6.0 version.

I've also fixed a bug in the previous test version where MIDI Out connections were not being properly closed upon exiting the application.

Due to .NET overheads, the app occupies around 200Mb of RAM, which may be an issue for some older systems.

Screenshots of the 'legacy' version running on a Windows XP SP3 system (Pentium 4 with 1GB RAM) at 1024x768:

sfryers
Thank you!
This very good what you make version for Windows XP ) I think what people really missed this application , now you give people feature use old PC with MT-32 hardware module )
You well done

But , you can make portable version for all Windows ? I meen what create MT-32 Editor with VMware ThinApp including libs in one exe file ?
I try do this , but nothing can not make if I make in Windows 7 and then move result file to Windows XP without Microsoft Net 4 , my result not working in Windows XP , if I make in Windows XP with Net Framework 4 and then I uninstaling Microsoft Net 4 and want use as portable version , I not can not use as I want , why ?
My goal make portable version with minmum size and all what do need for work )
for example , this version work in all Windows 7 without Net Framework 4.7.2 https://disk.yandex.ru/d/vqG0uPVZj7GiCw , as make the same legacy version ?

Roland User wrote on 2024-05-09, 01:49:

But , you can make portable version for all Windows ? I meen what create MT-32 Editor with VMware ThinApp including libs in one exe file ?

I'm sure it would be technically possible to do this, but the current version of VMWare ThinApp doesn't support Windows XP and I don't think there's any way to legally obtain the older versions. If anyone has the appropriate software licence, I'm happy for them to convert MT32 Editor- however, as VMWare's products seem to be designed for large corporations, this seems unlikely.

Why do you dislike having .NET installed? .NET 4.0 only takes up around 50Mb of disk space, which isn't much even on a Windows XP system. I might try making a .NET 2.0 build for additional compatibility with older Windows systems, but that will require backporting all the code to C# version 7.3.

sfryers wrote on 2024-05-09, 16:41:

Why do you dislike having .NET installed? .NET 4.0 only takes up around 50Mb of disk space, which isn't much even on a Windows XP system. I might try making a .NET 2.0 build for additional compatibility with older Windows systems, but that will require backporting all the code to C# version 7.3.

Beause this make synth pack bigger , and I and I would like this not do , I like compact versions applications , because I make portable version )
By the way If you will be study my version for compile in VMware ThinApp your older application , so you see what despite the need NET 4.7.2 , for run and compile I add only those parts of it whitch real need , all other components from NET 4.7.2 was be removed )
That's why you can say which ones exactly components , directories and files need for run your version , and I will try make portable version )
Size diffirence verys large , when include only so what need size ~40 MB , but if do full image with all components size ~ 400 MB
And it's just not reasonable do one file for run MT-32 Editor legacy on 400 MB if possible make version 40-50 MB )

I've managed to produce a build for .NET Framework 2.0. This was easier than I expected as it didn't actually require regressing the code to C# 7.3; all I needed to do was to disable implicit usings in the project file, add explicit usings to each class, and re-implement the method 'IsNullOrWhitespace', which doesn't exist in this framework version.

This build reduces total memory usage to around 130Mb, which should be helpful on older systems, in addition to the framework installation having a smaller disk space requirement. Whilst .NET Framework 2.0 is, in theory, compatible with Windows 98, this build doesn't seem to like it (the console window opens up but the UI never appears). I am hopeful that it will work on Windows 2000 or XP SP2 and below, but I haven't tested it yet. It works fine on XP SP3.

Roland User wrote on 2024-05-09, 17:08:

That's why you can say which ones exactly components , directories and files need for run your version , and I will try make portable version )

If it's any help to you, the application uses the following .NET Framework components:

1System
2System.Collections.Generic
3System.Drawing
4System.IO
5System.Text
6System.Threading
7System.Windows.Forms
8Sanford.Multimedia.Midi

Thanks!
Maybe I'm alone with this opinion but I like the resizeable UI of the legacy versions better than the fixed size UI of the .NET 6 version even on full HD monitors. I can maximize the main window of the legacy versions when all controls are needed but when I want to interact with other porograms I can set the main window to normal size which is better than moving the large window of the .NET 6 version out of the way.

Just wanted to say thanks for this! I recently modified my Roland RA-50 to add the CM-32L sample ROM. There's some weird quirk that hasn't yet been figured out where the CM-32L module in the unit doesn't map the CM-32L samples to keys on channel 10. By using MT-32 Editor, I manually re-mapped the sounds and created a SysEx file - I can load this to restore the CM-32L samples to their correct place. Thanks!

Just finally used this for the first time tonight. Thank you, @sfryers!! It is incredibly useful being able to load a game SysEx and see things like whether a patch has reverb enabled, what pitch bend setting it uses, and so on. Incredible stuff!

I do have one question about the Rhythm Area. The CM-32L sound effects are listed in pretty much every rhythm patch list, even for MT-32 intended SysEx - does that mean the timbre banks were programmed that way, or does it just reflect the numbers that those positions correspond to and where they're used? It would be useful in any case to have a toggle to hide them, so if you're using a MT-32 (or variant without PCM SFX), you can quickly switch it "off" and see that certain notes won't translate to a sound effect, it'll be "Nothing" and effectively muted.

sfryers
Thank you well done!
The only drawback I found , this is what can not save window size and window position in ini file

If use pure Windows XP as is without all , only Install and run in this system MT-32 Editor Legacy - not possible usage ) need Net 2.0 whitch absent in pure version Windows XP SP3 )
Previously I thinked what Windows XP SP3 include Net 2.0 , but I was wrong
There is one more want ) all good ) but as to hear result with create patch ? Please if you not hard add patch play button ) this need for what to hear result
I mean add button play or button speaker for output channel 2 L/A synh because not everyone has it piano or midi conroller on midi synthesizer
For example , I offer do as in SCVA when select channel and instrument , and if hold left mouse button , we be hear sound of select instrument ) so I offer do and in MT-32 Editor, only output to MIDI out port

It seems something is lost

Thanks all- some great suggestions here. I've made an updated 'legacy' .NET2.0 build incorporating some of these requests:

Falcosoft wrote on 2024-05-10, 19:06:

Maybe I'm alone with this opinion but I like the resizeable UI of the legacy versions better than the fixed size UI of the .NET 6 version even on full HD monitors.

It'll be easy enough to add the additional code elements into the main .NET 6 version. It won't resize quite so small as the legacy version as I want to retain the full size slider controls. The half-size sliders in the legacy version are a compromise for small display sizes- as a result, small value adjustments can only be made by using the cursor keys.

RichB93 wrote on 2024-05-10, 23:19:

By using MT-32 Editor, I manually re-mapped the sounds and created a SysEx file - I can load this to restore the CM-32L samples to their correct place. Thanks!

Good to see the app is proving useful in ways I'd never have considered!

Spikey wrote on 2024-05-11, 16:11:

I do have one question about the Rhythm Area. The CM-32L sound effects are listed in pretty much every rhythm patch list, even for MT-32 intended SysEx - does that mean the timbre banks were programmed that way, or does it just reflect the numbers that those positions correspond to and where they're used? It would be useful in any case to have a toggle to hide them, so if you're using a MT-32 (or variant without PCM SFX), you can quickly switch it "off" and see that certain notes won't translate to a sound effect, it'll be "Nothing" and effectively muted.

This was something I spent quite a bit of time thinking about in the early development phase. Ultimately, MT32 Editor has no idea what type of device is connected to the selected MIDI Out port- it'll happily send out MT/CM SysEx data regardless of whether a compatible device is present. As sending CM-32L-specific data to an original MT-32 doesn't cause anything particularly bad to happen, I chose to implement MT32 Editor's default memory configuration to reflect the extended CM-32L layout.

Loading a rhythm bank intended for the MT-32 to a hardware CM-32L does leave the default SFX samples in place on the high keys which are beyond the upper extent of the MT-32's rhythm bank memory- MT32 Editor's behaviour is very similar in this respect. A point that I've not fully explained in the documentation is that when you load an externally-created SysEx file into MT32 Editor, what you see in the application is not always a 1-1 copy of what's in the file- some data such as temporary timbre/patch commands, or any non-MT/CM SysEx commands, is ignored completely. Conversely any 'missing' data such as undefined/invalid patch and rhythm key data is simply replaced by the default CM-32L memory values. For this reason, I'd recommend not saving over any .syx files which weren't created by MT32 Editor as you'll end up losing any parts of the data which MT32 Editor doesn't understand.

I'll have a think about your request, but it would need to be implemented carefully to avoid any undesirable/unexpected behaviours- eg. should the CM-32L-specific data values still be saved to file if they were optionally hidden in the UI? If not, we probably need a warning that any CM-32L specific data is about to be lost. A potentially safer option might be to show any CM-32L-specific components (ie. the extended rhythm bank area and the PCM bank 2 samples) in a different colour in the UI to emphasise that an original MT-32 (or Munt with an MT-32 ROM loaded) won't be able to make use of them.

Roland User wrote on 2024-05-11, 20:48:

sfryers Thank you well done! The only drawback I found , this is what can not save window size and window position in ini file […]
Show full quote

sfryers
Thank you well done!
The only drawback I found , this is what can not save window size and window position in ini file

If use pure Windows XP as is without all , only Install and run in this system MT-32 Editor Legacy - not possible usage ) need Net 2.0 whitch absent in pure version Windows XP SP3 )
Previously I thinked what Windows XP SP3 include Net 2.0 , but I was wrong
There is one more want ) all good ) but as to hear result with create patch ? Please if you not hard add patch play button ) this need for what to hear result
I mean add button play or button speaker for output channel 2 L/A synh because not everyone has it piano or midi conroller on midi synthesizer
For example , I offer do as in SCVA when select channel and instrument , and if hold left mouse button , we be hear sound of select instrument ) so I offer do and in MT-32 Editor, only output to MIDI out port

Good suggestions! The latest legacy build has a new item in the options menu, "Save window size and position". When selected, it will restore the previous window settings the next time you run the application. There's also now a green 'play' button on the main menu bar which will send a Middle C to channel 2 of the connected MIDI Out device. I'll add these features to the main .NET 6 version in the next build. Unfortunately, I don't think any versions of Windows prior to Vista were shipped with a .NET framework installed by default.

Roland User wrote on 2024-05-12, 00:03:

It seems something is lost

Yes, I had to remove the graph parameter drawings to get the legacy interface to fit on a 1024x768 display. I've now replaced these graphics in a separate window- select 'Help->Envelope Diagrams' to see them.