sfryers wrote on 2024-01-05, 18:02:

Hi all, […]
Show full quote

Hi all,

I was planning to do some further updates last Autumn but it's ended up being a very busy few months. I'm happy to make an x86 build of the app, but I'll only be able to test it on a 64-bit OS.

Falcosoft wrote on 2024-01-04, 22:37:

1. The attached SysEx dump from the DOS game Operation Stealth that contains valid MT-32 SySex messages throws an unhandled exception (index was outside the bounds of the array) when I try to load it.

That's a really strange SysEx file- thanks for sharing! Inspecting it with MIDI Tools shows that the 18th sysex message is missing a checksum byte- removing this message from the SysEx file prevents MT32Editor from crashing but it can still only recognise one of the 42 timbre definitions which appear in the file. Below the timbre definitions there are a large number of patch definitions which seem to repeat over and over again for no purpose. I'll have a look at the code this weekend and see if I can get it to do a better job of interpreting this file without crashing.

Falcosoft wrote on 2024-01-04, 22:37:

2. If the current directory is changed by a driver/operation then the save file (MT32Edit.ini) is saved to the arbitrary path that is the actual current directory and not to the start up directory where MT32Edit.exe can be found.

Not quite sure how to duplicate this bug, but it'll be an easy fix to detect the directory at start-up and make sure the .ini file is always saved there.

1. Yes, an x86 release would be great. I do not think that testing it on a real 32-bit OS is necessary.

2. These are only the SysEx messages and the game itself does not load all of them at once. Between the SysEx messages the game sends many short Midi messages that actually result in effects/sounds. The whole sequence is played during the intro that is many minutes long. If it helps I can send you the whole Midi dump of the intro together with short/channel and long/SysEx messages with proper timings.

3. The easiest way to replicate this bug is to create a shortcut to MT32Edit.exe but set the start-up location ("Start in" field of the shortcut) to some different directory and then change one of the Midi In/Out ports after the app is started (by using the shortcut). You will see that the ini file will be created in the "Start in" directory instead of MT32Edit.exe's own directory. You can also create a bat/cmd file with the same logic for testing.
So I suggest that instead of detecting the current directory at start-up (the current directory can be different from MT32Edit.exe's own directory right at the beginning) you should query the exe/assembly path instead before loading/saving the ini file.

sfryers wrote on 2024-01-05, 18:02:

Hi all,

I was planning to do some further updates last Autumn but it's ended up being a very busy few months. I'm happy to make an x86 build of the app, but I'll only be able to test it on a 64-bit OS.

I can test x86 version on Windows 7 x86 SP1 )

I've now published an updated version 0.9.6a- see the link in my original post.

This release includes both x86 and x64 binaries, although I might not publish an x64 build in future if there are no advantages over the x86 version.

Falcosoft wrote on 2024-01-05, 22:18:

2. These are only the SysEx messages and the game itself does not load all of them at once. Between the SysEx messages the game sends many short Midi messages that actually result in effects/sounds. The whole sequence is played during the intro that is many minutes long. If it helps I can send you the whole Midi dump of the intro together with short/channel and long/SysEx messages with proper timings.

That explains the weirdness! The new release can now open this SysEx file and load all the timbres within it. The repeated patch change messages are targeted at the temporary patch memory area, which MT32Editor makes no attempt to interpret.

Falcosoft wrote on 2024-01-05, 22:18:

3. The easiest way to replicate this bug is to create a shortcut to MT32Edit.exe but set the start-up location ("Start in" field of the shortcut) to some different directory and then change one of the Midi In/Out ports after the app is started (by using the shortcut). You will see that the ini file will be created in the "Start in" directory instead of MT32Edit.exe's own directory. You can also create a bat/cmd file with the same logic for testing.
So I suggest that instead of detecting the current directory at start-up (the current directory can be different from MT32Edit.exe's own directory right at the beginning) you should query the exe/assembly path instead before loading/saving the ini file.

The new release checks the exe/assembly path and will now always read and write the .ini file to this location regardless of the "Start in" directory setting.

Roland User wrote on 2024-01-06, 10:05:

I can test x86 version on Windows 7 x86 SP1 )

Thanks- let me know if there are any issues.

Thanks,
I can confirm that the new x86 build can enumerate/handle 32-bit only ports and also handles the Operation Stealth SysEx dump properly. The ini file saving proplem also seems to be solved.

This release includes both x86 and x64 binaries, although I might not publish an x64 build in future if there are no advantages over the x86 version.

Although I have not met 64-bit only ports so far in theory they can exist and in the future they can be the norm. So if making both x86 and x64 builds is not too complicated then I think this would be the best release standard.

It seems so as now do , 32 bit version not workable , this version need NET 6.0 for Windows 7 x86 and not runned if install this addon , also this not fixable if install Windows6.1-KB2999226-x86 , I not know why so.
What is the difficulty compiling on NET 4 or older ?

Roland User wrote on 2024-01-07, 15:51:

It seems so as now do , 32 bit version not workable , this version need NET 6.0 for Windows 7 x86 and not runned if install this addon , also this not fixable if install Windows6.1-KB2999226-x86 , I not know why so.
What is the difficulty compiling on NET 4 or older ?

And the new x64 version of 0.9.6a still runs on your Windows 7 x64?
And what happens if you run the new x86 version on your Windows 7 x64?

Falcosoft wrote on 2024-01-07, 16:02:

And the new x64 version of 0.9.6a still runs on your Windows 7 x64?
And what happens if you run the new x86 version on your Windows 7 x64?

Both versions work on Windows 7 x64 , but not work on Windows 7 x86

I can not understand , why autor share only exe file and not share required libarys for run exe file )
as I understand , if have required in library , so necessary include need required library in software

Roland User wrote on 2024-01-07, 15:51:

What is the difficulty compiling on NET 4 or older ?

Apart from the need to remove any .NET 6 and C# 10-specific features from the code base, the MIDI interface currently relies on the NAudio.midi library, which isn't compatible with .NET Framework 4.0.

I don't plan on making any major changes to functionality ahead of version 1.0. For future versions, I'd be more interested in achieving modern Linux/Mac/Windows cross-platform compatibility, rather than backward compatibility with older Windows versions. There is a GUI-based SysEx utility called SoundDiver from the early 2000s which apparently works well as an MT-32 editor on Windows PCs of that era.

sfryers wrote on 2024-01-07, 17:16:

Roland User wrote on 2024-01-07, 15:51:

What is the difficulty compiling on NET 4 or older ?

Apart from the need to remove any .NET 6 and C# 10-specific features from the code base, the MIDI interface currently relies on the NAudio.midi library, which isn't compatible with .NET Framework 4.0.

I'm not a .NET expert but I have heard about NAudio when .NET core not even existed. So I would be surprised if some older versions of NAudio had no support for .NET framework at all.
According to its nuget page even the current version still supports .NET Framework 4.7.2 and 4.8
https://www.nuget.org/packages/NAudio/

Roland User wrote on 2024-01-07, 16:42:

I can not understand , why autor share only exe file and not share required libarys for run exe file )
as I understand , if have required in library , so necessary include need required library in software

The .NET ecosystem never worked this way. The legacy .NET Framework 4 had no app local library support either. You had to install the .NET Framework runtime separately in order to run your program on earlier Windows versions.

Falcosoft wrote on 2024-01-07, 17:49:

The .NET ecosystem never worked this way. The legacy .NET Framework 4 had no app local library support either. You had to install the .NET Framework runtime separately in order to run your program on earlier Windows versions.

Yes , but not so curve... NET Framework install and work , now if I Install NET components , I still have problem on x86 version Windows ) , but if I install components on Windows x64 I can free run both version without errors.
As example can bring XnConvert 1.90 , in this application saming have components from NET new version , but this components include application and not requesting add from outside

Roland User wrote on 2024-01-07, 18:10:

Falcosoft wrote on 2024-01-07, 17:49:

The .NET ecosystem never worked this way. The legacy .NET Framework 4 had no app local library support either. You had to install the .NET Framework runtime separately in order to run your program on earlier Windows versions.

Yes , but not so curve... NET Framework install and work , now if I Install NET components , I still have problem on x86 version Windows ) , but if I install components on Windows x64 I can free run both version without errors.
As example can bring XnConvert 1.90 , in this application saming have components from NET new version , but this components include application and not requesting add from outside

Here is .NET Framework v4.7.2 x86 version for you to try:

Falcosoft wrote on 2024-01-07, 17:43:

I'm not a .NET expert but I have heard about NAudio when .NET core not even existed. So I would be surprised if some older versions of NAudio had no support for .NET framework at all.
According to its nuget page even the current version still supports .NET Framework 4.7.2 and 4.8
https://www.nuget.org/packages/NAudio/

NAudio has been around for a long time, but NAudio.Midi is much more recent. It does however appear to support .NET Framework 4.7.2 and above; I'll see if I can get the code to compile with that version targeted.

sfryers wrote on 2024-01-07, 18:48:

Falcosoft wrote on 2024-01-07, 17:43:

I'm not a .NET expert but I have heard about NAudio when .NET core not even existed. So I would be surprised if some older versions of NAudio had no support for .NET framework at all.
According to its nuget page even the current version still supports .NET Framework 4.7.2 and 4.8
https://www.nuget.org/packages/NAudio/

NAudio has been around for a long time, but NAudio.Midi is much more recent. It does however appear to support .NET Framework 4.7.2 and above; I'll see if I can get the code to compile with that version targeted.

It worked for me but had to change some settings in project file and had to modify namespace syntax and add some usings to files. Also had to comment out some code. Here is the source code of the above .NET Framework 4.7.2 compatible binary:

Thanks!

Falcosoft wrote on 2024-01-07, 18:20:

Here is .NET Framework v4.7.2 x86 version for you to try:
MT32Edit_096_NET_472.zip

Thank you ) this version work )

Modern cross-platform compatibility means using AvaloniaUI with .NET 8 (the latest LTS release of the runtime/SDK).
The latest release of Windows Forms for .NET 8 introduces more extensive binding APIs, which could be used to introduce the MVVM pattern into the existing code base first.
MVVM is a pattern introduced by Microosoft at the same time as WPF was released back in 2006, to separate UI code from business logic code. It is also often used with AvaloniaUI.

Either way, such refactoring efforts present a high risk of regressions as the current code constantly mixes UI code and business logic in the UI's code behind files (my first WinForms project did that too, and WinForms is a leaky abstraction that leads to this kind of code all the time).

If I understand xcomcmdr's explanation correctly then the current code base would not lose anything by changing to old school .NET framework instead of .NET 6 since the used WinForms itself prevents the codebase to be cross platform compatible not the framework. And in terms of Windows only executables .NET Framework seems to provide better compatibility for older Windows versions.

Either way, such refactoring efforts present is a high risk of regressions as the current code constantly mixes UI code and business logic in the UI's code behind files (my first WinForms project did that too, and WinForms is a leaky abstraction that leads to this kind of code all the time).

BTW, This WinForms style of abstraction is very similar in this regard to Delphi, classic Visual Basic, C++ MFC/ATL/WTL code philosophy that were popular in the classic RAD era and could produce good quality applications despite what our modern era code aesthetic suggests. So even if no refactoring could happen MT32Editor would be in good company 😀.
( I personally like much more even pure C style Win32 programming with Window procedures and callbacks compared to WPF like and Web style programming for desktop Win32/64 applications but we are different and that is good.)

.NET Framework only works on Windows (and is shipped with Windows, and is closed source). It also does not evolve anymore.

.NET Core (now called .NET since .NET 5) is cross platform, shipped with the application (by default), and open source.

Right now, the usage of WinForms is what makes it a Windows only application.
Moving back to .NET Framework would tie it to the Windows platform without even using a Windows-only UI technology such as WinForms.

Edit:

Falcosoft wrote:

( I personally like much more even pure C style Win32 programming with Window procedures and callbacks compared to WPF like and Web style programming for desktop Win32/64 applications but we are different and that is good.)

WinForms is a wrapper around Win32, and callback are replaced by events. So yeah, it's very close in many ways.
There's even a Form visual designer in VS for the maximum RAD experience.
C# is also partially inspired by Delphi and Pascal, the designer is the same who designed Delphi.