A small milestone for the project, but an important one: the Store version has passed certification, was installed directly from the public Microsoft Store on a Windows 11 test system, and retained the existing MIDI Manager settings and database correctly.

MIDI Manager is a local-first desktop application for people working with MIDI and KAR collections. It can index large collections, run deeper MIDI analysis, search and review files, detect MIDI/device characteristics, build a separate Organized Library, create playback queues, and prepare floppy/Gotek IMG files. Your MIDI files stay on your own computer or storage.

Windows 0.9.5 is now available directly from the Microsoft Store:
https://apps.microsoft.com/detail/9P9PKX8XNDWF

Linux 0.9.5-1 remains available as an Ubuntu/Kubuntu .deb.

Downloads and current release information:
https://musicnotehaven.ethercomm.eu/downloads/

I am still looking for MIDI users who want to test the application with real-world collections. That feedback is now directly influencing the work toward Windows 1.0.0 and Linux 1.0.1 — especially analysis explainability, preservation of MIDI data, Library Organizer usability and support for less straightforward MIDI/arranger-keyboard material.

The tester programme is here:
https://musicnotehaven.ethercomm.eu/midi-manager-testers/

I’m particularly interested in feedback from people with collections that go beyond straightforward General MIDI files: older archives, KAR files, keyboard/arranger material, GS/XG files, unusual controller/program/bank data, SysEx, and files that have survived several generations of software.

If anyone here tries it, I’d genuinely like to hear what it gets right, what it misunderstands, and what would make it more useful for serious MIDI collection management.

One nuance, in case it's expected behavior on your end: it doesn't repaint live while you're on the parameter page — the value refreshes when you navigate back to that page, as if the controller re-reads on page-enter rather than continuously. Not real-time, but no longer frozen. Is that what you'd expect, or is there a trigger I'm missing to force a repaint of the currently-displayed page?

Is this on the workbench - or some other software - sorry not sure what you're referring to here?

Hi Jason,

First of all, thank you very much for taking the time to test 0.9.0 this thoroughly and for documenting what you found.

I only just saw your replies because the email address connected to my MIDI.org profile was one I do not monitor regularly. I have corrected that now, so I should see future replies much sooner.

Your feedback is extremely useful, particularly because it shows several places where the application either did not explain its state clearly enough or where the workflow was still too technical.

One important point is that the 0.9.0 build you tested is now quite a long way behind the current development version. We have made a very substantial number of changes since 0.9.0.

Some of the larger changes include:

• substantial performance improvements, particularly with larger MIDI collections;
• a new incremental, database-backed Organized Library browser;
• major improvements to the Playback Queue and its database integration;
• improved Dashboard statistics and status handling;
• extensive localization work throughout the application in English, Dutch, German, French and Spanish;
• adaptive command/button layouts that work much better at narrower window sizes;
• application-wide improvements to help text and tooltips;
• clearer licence-dependent behaviour and messages;
• substantial database and runtime hardening;
• additional automated and runtime validation, including the Trial/Free 100-file organization limit.

There have also been many smaller UI and workflow improvements.

Because the difference between 0.9.0 and the current development version has become so large, I have decided that it makes more sense to publish another pair of preview releases before the final 1.0 releases.

The current plan is to release 0.9.5 for Windows and 0.9.6 for Linux this weekend.

These will be the next testing builds on the Road to 1.0, before 1.0.0 for Windows and 1.0.1 for Linux.

Your specific findings are still very important, and I am going through them one by one.

The different counts you saw in Library Analysis and on the Dashboard definitely need attention. Seeing values such as 4,064 detected files alongside 14,659 indexed records is understandably confusing, regardless of what internal distinction produced those numbers. The Dashboard also should not require an application restart before showing completed analysis results.

I have also noted your comments about:

• enabling the initial source scan by default;
• PENDING being misleading for files whose analysis has already failed;
• clearer GM/GM2, Yamaha/XG and Roland/GS information;
• exposing MIDI Type 0/1 information;
• the apparent 200-file limitation in the device view;
• showing file locations and providing open-file/open-folder actions;
• the Library Organizer exposing too much technical terminology;
• the 25-item analysis workflow;
• handling unknown artists and incorrect MusicBrainz matches;
• the database-open error you encountered during review.

Your comments about the Library Organizer are particularly useful. A normal user should not need to understand terms such as AUTO_SAFE, planning batches and internal copy states simply to organize a MIDI collection. The application needs to make much clearer what it is doing, why a file needs review, and what the user is expected to do next.

I also appreciate your comment that the MIDI-by-device functionality is useful even though you personally do not want software reorganizing your existing folders. That is important to me. MIDI Manager should still provide useful analysis, search, device information and playback-related functionality without requiring somebody to reorganize their collection.

We also have a tester programme for people who would like to help with this final Road-to-1.0 testing. Up to 10 testers who complete the programme and provide a full test report can receive a free Personal licence. Feedback like yours is exactly the kind of real-world testing the programme is intended to encourage.

So if anyone else following this thread would like to test 0.9.5 or 0.9.6 when they become available, additional machines, MIDI collections and workflows are very welcome.

Once the new builds are available, I’ll post an update here. Jason, if you are willing to try the newer version as well, it would be especially useful to see which of your observations still apply after all the changes made since 0.9.0.

Thanks again for the detailed testing and screenshots. It genuinely helps shape what goes into the 1.0 release.

So the suggested method for Channel Voice Message values (as opposed to other types of values) is to use Process Inquiry to retrieve a snapshot and them work with the CVMs as they are sent from the device.

Moving onto doing values over PE the subscription mechanism is depending on the data. For simple small data I recommend sticking to a full/notify update. For data that is a bit more structured then partial on a small change, and notify on a large change

> Robustness patterns. Stale MIDI-CI sessions, re-subscription behavior, MUID invalidation on reconnect 

Not 100% I understand specifically the question. But on a MUID invalidation I generally throw away all information (including cache) and start again.

What I built. A small PE responder (running on a Mac) that impersonates a sound generator. It serves resources built from data that a synth already has — its parameter names and its CC map — so that a hardware controller can discover it over MIDI-CI. The result: the controller auto-labels its eight knobs with the synth's real parameter names and drives them, with no MIDI-learn and no templates. The two products were never designed to interoperate; PE made them.

For me this was the "oh, it actually works" moment — the thing PE promised, running on real gear. It scaled cleanly across ~47 instruments from one software collection.

Why I'm posting. Getting there took more reverse-engineering than I expected, and I ran into a few things I'd genuinely like other implementers' perspectives on:

1. Standard vs. vendor-specific resources. The controller I used fetches vendor-specific

   parameter/value resources rather than the standardized CtrlList / AllCtrlList. Is that common in the wild? Has anyone successfully served standard controller resources to a shipping controller and had it map knobs from them? I'd love to know how portable a "standard-resources-only" responder actually is today.

2. Subscriptions / value sync. For a responder to advertise live values and have a controller

   display them, what's the subscription behavior you've found works reliably? I'd like to compare notes on the full vs partial update flow and how different peers handle it.

3. Robustness patterns. Stale MIDI-CI sessions, re-subscription behavior, MUID invalidation on

   reconnect — is there an agreed set of best practices or, ideally, a reference implementation people build against?

Offer. I'm happy to share the responder and the harvester (the bit that turns a synth's shipped files into a PE resource set) as a reference — it might save the next person the reverse-engineering, and it could be a useful starting point for anyone building a responder. If there's interest in an open reference implementation / conformance-style test set for PE, I'd gladly contribute what I have.

Mostly I'd love to hear from anyone else implementing PE — what's worked, what's been painful, and whether the standard-resource path is as viable as I hope it becomes.