In the days of Electron bloatware, it's refreshing to see a program that is so light in terms of size. Unfortunately, at least on a 4K screen, the interface is a bit laggy and it uses a lot of CPU.
A web app would have been cross platform (including just web), had a superior UI (in both speed and UX) — and with a less bloated Electron alternative like Tauri — better in just about every way that matters.
I'm curious what samples it's using for playback. Is it just using whatever the host OS offers or does it have its own internal samples? I searched on the main page, About and FAQ for the term "Samples" and didn't see any info.
As someone into both music production and retro gaming, my experience of MIDI is that the instrument types are standard but the fidelity and quality of the music varies depending on the samples used. While low-end 90s sound cards had small sample ROMs and better cards had larger sample sets (2 or more MB). More recently there are even larger, very high quality MIDI sample sets which are open source. Also, is General MIDI 2 supported? How about extensions like Roland GS and Yamaha XG?
Cynthia uses whatever midi playback device you have on offer. By default that's "Microsoft GS Wavetable Synth" on Windows, which is horrible to say the least. But if you install a 3rd party midi driver app like VirtualMIDISynth or OmniMIDI (see my other comment in this thread about soundfonts) you can upgrade sound playback to high quality using soundfonts (.sf2).
The app can also switch between up to 10 midi devices in realtime, or use them all simultaneously for playback - see main GUI, bottom right, Playback Device, 1 to 10 or "A" for all.
App supports General Midi 1 (GM1) over 16 channels in playback formats 0 and 1, but not 2. It does not support General Midi 2 (GM2) e.g. 32 channels, and does not support "system exclusive messages".
It has a freepascal/lazarus project file, so it can be compiled for a lot of platforms, i don't about midi drivers on those platforms, so midi could not work or need more code.
Pascal! So that’s how the comment above about a “refreshing” lightness in code size was achieved.
It’s pretty consistent these days that when some indie / hobby app appears and is lightweight, there’s a very decent chance it’s Delphi, Free Pascal, or similar. A bit of a secret weapon in the Electron age.
Yeah, by portable I do mean just an EXE to run. That is, no install, won't mess with your operation system, or play with your registry settings etc, nor require any setup to get running.
This also allows the app to run seamlessly on a USB pen stick/harddisk so you can use it on different computers without fuss or being tied down by an installation. The app stores all it's settings etc in a folder alongside the EXE itself, usually "(app name).exe_storage", and automatically manages any references to external filenames/folders on it's own disk drive, allowing it to operate on different computers that might assign its disk drive a random/different drive letter without interrupting access to any referenced filenames/folders.
And no, it's not multi-platform/cross-platform. It's a Win32 (32 bit) binary/codebase. The occasional experiment I have done in the past into cross-platform coding has left me less than impressed. Unfortunately, I'm used to coding at the low-level/API level, and as soon as the programming language starts to abstract away the commands things tend to get dicy for me, and I inevitably find myself lugging around 20+ MB libraries of converted functions, and with no particular guarantee the final app with behave or look similar on different platforms.
Though I do wish such a thing existed. Something like a universal translation layer for all variations of software apps that is hardware accelerated and uniform in execution down to the very last and simple command would be a dream come true. Can't see why in 2025 we are still expected to code and/or compile apps for different operating systems and hardware platforms.
Their website makes their definition of portable very clear in "What makes a portable app special?".
It's quite clear they mean more a (much) stricter variation of the "no installation" definition than the "easily buildable on other OS" definition. Though they do mention execution under translation environments as a requirement.
There were companies that specialized in 'porting' games to Mac using/packaging Wine long ago. It was certainly effective in the Intel Mac days and newer CPUs can certainly run software that predates that well. Heck browsers can run OSes and games in JS/Wasm.
Sarcasm? Know that feeling. Midi does work on Wine under Mac without any fuss, both on Intel chip (tested on Mac Mini 2018) and Apple silicon (tested on Mac Mini 2023) with a fairly decent system soundfont for good music reproduction.
As for Linux, well... that's more difficult, even under Ubuntu with GUI apps for help. You need to have two audio apps installed and actively running and setup just right in-order for midi to produce any sound on Linux, which are "Qsynth" the midi soundfont player and "QjackCtl/Jack Audio" which is the audio stream controller.
Note, if you're running Linux in a virtual machine chances are it won't handle midi playback properly even if everything is setup right. I tested this under Ubuntu v20 I think a few years back and the midi playback was horribly distorted - don't think the IO rate between the virtual machine and the real machine was up to the job.
Unfortunately on Linux it can be rather difficult to say the least to get midi working right, and more often than not you want to hit the screen in frustration. Sadly, there is no simple "just do it" option to get things working as you'd expect.
In addition, Qsynth loves to generate multiple midi playback devices, like 6 or more, of which only one or two from my experience actually render any sound. To help with this frustration, Cynthia has a play all midi device option (main GUI bottom right, Playback Device, select "A"). This way, if only one of six or more midi devices on Linux is capable of sound playback Cynthia will get it working. Unfortunately Qsynth and Jack can be a real pain to setup and keep working.
Haven't used either of those apps myself directly, but from a few quick searches online they look to be doing the same job. It's probably a matter of settings - even when I had Qsynth and Jack running right, I had to go into Jack and align the audio streams etc and fiddle around a bit. Qsynth was a bit better, just had to get one midi device working and it was OK then.
Online is stating that PipeWire is now the default instead of PulseAudio or Jack. From my understanding they both sit on top of ALSA, the audio hardware driver.
So for things to go right you need:
1) Cynthia directed to playback through a working midi input device (she has a playback device range of 1-10, or "A" for all of them at once)
2) The midi input device is synthesised by FluidSynth which takes Cynthia's midi instructions and converts them into wave audio output
3) The wave audio output is directed to PipeWire/PulseAudio/Jack Audio
4) PipeWire/PulseAudio/Jack Audio ultimately direct it at your machine's hardware driver/handler, ALSA, which directs to your soundcard/sound chip and out to your speakers/headphones if all goes well.
I've read online that Jack is the pro option, which is why it was so complicated to do the basics, and PipeWire/PulseAudio are a little more user friendly?
If you switch Cynthia's Playback Device to "A" (bottom right of main GUI), she will play/broadcast her midi notes/instructions to all available midi input devices simultaneously, so if you have at least one midi input device producing sound, you should get something coming through to your speakers/headphones.
Unfortunately, I can't offer you much more help than this, as I'm not familiar with PipeWire/PulseAudio, and as far as I know FluidSynth was controlled behind the scenes (under the hood) by Qsynth's GUI.
Oh my, haven't heard canyon.mid for years - takes me right back. Have you tried either of the soundfonts below? They do a pretty good job a reproducing canyon.mid, not perfect, but enough to take you back. The default Windows "Microsoft GS Wavetable Synth" is rather horrible at sound reproduction at best, and that's being nice.
You can direct Cynthia to output her midi notes/instructions to a different midi device/devices for higher quality playback/sound reproduction through the midi driver apps below (for Windows):
The apps above do a nice job at playback with minimal lag and without much setup or tweaking to get going. Basically just install one, assign a soundfont, and restart Cynthia to be able to select a different midi device - numbered 1 to 10 under Playback Device (bottom right panel of main GUI).
At one point in the past I did look into including soundfont support directly into Cynthia, but instead decided to focus on playback stability and ease-of-use as top priorities, which funnily enough was a mountain enough all-by-itself to climb considering how difficult Windows can be to get along with, let alone get working right on something as simple as midi playback under Win32.
I never left pascal. Still code in an ancient Borland Delphi 3 Pro to this day - one slightly hefty license fee way back when for perpetual use was a bargain, unlike today's hefty fees. Still I love it's simplicity, crap-free interface, and blazing fast compilation times.
Have tried the modern community edition of Embarcadero Delphi a couple of times over the years, but found its layers on layers of source code and object inheritance complexity really shocking. I can only imagine the poor souls that have to maintain that mess.
Something like trying to ascertain simple logic pathways through their code in order to understand function limits or compatibility issues was a real nightmare/time consuming. Let alone attempting to predict or change core functionality.
And they did away with 8 bit ANSI strings, which were at times rather handy for some basic IO work and data processing. More than anything, you knew were you stood in your data at all times.
Another annoying thing was there bitmap handler, which required you to lock it in order to access it's internal pixels for data processing - think this was for compatibility with mobile chips - which from my basic observations did a full read and write (copy) of the image data - slowish. A simple binary data handler to mimic a system bitmap got right round that bottleneck.
In the days of Electron bloatware, it's refreshing to see a program that is so light in terms of size. Unfortunately, at least on a 4K screen, the interface is a bit laggy and it uses a lot of CPU.
A web app would have been cross platform (including just web), had a superior UI (in both speed and UX) — and with a less bloated Electron alternative like Tauri — better in just about every way that matters.
I’ve yet to see a web app that has native-like great UX.
I'm curious what samples it's using for playback. Is it just using whatever the host OS offers or does it have its own internal samples? I searched on the main page, About and FAQ for the term "Samples" and didn't see any info.
As someone into both music production and retro gaming, my experience of MIDI is that the instrument types are standard but the fidelity and quality of the music varies depending on the samples used. While low-end 90s sound cards had small sample ROMs and better cards had larger sample sets (2 or more MB). More recently there are even larger, very high quality MIDI sample sets which are open source. Also, is General MIDI 2 supported? How about extensions like Roland GS and Yamaha XG?
Cynthia uses whatever midi playback device you have on offer. By default that's "Microsoft GS Wavetable Synth" on Windows, which is horrible to say the least. But if you install a 3rd party midi driver app like VirtualMIDISynth or OmniMIDI (see my other comment in this thread about soundfonts) you can upgrade sound playback to high quality using soundfonts (.sf2).
The app can also switch between up to 10 midi devices in realtime, or use them all simultaneously for playback - see main GUI, bottom right, Playback Device, 1 to 10 or "A" for all.
App supports General Midi 1 (GM1) over 16 channels in playback formats 0 and 1, but not 2. It does not support General Midi 2 (GM2) e.g. 32 channels, and does not support "system exclusive messages".
Thank you for answering!
You're welcome.
Finally, don't have to remember the UMRN for Camptown Races anymore.
It has a freepascal/lazarus project file, so it can be compiled for a lot of platforms, i don't about midi drivers on those platforms, so midi could not work or need more code.
Pascal! So that’s how the comment above about a “refreshing” lightness in code size was achieved.
It’s pretty consistent these days that when some indie / hobby app appears and is lightweight, there’s a very decent chance it’s Delphi, Free Pascal, or similar. A bit of a secret weapon in the Electron age.
Calling a program portable by virtue of wine being a thing defies logic. That said, nice work. Midi instrument input is on my wishlist.
Portable and cross-platform are not synonymous. Being developed with the Wine in mind and being a standalone app are two unrelated features.
https://www.blaizenterprises.com/cynthia.html#help--what-mak...
Maybe it's "portable" in the sense that it's just an executable to launch, with no installation needed? I don't think they claim it is multi-platform.
Yeah, by portable I do mean just an EXE to run. That is, no install, won't mess with your operation system, or play with your registry settings etc, nor require any setup to get running.
This also allows the app to run seamlessly on a USB pen stick/harddisk so you can use it on different computers without fuss or being tied down by an installation. The app stores all it's settings etc in a folder alongside the EXE itself, usually "(app name).exe_storage", and automatically manages any references to external filenames/folders on it's own disk drive, allowing it to operate on different computers that might assign its disk drive a random/different drive letter without interrupting access to any referenced filenames/folders.
And no, it's not multi-platform/cross-platform. It's a Win32 (32 bit) binary/codebase. The occasional experiment I have done in the past into cross-platform coding has left me less than impressed. Unfortunately, I'm used to coding at the low-level/API level, and as soon as the programming language starts to abstract away the commands things tend to get dicy for me, and I inevitably find myself lugging around 20+ MB libraries of converted functions, and with no particular guarantee the final app with behave or look similar on different platforms.
Though I do wish such a thing existed. Something like a universal translation layer for all variations of software apps that is hardware accelerated and uniform in execution down to the very last and simple command would be a dream come true. Can't see why in 2025 we are still expected to code and/or compile apps for different operating systems and hardware platforms.
"* Also runs on Linux/Mac (including apple silicon) via Wine *"
Their website makes their definition of portable very clear in "What makes a portable app special?".
It's quite clear they mean more a (much) stricter variation of the "no installation" definition than the "easily buildable on other OS" definition. Though they do mention execution under translation environments as a requirement.
There were companies that specialized in 'porting' games to Mac using/packaging Wine long ago. It was certainly effective in the Intel Mac days and newer CPUs can certainly run software that predates that well. Heck browsers can run OSes and games in JS/Wasm.
If they specifically target and test for wine compatibility the I’d call it fair
I'd guess approximately nobody does it, but with winelib you can do a native compile and link.
Yeah, very nice app, but it's weird to target Windows as the primary OS.
Wine MIDI doesn't work, so it's a big advantage.
Sarcasm? Know that feeling. Midi does work on Wine under Mac without any fuss, both on Intel chip (tested on Mac Mini 2018) and Apple silicon (tested on Mac Mini 2023) with a fairly decent system soundfont for good music reproduction.
As for Linux, well... that's more difficult, even under Ubuntu with GUI apps for help. You need to have two audio apps installed and actively running and setup just right in-order for midi to produce any sound on Linux, which are "Qsynth" the midi soundfont player and "QjackCtl/Jack Audio" which is the audio stream controller.
Note, if you're running Linux in a virtual machine chances are it won't handle midi playback properly even if everything is setup right. I tested this under Ubuntu v20 I think a few years back and the midi playback was horribly distorted - don't think the IO rate between the virtual machine and the real machine was up to the job.
Unfortunately on Linux it can be rather difficult to say the least to get midi working right, and more often than not you want to hit the screen in frustration. Sadly, there is no simple "just do it" option to get things working as you'd expect.
In addition, Qsynth loves to generate multiple midi playback devices, like 6 or more, of which only one or two from my experience actually render any sound. To help with this frustration, Cynthia has a play all midi device option (main GUI bottom right, Playback Device, select "A"). This way, if only one of six or more midi devices on Linux is capable of sound playback Cynthia will get it working. Unfortunately Qsynth and Jack can be a real pain to setup and keep working.
I tried to use FluidSynth and PulseAudio. Maybe that's why.
Haven't used either of those apps myself directly, but from a few quick searches online they look to be doing the same job. It's probably a matter of settings - even when I had Qsynth and Jack running right, I had to go into Jack and align the audio streams etc and fiddle around a bit. Qsynth was a bit better, just had to get one midi device working and it was OK then.
Online is stating that PipeWire is now the default instead of PulseAudio or Jack. From my understanding they both sit on top of ALSA, the audio hardware driver.
So for things to go right you need: 1) Cynthia directed to playback through a working midi input device (she has a playback device range of 1-10, or "A" for all of them at once) 2) The midi input device is synthesised by FluidSynth which takes Cynthia's midi instructions and converts them into wave audio output 3) The wave audio output is directed to PipeWire/PulseAudio/Jack Audio 4) PipeWire/PulseAudio/Jack Audio ultimately direct it at your machine's hardware driver/handler, ALSA, which directs to your soundcard/sound chip and out to your speakers/headphones if all goes well.
I've read online that Jack is the pro option, which is why it was so complicated to do the basics, and PipeWire/PulseAudio are a little more user friendly?
If you switch Cynthia's Playback Device to "A" (bottom right of main GUI), she will play/broadcast her midi notes/instructions to all available midi input devices simultaneously, so if you have at least one midi input device producing sound, you should get something coming through to your speakers/headphones.
Unfortunately, I can't offer you much more help than this, as I'm not familiar with PipeWire/PulseAudio, and as far as I know FluidSynth was controlled behind the scenes (under the hood) by Qsynth's GUI.
Feature suggestion: Optional OPL3 simulation, so that CANYON.MID can be heard as God intended.
Oh my, haven't heard canyon.mid for years - takes me right back. Have you tried either of the soundfonts below? They do a pretty good job a reproducing canyon.mid, not perfect, but enough to take you back. The default Windows "Microsoft GS Wavetable Synth" is rather horrible at sound reproduction at best, and that's being nice.
a) 3 Mb OPL3.zip (contains one file "OPL3.SF2") - compact but pretty good: https://www.vogons.org/download/file.php?id=45715
and was sourced from: https://www.vogons.org/viewtopic.php?t=59354
b) 128 MB OPL-3_FM_128M.zip (contains one file "OPL-3_FM_128M.sf2") - a bit larger but slightly better in my opinion: https://musical-artifacts.com/artifacts/15/OPL-3_FM_128M.zip
and was sourced from: https://midis.fandom.com/wiki/OPL-3_FM_128M.sf2_(OPL3_Yamaha...
You can direct Cynthia to output her midi notes/instructions to a different midi device/devices for higher quality playback/sound reproduction through the midi driver apps below (for Windows):
a) VirtualMIDISynth (supports up to 4 simultaneous drivers with option to use one or more different soundfonts per driver): https://coolsoft.altervista.org/en/virtualmidisynth
b) OmniMIDI: https://www.majorgeeks.com/files/details/keppys_synthesizer....
The apps above do a nice job at playback with minimal lag and without much setup or tweaking to get going. Basically just install one, assign a soundfont, and restart Cynthia to be able to select a different midi device - numbered 1 to 10 under Playback Device (bottom right panel of main GUI).
At one point in the past I did look into including soundfont support directly into Cynthia, but instead decided to focus on playback stability and ease-of-use as top priorities, which funnily enough was a mountain enough all-by-itself to climb considering how difficult Windows can be to get along with, let alone get working right on something as simple as midi playback under Win32.
Type: Desktop App (Standard Edition)
This is (pun intended) music to my ears!
Wow, it's been a long time since I saw Pascal code.
I never left pascal. Still code in an ancient Borland Delphi 3 Pro to this day - one slightly hefty license fee way back when for perpetual use was a bargain, unlike today's hefty fees. Still I love it's simplicity, crap-free interface, and blazing fast compilation times.
Have tried the modern community edition of Embarcadero Delphi a couple of times over the years, but found its layers on layers of source code and object inheritance complexity really shocking. I can only imagine the poor souls that have to maintain that mess.
Something like trying to ascertain simple logic pathways through their code in order to understand function limits or compatibility issues was a real nightmare/time consuming. Let alone attempting to predict or change core functionality.
And they did away with 8 bit ANSI strings, which were at times rather handy for some basic IO work and data processing. More than anything, you knew were you stood in your data at all times.
Another annoying thing was there bitmap handler, which required you to lock it in order to access it's internal pixels for data processing - think this was for compatibility with mobile chips - which from my basic observations did a full read and write (copy) of the image data - slowish. A simple binary data handler to mimic a system bitmap got right round that bottleneck.
My first thought was “what’s wrong with foobar?”
Then I saw the instrument / note grid, and the keyboard UI - this looks fun!