I made a video that shows how I use it - and the problems described above, including the mentioned "clicks" that I get instead of the real sound: https://youtu.be/4SMRV_loNSQ
First, I start the editor and try to play something, but you just hear this "click". Then I start the Munt panel - I initially just wanted to use it to see what´s going on with the virtual MT-32 or get a clue why it is not working; so, in fact, I don´t need the Munt panel itself. In the second part, I first start the Munt panel and then the MT-32 editor. In the last part, I load the Willy Beamish syx into the MT-32 editor (Munt panel not running), but here also just a clicking sound. In the end, I forgot to demonstrate playing the MT-32 sound with the Munt panel, so it should not be a Munt installation problem, but just believe me, that it works 😉

Order of operations is important.

Start the MUNT interface *first*
Then MT32Edit
Then add your external MIDI interface to MUNT.

I think, this is exactly what I did in my second part of the video, starting at 0:45. But as you can see, the Munt panel is refreshing all the time.

You're right. I think there's something wrong with how MT-32 Editor is opening and holding it's MIDI connection to MUNT.

Using LoopMIDI as I described a few posts ago I'm able to get what I think is a working arrangement, but I don't have any kind of MIDI keyboard to test with.

To Elaborate, I'm running

* MUNT - Tools -> New MIDI Port -> loopMIDI port.
* MT-32 Editor with MIDI Out set to loopMIDI port and Hardware MT-32 Connected enabled
* MidiPlayer5 (in lieu of a keyboard) set to output to loopMIDI port.

@SkyHawk, thanks for your hints, I really got it working like this, having set midi-in in the MT-32 Editor to my "real" midi-in.

It would be interesting nevertheless why I cannot access the MT-32 midi driver directly because I believed that the munt panel is just something like a monitor for the mt-32 driver, not something that really enables using it, because Dosbox games set to mt-32 also played music without having the panel opened.

The editor is already really great, just my first 2 feedbacks:
- Would it be possible to change the "Editing Partial No." setting to radio buttons? Because with radio buttons, you need one click, with a dropdown, you need two...
- Enabling and disabling the reverb switches from the edited sound to a preset sound, so you have to manually select the edited sound again on the left side

JK1974 wrote on 2023-04-22, 22:58:

It would be interesting nevertheless why I cannot access the MT-32 midi driver directly because I believed that the munt panel is just something like a monitor for the mt-32 driver, not something that really enables using it, because Dosbox games set to mt-32 also played music without having the panel opened.

I think this is related to the behavior you observed with MUNT "blinking on and off". Unless the MUNT frontend is running, each new MIDI connection to MUNT will spawn a new MUNT instance. The moment that MIDI connection is closed, the MUNT instance is destroyed.

MT32Edit appears to be constantly closing and re-opening it's MIDI connection, hence the MUNT driver is constantly creating and destroying instances.

That's also how I understand it. I guess, the editor opens the MIDI port, sends something, then immediately closes the port. By default, each MIDI connection is served by a separate synth in mt32emu-qt. For added flexibility, there is also a pinned synth mode, as I said above. When enabled, one synth will work with several consecutive MIDI connections and retain its state in between.

However, I also think the editor should rather keep the port opened, because opening/closing a MIDI port in Windows takes time, even a virtual port, for some unknown reason.

Thanks all- I suspect JK1974's issue is a result of the 0xFE Active Sense messages from the SY99, coupled with the fairly rudimentary way my program handles MIDI In data. Neither of my MIDI keyboards (one of which, a Roland JV-35, is a similar vintage to the Yamaha) appear to implement Active Sense, so I've not seen this particular behaviour before.

The MIDI code was the first part of the editor I implemented- I got it working 'well enough' at the start of the development process and haven't really come back to it since then. The MIDI In routine is very basic, and just acts as a MIDI Thru by copying any data received on the MIDI In port directly to the MIDI Out port. It switches the MIDI Out connection off after each message to avoid clashes between the MIDI Thru data and the generated SysEx messages- which is evidently not standard MIDI behaviour.

I'll take another look at the MIDI routines and see how I can avoid any data clashes whilst keeping the port open.

I've published an updated build, v0.9.3a (see link in original post).

This version keeps the MIDI connections open so should improve compatibility with MUNT. Let me know if there are still any issues with MIDI devices which use Active Sense.

Hmm, not sure why active sense is related at all. It is an optional feature, and any conforming device should only engage this function once it receives the Active Sense message. FYI, mt32emu does not emulate this either, but we provide a callback in the library, so the client application might reset the synth when it detects a connection failure.

Prior to v0.9.3a, MT-32 Editor was initialising and then discarding the virtual MIDI connection each time a MIDI data packet was received from the MIDI In port. I suspect the Active Sense messages from the SY99 may have been triggering this initialisation/discard process multiple times per second for as long as the MIDI device was connected and idle.

JK1974 wrote on 2023-04-22, 22:58:

The editor is already really great, just my first 2 feedbacks:
- Would it be possible to change the "Editing Partial No." setting to radio buttons? Because with radio buttons, you need one click, with a dropdown, you need two...

Good suggestion, I'll change this in the next build.

- Enabling and disabling the reverb switches from the edited sound to a preset sound, so you have to manually select the edited sound again on the left side

This is a bit complicated to fully resolve. The MT-32 stores the reverb on/off setting (along with key shift, fine tune, bend range etc.) as part of the patch memory area, not the timbre memory area. There isn't a 1-to-1 connection between the two memory areas, as you can have memory timbres which are not allocated to any patch, and also memory timbres which are allocated to more than one patch. The MT-32 also has 8 temporary patch memory areas which could potentially be used to hold patch settings for some of the most recently-edited timbres, but I think trying to make use of these will just end up making the interface more confusing.

I will try to make it work so that when a memory timbre is selected from the list on the left side, an attempt is made to automatically select the corresponding patch on the right side- but this will only succeed if there actually is a patch which is configured to use that memory timbre.

sfryers wrote on 2023-04-23, 14:27:

Prior to v0.9.3a, MT-32 Editor was initialising and then discarding the virtual MIDI connection each time a MIDI data packet was received from the MIDI In port. I suspect the Active Sense messages from the SY99 may have been triggering this initialisation/discard process multiple times per second for as long as the MIDI device was connected and idle.

My physical MIDI interface, which is picked up by MT32Edit as default, has nothing connected to it yet I was seeing the same closing-and-opening connections to MUNT as JK1974.

That said, 0.9.3 does seem to correct the issue!

Hi, also positive Feedback from my side: Works now via direct MIDI input to the MT-32 Editor as well when I have started Munt beforehand - no eternal resets and cut notes anymore. Thanks a lot!

Good to know the latest update is working better! Thanks for testing and let me know if you have any more feedback.

Updated build v0.9.4a is now available- please see my original post. This update includes some minor bug fixes along with JK1974's suggested UI improvements.

I've published an updated build v0.9.5a, which is DPI-aware and should display correctly on systems where Windows Display Scaling is set to a value other than 100%.

There are no changes to the core functionality. Please see my original post for download links.

Hello,

As a long time (+10 years) C# dev, there is an issue with the code -> Windows forms code-behind files which contain business logic within them.

I've been there and done that. It leads to an application development experience that is not fun, since there are too many moving parts, and UI logic is mixed with business logic.

It's much better to use the MVVM pattern (along with bindings), but that means AvaloniaUI or WPF instead of WinForms.

This pattern, along with interfaces and SOLID principles, allows for unit tests and dependency injection.

Meaning: code that can move FAST and be refactored without any fear.

WPF/AvaloniaUI are quite different from Winforms, but worth it in the end. I might send a PR, since I need to study Dune's MT-32 driver, and the MT-32 itself...

Also, this uses .NET 6, which is cross-platform. The UI could be cross-platform (if AvaloniaUI is used). What other obstacles would be present ? Are there native MIDI functions used, such as WinMM ?

(I'm using Linux)

edit: also both wpf and avaloniaui have no issues at all with DPI, unlike WinForms.
edit2: to get filenames, extensions, and to combine paths, you can use Path.GetFilename, Path.GetExtension, and Path.Combine
edit3: For MIDI, there are cross-platform libs, such as PortMIDI, or C# libs, such as DryWetMIDI. One problem would be regression testing, I'd need to have MUNT on Linux first.

Hi xcomcmdr,

Thanks for the feedback. I'd never written a line of C# before I started this project in January this year, so it's been a huge learning experience for me. I chose to develop using WinForms as, despite its shortcomings, I had some prior experience of it from tinkering with Visual Basic many years ago- which meant I didn't feel like I was starting completely from scratch.

My current plan is to fix a couple of minor outstanding bugs in the current code and issue a v1.0 release later this month. There have been a couple of requests for a cross-platform version or a version which will run on Windows releases older than Windows 7. Now that I'm getting more comfortable with C#, I think my next goal (when I manage to find the time!) will be to look at doing a cross-platform update. Looks like I'll need to:

• Refactor the code base to properly separate out the UI and business logic elements.
• Replace the current Windows-only MIDI library (naudio.midi) with one with cross-platform support.
• Either re-implement the UI in AvaloniaUI, or maybe just see if I can alter any of the current WinForms elements which prevent it from working with Mono
• Potentially look at using an older .NET version in order to get Windows 98 and XP support, however I'm aware that going down that route might end up making modern cross-platform compatibility harder to accomplish.