xcomcmdr wrote on 2024-01-07, 21:31:

.NET Framework only works on Windows (and is shipped with Windows, and is closed source). It also does not evolve anymore. […]
Show full quote

.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.

What is the differene compared to what I said?

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.

The point is:
If Winforms stays then the current code base would not lose anything by changing to old school .NET framework. And it seems leaving Winforms behind will not be an easy task and will not happen for the 1.0 release.
And changing the current version to be (also) .NET Framework compatible requires about 20 lines of code.

Oh sorry, I read it too fast. I'm used to the MS naming of .NET Framework / .NET Core (now .NET) being confusing.

Falcosoft wrote:

If Winforms stays then the current code base would not lose anything by changing to old school .NET framework.

There are more controls such as the TaskDialog, available in the modern WinForms implementation of .NET 6/8. Along with tons of fixes regarding DPI support and 4K screens, for example.
The gradual move towards the MVVM pattern while keeping WinForms at first will be way harder without the new WinForms binding APIs introduced with .NET 8.
Anything beyond C# 7 cannot be used anymore. The old standard library misses a lot of improvements. Performance improvements are also gone.
A lot of third party packages are not compatible with .NET Framework anymore.
The ability to ship the app as a very small (on disk) native AOT compiled application is also gone (but that's more experimental anyway).

xcomcmdr wrote on 2024-01-07, 21:56:

Oh sorry, I read it too fast. I'm used to the MS naming of .NET Framework / .NET Core (now .NET) being confusing. […]
Show full quote

Oh sorry, I read it too fast. I'm used to the MS naming of .NET Framework / .NET Core (now .NET) being confusing.

Falcosoft wrote:

If Winforms stays then the current code base would not lose anything by changing to old school .NET framework.

There are more controls such as the TaskDialog, available in the modern WinForms implementation of .NET 6/8. Along with tons of fixes regarding DPI support and 4K screens, for example.
The gradual move towards the MVVM pattern while keeping WinForms at first will be way harder without the new WinForms binding APIs introduced with .NET 8.
Anything beyond C# 7 cannot be used anymore. The old standard library misses a lot of improvements. Performance improvements are also gone.
A lot of third party packages are not compatible with .NET Framework anymore.
The ability to ship the app as a very small (on disk) native AOT compiled application is also gone (but that's more experimental anyway).

I was taking about MT32Editor in its current form with its current feature set that is already well defined. And I do not think that gradual additions necessarily imply new third party packages that are only compatible with the newest and greatest.
I'm currently developing at least 2 popular MIDI related projects that work from Win NT4 SP6 to Win 11 (one of them supports Win9x) and even use Win 7 and Win 10 specific features so I do not think that progressive enhancement and graceful degradation is not possible in the world of Windows applications (although they are not .NET projects).
Features as TaskDialog can be substituted by MessageBox or custom forms and from my experience DPI related fixes are never perfect by any frameworks that use Win32 native controls at the base level so manual fixes are almost always necassary (as alraedy happened to this project).
You can set LangVersion to 9.0 and even to 10.0 without problems for this project even when the target framework is .NET Framework 4.7.2 otherwise the above attached binary could not have been produced.
I do not think that this application really requires that alleged performance improvements. At least the .Net Framework 4.7.2 version does not seem to be any slower than the .NET 6 version.

But all the above said actually irrelevant since I'm not saying that in the future when any of your mentioned/propheted breaking changes will be required you should not do them because of compatibility reasons.
I'm just saying that the code in its current form and even with some future minor fixes could be released as a more compatible .NET Framework executable (as proved by my .NET Framework version). And if/when that breaking changes happen in the future then the project should be released as .NET 6/7/8 executable as necessary.

No one will love your piece of software more just because it is using more modern technology or just because it uses newer language features or SOLID principles. If using more modern programming stuff offers nothing more in practice than less compatibility with older operating systems and older hardware then then you are doing something wrong and your users will be less satisfied. It's just that simple.

Here https://yadi.sk/d/Kcyp-vwS2kLYdw you can download portable version for Windows 7 without NET 4.7.2 ) this version created on VMware ThinApp )

Falcosoft wrote:

No one will love your piece of software more just because it is using more modern technology or just because it uses newer language features or SOLID principles. If using more modern programming stuff offers nothing more in practice than less compatibility with older operating systems and older hardware then then you are doing something wrong and your users will be less satisfied. It's just that simple.

Simply put: If I have to hate working on a hobby project in an outdated technology where development is slower because I can't use the latest packages, languages features, or IDEs (not too long ago, VS dropped support for anything before .NETFX 4.7), my users better be paying me. Or else, you get developer burnout and 0 (zero) pieces of software.

Especially since the usage of desktop OSes before Windows 10 is so rare nowadays.

Also I think 4K screens and modern DPI support is important to users. Yes, DPI support is messy with WinForms, but it was even less good with .NET Framework, so going back might introduce a regression.
Which potentially means fixing the same DPI problem again but on a harder difficulty setting as old documentation will have to be found. Not fun.

Falcosoft wrote:

TaskDialog can be substituted by MessageBox

Sure. And it was available as a 3rd party package before that. But it was introduced in Windows Vista in 2006. I'd say it's about time to welcome change and let WinForms wrap it in a nicer API than P/Invoke.
Beyond that, you don't get the latest WinForm UI controls and binding APIs, which can also lead to a slower app development. Going back is not cost free to the developer.

Falcosft wrote:

You can set LangVersion to 9.0 and even to 10.0 without problems for this project

Sure. But, the latest C# language is 12... And even C# 9.0 features like records are not supported entirely in .NET Framework: https://btburnett.com/csharp/2020/12/11/cshar … ut-dotnet5.html

Ultimately, no one else but sfryers dictates where the application is going. And they expressed interest in the app going cross platform. This is incompatible with the usage of .NET Framework instead of modern .NET.

xcomcmdr wrote on 2024-01-08, 08:18:

Simply put: If I have to hate working on a hobby project in an outdated technology where development is slower because I can't use the latest packages, languages features, or IDEs (not too long ago, VS dropped support for anything before .NETFX 4.7), my users better be paying me. Or else, you get developer burnout and 0 (zero) pieces of software.

As I said before programmers are different and that is good. I personally enjoy to circumvent the restrictions of the one true way that MS decided you should walk on. (If that makes your software more easy to use and available to more users). I think this is part of the creative process that makes software engineering enjoyable.
You can use the greatest and newest IDE for the whole development process and only alter the deployment phase a little to achieve more compatibility. I'm developing my C++ projects on VS 2019 and only in the last phase I'm sending the projects to VS 2005 compiler to get a more compatible binary and linking with the non-MS supported msvcrt.lib from the Windows DDK so that no Visual C++ redistributable is required.

Ultimately, no one else but sfryers dictates where the application is going. And they expressed interested in the app going cross platform. This is incompatible with the usage of .NET Framework instead of modern .NET.

Yes, and no one questioned this. I'm just sharing my opinion not about the direction of future development but about the current distribution/release form of the project in its current state.

Also, going cross-platform means ditching the x86 platform, as the vast majority of linux users only use x64 distros, without any x86 compatibility layer installed by default (this is the default on Ubuntu, for example):

https://askubuntu.com/questions/454253/how-to … n-ubuntu-64-bit

macOS is in the same boat.

On the .NET side, there is no x86_32 release of the SDK/Runtime, except for Windows:

https://dotnet.microsoft.com/en-us/download/dotnet/8.0

I compose music on my MT-32, and this will make it *lots* easier... if we can get it working outside of windows, at least.
It's really nice to see that someone's been working on this. And that they aren't opposed to helping make it a little bit more cross-platform.

I guess I'll be having to stick to my Atari ST emulation-based approach (and some manual hexadecimal editing/checksum calculations) for now, however. Much smaller and easier to get working and maintain than a Windows install.

sergm wrote on 2023-04-08, 08:20:

Alas, I personally still can't use it directly. Either LA-SYNTH from 1995 or MT32 Editor requires running Windows, just different versions 😀 I wonder how hard it would be to port it to other operating system e.g. with Mono.

You probably won't know, but just in case: does LA-SYNTH happen to work on PC-98 Japanese Windows 3.x? Because that might be a temporary solution I can use.

I'd assume there was SOME software in Japan meant for making patches for the MT-32, Roland being a Japanese company and all.

SkyHawk wrote on 2023-04-08, 17:43:

I'd suggest you could surely run Windows and this application in a VM. But I don't think I've ever seen a VM solution that allows access to host MIDI.

This is a kind of response that people hate. Or at least I don't like it.
I at least ask for support because I DON'T want to make a whole modern windows VM just for sending a handful of bytes to something from the 80s. And also it's a horrible waste of drive space.

There's hope with IKVM: https://github.com/ikvmnet/ikvm/issues/468

Basically, the .NET Standard Library doesn't include MIDI ports support. In the realm of 3rd party packages there was managed-midi, but it has been abandoned a long time ago. It's possible to code it yourself, but making it work *and* cross-platform is a huge undertaking.

Currently, the MT-32 Editor uses the native Windows WinMM API for that.

On the other hand, the Java standard library offers FM Synth, General MIDI access, MIDI ports control, and PCM playback. IKVM makes the JVM (and pretty much any Java package) available to .NET.

As for the UI, it's possible to convert it to Avalonia. But it's already huge, with a high risk of regression in the conversion. See: https://github.com/sfryers/MT32Editor/issues/7

Disclaimer: I'm just following this from afar.

xcomcmdr wrote on 2024-02-18, 08:39:

There's hope with IKVM: https://github.com/ikvmnet/ikvm/issues/468

Yes, it'll be very interesting to see whether that project provides an answer to the cross-platform MIDI issue.

The next minor MT32 Editor update will be available in the next few days.

Updated version v0.9.7a is now available- please see the link in my original post.

The application can now read MT-32 SysEx data from .mid files, although I only have a small number of these to test with. I've also added an autosave feature, and the ability to load a file at startup (either from the command line, drag & drop, or by using the Windows "Open With" feature). Additional user options are now saved to the MT32Edit.ini file and recalled next time the application is run. The application now shows the current file details in the main window title bar. The console window can now be hidden.

As well as the standard x86 and x64 builds for .NET 6.0, I've also included an untested, experimental build for Windows 7 32-bit. This build targets .NET 4.7.2- thanks to @Falcosoft for demonstrating that this is achievable with minimal code changes. The 4.7.2 build results in a somewhat messy, but still functional UI, which I don't plan on doing any further work to improve.

sfryers wrote on 2024-02-24, 11:10:

Updated version v0.9.7a is now available- please see the link in my original post.

The application can now read MT-32 SysEx data from .mid files, although I only have a small number of these to test with. I've also added an autosave feature, and the ability to load a file at startup (either from the command line, drag & drop, or by using the Windows "Open With" feature). Additional user options are now saved to the MT32Edit.ini file and recalled next time the application is run. The application now shows the current file details in the main window title bar. The console window can now be hidden.

As well as the standard x86 and x64 builds for .NET 6.0, I've also included an untested, experimental build for Windows 7 32-bit. This build targets .NET 4.7.2- thanks to @Falcosoft for demonstrating that this is achievable with minimal code changes. The 4.7.2 build results in a somewhat messy, but still functional UI, which I don't plan on doing any further work to improve.

Thanks, it sems to be working perfectly (tested regular .NET 6.0 x86 version).
I like the feature that during import the dialog shows the first MT-32 LCD message contained in the Midi file.

BTW, this editor works perfectly with my Munt VSTi plugin. Timbres found in a Midi file can be tested easily real-time:
https://youtu.be/ry9Bcp73sCE

Falcosoft wrote on 2024-02-24, 13:13:

Thanks, it sems to be working perfectly (tested regular .NET 6.0 x86 version). I like the feature that during import the dialog […]
Show full quote

Thanks, it sems to be working perfectly (tested regular .NET 6.0 x86 version).
I like the feature that during import the dialog shows the first MT-32 LCD message contained in the Midi file.

BTW, this editor works perfectly with my Munt VSTi plugin. Timbres found in a Midi file can be tested easily real-time:
https://youtu.be/ry9Bcp73sCE

Thanks for testing. It's good to see it working with other Midi applications.

wyatt8740 wrote on 2024-02-17, 22:34:

I at least ask for support because I DON'T want to make a whole modern windows VM just for sending a handful of bytes to something from the 80s. And also it's a horrible waste of drive space.

Whilst a native cross-platform release is likely to be a while away yet, I do have some positive news to share.

The experimental build included in my latest release, which targets .NET4.7.2 instead of .NET 6, appears to be fully functional on Linux using Wine. I've successfully tested it today on Ubuntu 20.04 with the latest supported versions of Wine, wine-mono.msi, and a hardware MT-32 connected with a Roland UM-ONE USB MIDI adapter. The UI is a bit messy, and it's quite laggy, but it does appear to be working correctly.

An updated release v0.9.8a is now available- please see my original post for the download link.

This is mostly a bug-fix release, however I have now added a selectable dark/light UI theme.

This release is also more responsive when running on Linux under Wine - and contrary to my previous post, the .NET 6 version runs just fine if you actually have the latest versions of Wine and wine-mono.msi installed.

sfryers wrote on 2024-03-16, 10:19:

An updated release v0.9.8a is now available- please see my original post for the download link.

This is mostly a bug-fix release, however I have now added a selectable dark/light UI theme.

This release is also more responsive when running on Linux under Wine - and contrary to my previous post, the .NET 6 version runs just fine if you actually have the latest versions of Wine and wine-mono.msi installed.

That seems great! - and yeah, I can do that. Thanks for caring about portability enough to at least listen and try to make it better. Many .NET developers I've interacted with don't even do that.

Holy cow how is it I missed this and it's a whole year old? Thank you so much for creating something modern! I've been using LA-Synth for Win3.x under OTVDM and sometimes Unisyn (another Win3.x librarian for multiple synths which I originally found by searching for something compatible with the FB-01).

EDIT: After using it a little bit last night and this morning, I've noticed that the x64 and x86 builds have this weird pausing slowdown that happens every half-second. This is for everything; clicking on a menu/button, hovering over a menu selection (waiting for it to highlight). But the .NET 4.7.2 build works flawlessly at full speed without this constant pausing problem. I'm running Win10 on a Ryzen 5 3600X 6-core CPU @3.79GHz with 32GB RAM. I'm not sure what could be slowing these particular builds down.

I've skimmed the thread and haven't seen anyone mention it yet. Has anyone else run into this with the x64/x86 builds?

MusicallyInspired wrote on 2024-04-09, 05:35:

After using it a little bit last night and this morning, I've noticed that the x64 and x86 builds have this weird pausing slowdown that happens every half-second. This is for everything; clicking on a menu/button, hovering over a menu selection (waiting for it to highlight). But the .NET 4.7.2 build works flawlessly at full speed without this constant pausing problem. I'm running Win10 on a Ryzen 5 3600X 6-core CPU @3.79GHz with 32GB RAM. I'm not sure what could be slowing these particular builds down.

That's very odd. My development system has almost identical specs (Win10, Ryzen 5 3600, 32Gb) and I've never experienced anything like this. Are you using Munt or a hardware MIDI interface?

MusicallyInspired wrote on 2024-04-09, 05:35:

Holy cow how is it I missed this and it's a whole year old? Thank you so much for creating something modern! I've been using LA-Synth for Win3.x under OTVDM and sometimes Unisyn (another Win3.x librarian for multiple synths which I originally found by searching for something compatible with the FB-01).

EDIT: After using it a little bit last night and this morning, I've noticed that the x64 and x86 builds have this weird pausing slowdown that happens every half-second. This is for everything; clicking on a menu/button, hovering over a menu selection (waiting for it to highlight). But the .NET 4.7.2 build works flawlessly at full speed without this constant pausing problem. I'm running Win10 on a Ryzen 5 3600X 6-core CPU @3.79GHz with 32GB RAM. I'm not sure what could be slowing these particular builds down.

I've skimmed the thread and haven't seen anyone mention it yet. Has anyone else run into this with the x64/x86 builds?

I have tried to reproduce this issue with way weaker hardware on Win 10 but I could not. I have tried both hardware and software Midi In/Out ports.
Maybe you can try earlier releases to determine if older verisons work for you or not. This way you can help Sfryers to investigate if some kind of strange regression can cause your issue.

@Sfryers:
During testing I have noticed that the .NET6 x86 version presents itself as x64 version on the console 😀

Falcosoft wrote on 2024-04-09, 21:23:

@Sfryers:
During testing I have noticed that the .NET6 x86 version presents itself as x64 version on the console 😀

Whoops! The string containing the version number which appears in the console and 'About' window is hard-coded, I must have forgotten to change it when I last compiled the x86 version. I've just about finished adding an undo/redo function to the editor, so I'm intending to publish another update this weekend.