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.