Showing posts with label Mac. Show all posts
Showing posts with label Mac. Show all posts

Saturday, September 20, 2025

Celebrations with the GPL

This post is to celebrate a few things despite the events that are clouding our feelings. 😠

Another thing to not celebrate is the slaughtering by Sourceforge of my developer web site, which they are calling "sunsetting", by October. I've already migrated it

On the other, brighter hand, I'm celebrating this week La Mercè, which is the local festivity of Barcelona.

 Castellers of Barcelona
 
Another event to celebrate is the first 2 million downloads of VMPK for Linux, Windows and Mac. The Sourceforge statistics do not include the installs thru Flatpak, but you may realize that more than 75% of the Sourceforge downloads are the Windows packages. The 2 mil download happened some past day of this year 2025. I've promised a celebration, and now, I have released the Android port of VMPK under the GPLv3 license in GitHub.

VMPK Screenshot

You may download it from GitHub (source code and APK), or you may get it from the IzzyOnDroid repository which is available in the F-Droid app, but also on Neo-StoreDroid-ify,  and the unofficial IzzyOnDroid app.

If you already have the F-Droid app, you only need to add the IzzyOnDroid repository in Settings>Repositories and install it today, or you may prefer to use the official F-Droid repo.

I would like to add to the celebration a video live streaming concerto, but I am too lazy and odd playing for that. Better use this wonderful rendering of the Tchaikovsky Violin concerto by TwoSet Violin, with Brett Yang playing the soloist and Eddy Chen the rest of the orchestra. Enjoy!

Thursday, August 11, 2022

Summer Releases

This week I have published several new versions of my music applications:

The first two applications, kmetronome and kmidimon, are now over fifteen years old and are only available for Linux. These two new versions are simply bug fixes, with no new features. But it is interesting to note that in FlatHub they are already based on Qt6 and supporting both Wayland and X11, although the packages in AppImage format still use Qt5. The chances of finding these applications in the official repositories of Linux distributions are slim. In fact, kmidimon was removed from the official Debian repositories with some lame excuse, and it is unlikely to be included again. I can't do anything about it, so please: direct complaints where they belong. Or use the new available distribution formats or the unofficial repositories, like Debian Multimedia, which includes the three mentioned applications and many others.

The other app, dmidiplayer, is much newer and cross-platform. It is the successor to Kmid2, the KDE karaoke application that I rewrote many years ago. In this new version the most remarkable new feature is the persistent configuration of the songs. This is a feature that was already present in the old Kmid2 and that allows you to store the tempo, general volume, pitch transposition, and MIDI channel settings for each song, which will be applied when it is played again in the future. The other novelty is the individual volume adjustment for each MIDI channel, something that was not possible in Kmid2.

After all these years, it is curious that it is still possible to find Kmid2 in one distribution: Fedora, despite being a Qt4/KDE4 application. So a functional comparison of both applications is not only possible, but easy to do. In my opinion, with this version dmidiplayer has reached parity in terms of functionality with Kmid2. On the other hand, the new architecture has allowed the application to be available on other Unixes (such as FreeBSD) in addition to Linux, macOS, and Windows.

I guess the next app to get updates will be VMPK. There is no forecast yet of the changes it will bring, but there is a recurring request that I will not do: MIDI Jack support. This is not to say that it is not possible to use Jack MIDI with VMPK, because in fact there is an utility called 'a2jmidid' that serves as a translation layer between applications using the ALSA Sequencer and Jack MIDI. On the other hand, for VMPK to use new native backends it is only necessary to implement Drumstick::RT plugins. And this can be done by any interested developer, and then independently distribute the out-of-tree plugins. I've opened a discussion on GitHub about this. Anyone interested, please read and ask your questions there.

Wednesday, September 22, 2021

New Releases and the New Picture

A new batch of releases from the last weekend: Drumstick libraries 2.4.0, Drumstick Multiplatform MIDI File Player 1.5.1 and Drumstick MIDI Monitor 1.1.0 are out, and here are the main changes for each one:

Drumstick Libraries v2.4.0:

  • implemented ticket #29: RIFF RMID file support. New utility dumprmi, and guiplayer updated.
  • implemented ticket #32: missing library version functions in File and RT libs
  • implemented ticket #33: versioninfo object for windows libraries
  • Enabled by default the internal reverb on macOS DLS Synth
  • Avoided hardcoded font family name in vpiano

Drumstick Multiplatform MIDI File Player v1.5.1:

  • Fixed GH ticket #6: The dependency target "update_helpfiles" of target "dmidiplayer" does not exist. The pandoc utility is optional again.
  • Fixed error checking of DwmGetWindowAttribute() call. This caused a problem in Windows 7 running the "Windows Classic" theme.
  • Support for RIFF MIDI files, provided by Drumstick 2.4.0
  • Czech manual updated, thanks to Pavel Fric

Drumstick MIDI Monitor v1.1.0

  • Removed warnings building with Qt >= 5.15
  • MIDI texts/lyrics encoding defaults to Latin1
  • New options: Qt Style, Dark mode, and internal icon theme based on breeze
  • CMake version >= 3.14
  • Added SCM Revision to the about box
  • Fixed file info dialog (initial tempo, ...)
  • Support for RIFF RMID (.rmi) file format

A common point for all the above is the RIFF MIDI file format support. Citing the LOC:

It is a wrapper format for MIDI data, as first specified by Microsoft, and later extended by MIDI.org (an arm of the MIDI Manufacturers Association) to permit the bundling of both MIDI files and Downloadable Sounds (DLS) files. According to Multimedia Programming Interface and Data Specifications 1.0, August 1991.: "The 'RMID' format consists of a standard MIDI file enclosed in a RIFF chunk. Enclosing the MIDI file in a 'RIFF' chunk allows the file to be consistently identified; for example, an 'INFO' list can be included in the file."

The RIFF format specifications were published in 1991 in Microsoft Windows Multimedia Programmer's Reference, with a brief section devoted to RMID (8-31). The extended specification that documented how both MIDI and downloadable sounds could be bundled in an RMID file (technical note RP-029, "Bundling SMF and DLS data in an 'RMID' File"), was published by the MIDI Manusfacturers Association (MMA) in 2000. The co-authors represent IBM Research, Kurzweil, Microsoft, and Sonic Foundry. In 2001, MMA published the XMF_1_0 specification, which they now prefer to RMID.

The implementation in Drumstick::File offers read-only functionality, and requires the existing SMF class to process the MIDI data portion. The DLS processing is missing, because I've been unable to find a single example of usage, and I suspect that nobody has used it in the real world. Anyway, there is a new utility 'drumstick-dumprmi', which is similar to the other commandline utilities printing the file contents as text in the terminal, with the extra functionality of extract/convert the MIDI data into a standalone SMF file.

Last month was published another utility: wrk2mid v1.0.0 which converts WRK Cakewalk files into SMF. This is something that can be done in Windows using the program Cakewalk by BandLab, which is gratis as a beer, but 'wrk2mid' can be compiled and run on Linux and macOS, so maybe it could be useful for someone. I don't expect to see it on Linux distributions any time soon, though. See: https://wrk2mid.sourceforge.io/

There was a post from 2014 with a diagram of the relationship between the Drumstick libraries v1.0 and applications at the time. Now, all my applications depend on Drumstick v2.x and there are new ones too, so may be this is a good time to paint the new picture...

The new picture

The new picture

It is a pending subject to renew the repertoire included in dmidiplayer as sample songs. Here is a future one, rendered on macOS (Mojave) using dmidiplayer v1.5.1 with FluidSynth v2.2.3 and GeneralUser Soundfont.

The song is "Negra Sombra" with lyrics by Rosalia de Castro (1837-1885), published in 1880 in her book "Follas Novas", and music by Xoan Montes (1840-1899), a composer from my own birthplace (Lugo). The song was premiered in La Habana, Cuba, in 1892. You may recognize the melody if you like choral music, or because an arrangement by Carlos Nuñez and Luz Casal was included in the soundtrack of the Spanish drama film "The Sea Inside" (2004, Spanish: Mar adentro). This rendition is derived from a score and MIDI sequence by Lalus fecit edition 2013 licensed as CC-by-nc-sa.

Publishing this song at YouTube triggered the algorithm claiming it as a copyrighted work by Sony. I am not monetizing my videos at YouTube so it doesn't matter in practice, but it bothers me a lot so I'm disputing the claim. Google and Sony are taking a work that is in the public domain, and they are appropriating it. That may be seen as criminal conversion, or at least cultural appropriation.

Saturday, May 15, 2021

Drumstick Multiplatform MIDI File Player, Released and Reloaded

Drumstick Multiplatform MIDI File Player 1.3.0 has been released this week, right after the Drumstick Libraries 2.2.0 and VMPK 0.8.3; business as usual: we write programs, we release stuff. This post is about the first program, a MIDI file player (reloaded). Let's start by the beginning...

10 years ago, there was not a fully featured MIDI file player for Linux. Of course, there was Linux software that could (barely) play MIDI files, but nothing comparable to the vanBasco MIDI Karaoke player (which is a Windows 32 bit application, updated the last time in 2006). This program can be run in Wine, by the way. The key features of the vanBasco player are described in its site, and anyone with a musical background can identify its value, beyond the entertainment use case:

  • lyrics can be displayed in a resizable window or full-screen
  • control window: ability to change tempo, volume, key of song
  • real-time MIDI output window: shows notes, volumes, and instruments, can mute or play solo individual instruments
  • piano view: displays notes on a big piano keyboard

The KDE 4 desktop was starting to become mature and stable at the time, so I've decided to scratch my itch rewriting the old and abandoned KMid  application, adding my favorite features from vanBasco. This was already told on this blog a few times. KMid2 was a total rewrite almost from scratch, with the additional goal to make it multiplatform. Indeed, it was possible to build and run it on Linux, macOS and Windows, but there wasn't an easy way to deploy KDE programs on macOS and Windows at the time, so the only viable target was Linux. On the other hand, because the chosen architecture, it  was difficult to maintain and port the program to other platforms. Then, several Linux distributions boycotted this application, with the total indifference of the KDE community. Good riddance.

Fast forward to the roaring twenties. Nothing changed for Linux. The vanBasco player is still the king in the Windows world. In spite of most Windows 10 users running a 64 bit Operating System, vanBasco is rotting its 32 bits. The only alternative fulfilling the four mentioned features is Falcosoft MIDI player. I don't know about native macOS alternatives, either. Of course there are players for macOS, and WinAmp for Windows, and even VLC plays MIDI files, but that is not what I'm talking about...

I prefer to avoid hard use cases. Someone asked me once about my VMPK program: how it would be classified? Is it a Game? No, it is not a game, it is a toy! A game has a set of rules that the player must follow to reach the final goal: to win the game. On the other hand, a toy has no written rules. The player can explore, learn, and have fun on its own. No winners, no losers. Sometimes a good game may be repurposed by the users, like Wolfenstein 3D, but it is uncommon. It is in the definition of free software: the freedom to run the program as you wish, for any purpose.

Anyway, here is an usage example for this program: there is a choir, with a conductor or composer that arranges or edits pieces using some MIDI software like Rosegarden, MuseScore, Frescobaldi, or similar. He prints the scores (or exports PDF files for electronic distribution) for the singers. He also exports the pieces as MIDI files, that can be loaded by dmidiplayer, and used by the singers to learn and practice the lyrics and music of each voice. The examples in dmidiplayer include some choral music, edited in Rosegarden and directly exported as MIDI files.

You can download this program for free, either as sources that you may study, modify and build, or an AppImage for any Linux distro, or as ready to install packages for Windows, and macOS, from Sourceforge and GitHub.

There is also a Flatpak available at Flathub. And thanks to deb-multimedia, there are also deb packages for Debian and Ubuntu users.

Thursday, July 30, 2020

VMPK: MIDI by Network

This is only a quick and dirty article to link to the MIDI by Network page in the VMPK Wiki. It explains the basic concepts about ipMIDI and how to use it with VMPK.

The Wiki has also pages about the VMPK developing environment using Qt Creator and CMake.

Saturday, April 21, 2018

VMPK 0.7.0 released


It has been a while! First of all: thank you very much for the million downloads of VMPK! It happened in 2016, but I wasn't paying attention at the time. I didn't post any article around that event, neither released a new VMPK version since that year, so let's cover both things.

Download statistics

Born in 2008, this project is multiplatform from the beginning, with the goal of emulating a MIDI controller device on software; which means: producing (and consuming) MIDI events. The producing part requires another source of human triggered events: computer keyboard, mouse and touch screen events are supported and available on the three main target operating systems. But producing MIDI events without delivering them to a MIDI Synthesizer makes the program useless, with no sound output at all. This has been the experience of most new VMPK Linux users for years. Windows users have a software synth included in the operating system, installed and ready to use, so they may produce sound as soon as they install VMPK from scratch. But Mac and Linux users need to find and install first a suitable synthesizer. Mac OSX also includes a soft synth library, but it is not a ready-to-use service and needs to be activated by a third party software. It's not very hard to find and install, because Apple has always made MIDI users a niche for their products. Good for them.

I've been approached last year by Microsoft people to package and publish VMPK into their Windows Store for Windows 10. Probably the million downloads has something to do with it. I've tried the packaging part without technical problems thanks to the support of the MS Desktop Bridge team, but the store conditions were awful, arbitrary and unfair, so I am not willing to comply with them. This means that VMPK will be available only outside the Windows Store and there won't be an UWP or Windows Phone version either in the future. I don't want to speak about the Apple's App Store. To the hell with them as well.

Linux users have been often made hostages of their distributions and packagers. In theory, the package repositories of each distribution (equivalent to an app store) are made for easy discovery and install of all the software available for Linux, but this is not true in practice. Software integration from different unrelated sources is also the job of the Linux distributions, which they miserably fail as well. I mean that when saying hostages, because the packagers sometimes act as if they want to force their users to follow their own personal preferences, like the gurus of a sect: Jack is the chosen one!!! PulseAudio is evil!!!

More about that later. Let's listen an enlightening Linus Torvalds first:


OK Linus. I've released this time an AppImage package for 64-bit Linux. OTOH, I'm still using Subversion and not planning to migrate the source repository to Git anytime soon.

What I think it would be a good VMPK distribution? Well, first of all, the latest version should be available for install, optionally with some former versions available to choose if the users needs to compare something (like a bug resolved or introduced in the latest version). Second: main functions should be immediately available: the user must be able to simply get sound at once. For Linux, ALSA sequencer inputs and outputs must also be available without any other extra configuration. About network I/O: the Mac OSX and Windows operating systems automatically activate firewalls blocking this function but, as soon as VMPK starts the first time, the OS asks the user for permission to open the firewall for this software. Linux distributions that include an active firewall should listen and learn something here.

The latest VMPK release includes lightweight soft synths for Linux and Mac OSX, which were available as a Drumstick-RT library back-ends for some time. The Linux soft synth is Sonivox EAS, borrowed from Android OSP and ported to Linux + PulseAudio, which was already mentioned in another post.

It is the default output chosen by VMPK upon install, so you need to use PulseAudio if you want to try VMPK. Why the PulseAudio choice? Because it is the default Linux sound server in most distributions: Ubuntu, Fedora (Red Hat), OpenSUSE, etc. I know that there has been a lot of criticism among the Linux audio community about PA, but honestly: I can't care less about arguments that sound like fanaticism. Someone told me that: “many people in linux-audio avoid PA like the plague.” Well, I'm sure you know that many computer users avoid Linux like a plague, but I don't let a handful of haters to influence my decision of keeping VMPK available for Linux users. And at the end of the day, this is my personal project and I am who decide the road-map. This is also free software. If you don't like something or have good ideas to get it better, you may contribute with code or make your own fork.

Sunday, April 3, 2016

Taking Back From Android



Android is an operating system developed by Google around the Linux kernel. It is not like any other Linux distribution, because not only many common subsystems have been replaced by other components, but also the user interface is radically different based on Java language running into a virtual machine called Dalvik.

An example of subsystem removed from the Linux kernel is the ALSA Sequencer, which is a key piece for MIDI input/output with routing and scheduling that makes Linux comparable in capabilities to Mac OSX for musical applications (for musicians, not whistlers) and years ahead of Microsoft Windows in terms of infrastructure. Android did not offer anything comparable until Android 6 (Marshmallow).

Another subsystem from userspace Linux not included in Android is PulseAudio. Instead, OpenSL ES that can be found on Android for digital audio output and input.

But Android also has some shining components. One of them is Sonivox EAS (originally created by Sonic Network, Inc.) released under the Apache 2 license, and the MIDI Synthesizer used by my VMPK for Android application to produce noise. Funnily enough, it provided some legal fuel to Oracle in its battle against Google, because of some Java binding sources that were included in the AOSP repositories. It is not particularly outstanding in terms of audio quality, but has the ability of providing real time wavetable GM synthesis without using external soundfont files, and consumes very little resources so it may be indicated for Linux projects on small embedded devices. Let's take it to Linux, then!

So the plan is: for the next Drumstick release, there will be a Drumstick-RT backend using Sonivox EAS. The audio output part is yet undecided, but for Linux will probably be PulseAudio. In the same spirit, for Mac OSX there will be a backend leveraging the internal Apple DLS synth. These backends will be available in addition to the current FluidSynth one, which provides very good quality, but uses expensive floating point DSP calculations and requires external soundfont files.

Meanwhile, I've published on GitHub this repository including a port of Sonivox EAS for Linux with ALSA Sequencer MIDI input and PulseAudio output. It also  depends on Qt5 and Drumstick. Enjoy!

Sonivox EAS for Linux and Qt:
https://github.com/pedrolcl/Linux-SonivoxEas

Related Android project:
https://github.com/pedrolcl/android/tree/master/NativeGMSynth

Sunday, September 14, 2014

Notes about VMPK 0.6.0 for Desktops

Dear Blog,

It has been a long time, but a week later after the release it is time to discuss some aspects of the latest version of our Virtual MIDI Piano Keyboard for desktop computers.

Where to start? an interesting point is the change of architecture with the replacement of RtMIDI by Drumstick-RT. This library is new and homegrown, part of the Drumstick family which includes Drumstick-File and Drumstick-ALSA as well. The motivation to create it was the difficulty of extending RtMIDI with other drivers different to the ones chosen by his author. This was not a problem in the past, because the RtMIDI sources were always included in the application, and any customization was possible and easy. Now, thanks to the Taliban of Linux distributions forcing the dynamic linking of RtMIDI this is simply not feasible - to the hell with the freedom of Free Software!. Throwing away the ipMIDI backend was not an option. On the other hand, with Drumstick RT is not only possible, but new backends can be compiled separately and installed in the system without recompiling neither VMPK nor Drumstick, because they are in fact plugins. By chance it also has fixed the bug reported (in 2009!) in ticket #15: LinuxSampler did not appear among ALSA connections, because LinuxSampler MIDI port has no flag providing proper characterization and RtMIDI (unlike Drumstick RT) filters out that port.

The replacement of the RtMIDI library with Drumstick-RT was a long time plan, not only for VMPK, but for Drumstick as well, that finally took place now. I hope that this shall be a foundation for features like recording/playback in the future. The only thing that maybe would be missing for some users is the jack-midi interface, but on the other hand Unix users will enjoy native OSS support, and also FluidSynth direct output on all operating systems, meaning  also configurable SoundFonts: a very demanded feature for Windows users.

Another long time request finally implemented is the ability of displaying any number of keys, for instance 88 keys, instead of full octaves, starting with any arbitrary white note (ticket #39), like configuring 25 or 49 keys (depending on which device, laptop or tablet, and screen size you have). Congratulations to all the requesters and sorry for keeping you waiting for this feature so long.

Finally, the migration to Qt5 has happened. This means also replacing a dependency from Xlib to XCB, that hopefully will bring future support for wayland/whatever. The victim has been the keyboard grabbing feature, that was only working on Linux thanks to a now lost X11/Qt4 feature. I hope to bring it back in the future with a multiplatform implementation.

There are now binary packages for 32/64 bit Linux users that shall work on any modern distribution, in the form of installers packaged using the excellent BitRock InstallBuilder. That means including all the required dependencies inside the package, in the same way the libraries are included in the Windows and Mac OS X setup packages. In order to reduce the package weight, superfluous things like Jack support were excluded, because the new FluidSynth backend is intended to provide instant audio out of the box without requiring the users to search, find, ask, learn, install, try and tweak. Something that traditional Linux distributions have failed to do, in despite of their duty of integration and making the life easier to their users. I am pretty sure that many Linux distros will fail to provide VMPK native packages for this release like they did for the 0.5.x  series (see Debian, Ubuntu and Fedora repositories for instance). Prove me wrong, and this kind of binary Linux packages would be deprecated.

Saturday, April 2, 2011

The MIDI Connection


How to Connect MIDI Things with FluidSynth Using Several Operating Systems

We are going to address two scenarios. First, we want to connect FluidSynth with an external USB MIDI keyboard, so we can play the piano keys producing sounds in FluidSynth. Second scenario: connect Virtual MIDI Piano Keyboard (VMPK) to FluidSynth, so we can use the mouse and the computer keyboard to produce sounds. We are going to use Qsynth instead of the command line client because its graphic user interface is much more friendly for beginners, but it could be done with the CLI fluidsynth program as well. The external USB MIDI keyboard is the Edirol PCR-M50, which works well with Linux, Windows and Mac OSX. Also FluidSynth, Qsynth and VMPK can be used in all three operating systems, which gives the opportunity to unveil and understand the differences among them comparing the same scenarios.
  1. External USB MIDI keyboard
The PCR-M50 has one MIDI IN and one MIDI OUT standard DIN-5 sockets, and also an USB socket. We are going to connect the device and the computer using an USB cable.

In Linux, ALSA includes full support for this device in the “snd-usb-audio” driver, which should work out of the box. For the other operating systems, the first step should be installing the PCR-M50 operating system drivers. The keyboard comes with a CD-ROM disk including the drivers for Windows and Mac OSX, which may be also downloaded from the manufacturer's web site: http://www.roland.com/products/en/_support/dld.cfm?PRODUCT=PCR-M50

To verify that the device is working with the operating system...
  • In Linux, open a terminal window and type the command “cat /proc/asound/seq/clients”. There should be a “PCR” client, corresponding to our device.
  • In Windows, open the Device Manager in the Control Panel, and show the “EDIROL PCR” properties under the “Sound, video and games controllers”. It should state that the device is working correctly.
  • In Mac OSX, open the “Utilities/Audio and MIDI Setup” program, and you should see the “EDIROL PCR” icon. There is a “Show device info” option, that enumerates the available ports.
The USB interface provides two output ports and three inputs.
  • PCR MIDI IN/OUT corresponding to the DIN-5 MIDI sockets on the keyboard.

  • PCR1 and PCR2, assignable to MIDI messages. By default PCR1 is used for real time messages like note on/off, pitch bend, modulation controller, etc. so we want to connect this port to the MIDI input of FluidSynth.
You can find more information provided by the manufacturer.

Now that we know that the keyboard works, let's open and configure Qsynth and FluidSynth.
  1. Qsynth configuration
You should install both Qsynth and the libfluidsynth library or DLL. Recommended versions are FluidSynth 1.1.3 and Qsynth 0.3.6 or later (it is going to be released in a few days). The details depend on your operating system. You also need a Sound Font file, like the GeneralUser SF2 by S. Christian Collins

To configure Qsynth, open the program and press the “setup...” button to configure the engine. The name provided in the “Engine Name” box becomes the tab name later in the main window.
  • In the MIDI tab:
    • Check the “Enable MIDI Input” box.
    • Select a MIDI driver: “alsa_seq” in Linux, “winmidi” in Windows and “coremidi” in Mac OSX.
    • In Linux and Mac OSX, fill the MIDI Client name ID, writing something like “GeneralUser” (or any other meaningful name of your choice).
  • In the Audio tab, select the audio driver and other settings that you know work well with your computer hardware and your operating system.
  • In the SoundFont tab, add the “GeneralUser GS FluidSynth.SF2” sound font or any other soundfont of you preference.
  • Restart the engine to apply your settings.

Scenario 1 in Linux
To connect the keyboard to Qsynth there are several ways.
  • Using a terminal, and the ALSA CLI utility “aconnect” with a command line like this:
    $ aconnect PCR:1 "FLUID Synth (GeneralUser):0"
  • Using a graphic MIDI patch bay utility, like the ALSA tab in the connections window of qjackctl, or any similar program. Anyway, you need to connect the port 1 of the PCR device to the port 0 of FluidSynth.
  • Play your keyboard.

In Linux you only need to use the patch bay utility to create the connection. Once it is established, you may close the patch bay program without disturbing the flow of MIDI data.

Scenario 1 in Windows
Plug the keyboard first, then open Qsynth and press the “setup...” button.
  • In the MIDI tab
    • Select the “winmidi” MIDI driver.
    • In the MIDI Device, select the port “1:EDIROL PCR 1”
  • Restart the engine to apply your settings.
  • Play your keyboard.
The alternative to Qsynth is the command line interface:
fluidsynth.exe -o midi.winmidi.device=”1:EDIROL PCR 1”
In Windows you don't need a patch bay utility, because FluidSynth reads directly from the operating system device. This is the only way to do it in Windows, because the operating system doesn't create virtual MIDI ports for software programs, only for system device drivers.

Scenario 1 in Mac OSX
After you finished configuring the Qsynth engine, you need a patch bay program to connect the keyboard to Qsynth, like the one at http://notahat.com/midi_patchbay
You need to create a connection from MIDI IN = “EDIROL PCR 1” to MIDI OUT = “FluidSynth virtual port (xxxx)”. You should keep the patch bay program running while you are playing, because the connection is not persistent. You may save your configuration in a file, though.
FluidSynth creates in Mac OSX a virtual MIDI port, like in Linux/ALSA, and exactly like in this case, you need to create the connection between the keyboard and the soft synth using an external tool.

Scenario 2
We are going to trigger the synthesizer sounds using the Virtual MIDI Piano Keyboard. This is a software emulation of the hardware instrument used in the former scenario. The difference is that VMPK is another software application like Qsynth/FluidSynth. More information here.

Scenario 2 in Linux
First, run Qsynth, then VMPK.
VMPK's menu Edit->Connections opens a dialog box. In “Output MIDI connection”, select the item named “FLUID Synth (xxxx):0”. You don't need any patch bay, because VMPK is already providing a connection function in this dialog. You could use an external connection manager as well, of course.

In Linux/ALSA, all MIDI programs have their own virtual MIDI ports. The virtual ports and the device ports are equivalent.

Scenario 2 in Windows
In Windows, you can't connect the MIDI output of a program to the MIDI input of another program. This mechanism is not provided by the operating system, which only allows a program to read data from a MIDI IN device, or write data to a MIDI OUT device, using of course the installed operating system drivers. To overcome this limitation, the best solution is to install virtual MIDI cables, like the ones provided by MIDI Yoke (http://www.midiox.com/myoke.htm). MIDI Yoke is an operating system driver, without any hardware device associated. You may define how much cables are created at start up using a control panel applet. Each cable has two ends: a MIDI IN and a MIDI OUT. MIDI data flows from OUT to IN, so one program can write data to cable 1, and another program can read the same data from the other end of cable 1.

First, run Qsynth and press the “setup...” button.
  • In the MIDI tab
    • Select the “winmidi” MIDI driver.
    • In the MIDI Device, select the port “In From MIDI Yoke: 1
  • Restart the engine to apply your settings.
Run VMPK, and open the menu Edit->Connections. In “Output MIDI connection:” select “Out To MIDI Yoke: 1”, and press OK. Now you can play.

Scenario 2 in Mac OSX
First, run Qsynth, then VMPK.
VMPK's menu Edit->Connections opens a dialog box. In “Output MIDI connection”, select the item named “FluidSynth virtual port (xxxx)”. You don't need any patch bay, because VMPK is already providing a connection function in this dialog. You could use an external connection manager as well, of course.

In Mac OSX, programs can create virtual MIDI ports or communicate directly to other MIDI ports. Virtual ports and physical ports are equivalent.

Thursday, November 4, 2010

FluidSynth and QSynth: Mac OSX status.

Here is a summary of the latest changes I've made to FluidSynth and QSynth in Mac OSX.
  • CoreAudio driver now uses the HAL output AudioUnit. A new function has been added to enumerate existing hardware devices, and an option named "audio.coreaudio.device" with the same functionality as other FluidSynth hardware drivers. It can be selected in QSynth using the audio device combo box.
  • CoreMIDI driver option "midi.coremidi.id" now works much like the equivalent option of the Linux ALSA driver. Added support in QSynth for this setting.
  • FluidSynth has a new CMake boolean option: "enable-framework", default=true. It creates a Mac OSX style "FluidSynth.framework", a type of bundle that includes headers and libraries together (and other resources if required). This framework bundle is installed by default in "/Library/Frameworks". If this option is disabled at configuration time, the build system creates an Unix style dynamic library as before.
  • QSynth has also a CMake build system. It can use either the new framework or the old Unix style dylib. After compilation, you can copy/embed all the used frameworks (including FluidSynth) into the app bundle, running the Qt utility "macdeployqt". To build universal binaries, use a CMake argument like CMAKE_OSX_ARCHITECTURES=i386;ppc (all the dependencies need to be compiled using the same set of architectures).
Pending tasks: testing, packaging, documentation. Opinions?

Saturday, October 30, 2010

Good times are gone

My sabbatical is over, and all this month I have been busy on a full time job, programming Windows applications in C# for a living. For this reason I have not had much time to devote to open source projects, and the forecast is that this situation will not change in the near future.

In the past few months I have contributed as much as I could to the free software community with MIDI applications, an area I know well and where  there is not too much material, particularly on Linux. Result of this has been KMid2 and Drumstick. I have also maintained my previous projects: KMetronome and KMidimon. About VMPK, this month has beaten their previous records on SourceForge with more than 10000 downloads in October. Thank you very much to all Mac and Windows users who trusted this software, and of course to all participants, contributors and translators who made it  possible. In Debian, the situation is also "fantastic", with 137 installations to date, and only one release late. I have no data on other Linux.

Monday, April 26, 2010

Apples and Oranges

KMid is now a multi-platform application for Linux, Windows, and Mac OSX. It may be the right time to make a comparison between the different operating systems with regarding to the development of KMid backends.

First, the functional components needed by a KMid backend

  • Read and parsing of SMF: MIDI and Karaoke files. This mechanism must offer not only timestamped MIDI events, but also the metadata (for instance, song lyrics) embedded into the SMF data.
  • Facility for sequencing MIDI events. Events read from a file are labeled with timestamps, to be delivered to MIDI synthesizers at the right times, handling also common player actions like play, pause and stop.
  • Internal and external, hardware and software MIDI synthesizers. The main goal of KMid is to support external musical instruments, but as many potential users do not have one, it is interesting to be able to use software synthesizers, in a transparent way without complicating the program design.
Organization of the backends

KMid::Backend is modelled after several Phonon interfaces. There is not a dependency on Phonon, only inspiration and Copy&Paste. There is a KMid::MIDIObject abstract class that resembles more or less a Phonon::MediaObject, encapsulating the sequencer functionality, and a KMid::MIDIOutput class representing a MIDI output port, similar to Phonon::AudioOutput. Main differences are:

  • KMid::MIDIObject time is measured in musical time (ticks) instead of milliseconds. Some additional properties: timeSkew, textEncoding, lyrics. Several signals, one for Each MIDI event type and metadata, feeding the program's graphic interface animations: lyrics highlighting, visual metronome, channel meters, and piano player keys.
  • KMid::MIDIOutput has pitchShift and midiMap properties. Volume and mute properties take a MIDI channel argument. There are also some real-time MIDI event slots, one for each MIDI event type, used by widgets like the channel instrument selectors or the piano player keys when they are triggered by the mouse or the computer keyboard.
Linux

ALSA provides a very advanced MIDI sequencer. The API is big and cumbersome to use in a KDE program, so I've developed a library layer, named "drumstick-alsa", providing a C++/Qt4 wrapper around it. ALSA does not provide a mechanism for reading and parsing MIDI files, so there is another library named "drumstick-file" taking care of it. In ALSA, MIDI hardware and software clients are all equivalent and there is a routing mechanism between MIDI OUT and MIDI IN ports, fully transparent and very powerful, where either of the two ends of the connection can be a program or a MIDI device driver. Of course, the data transmitted by the communications connection uses the standard MIDI protocol. KMid creates a MIDI output port externally visible, to be connected to a MIDI synthesizer, and also private loopback ports (input and output) which are used for visual feedback in the graphic interface (highlighted lyrics, metronome, piano keys...) The MidiPlayer class schedules MIDI events to a loopback port, which are received in time and propagated activating the signals emitted by the MIDIObject class and at the same time are sent through the MIDIOutput class to their final destination, which is any kind of MIDI synthesizer.

Any software synthesizer that is also an ALSA sequencer client can be connected to the MIDI output of KMid. Although not strictly necessary, for the users convenience it is possible to enable and launch FluidSynth or TiMidity++ on KMid's initialization. Unfortunately, a software synthesizer receives MIDI events and converts them into digital audio, and here  is where some users may find problems that go beyond the scope of KMid (ALSA/Jack/OSS/PulseAudio..., you know). In addition, a software synthesizer may require soundfonts. Enough to say that Linux distributions should package and integrate all the components that the users may need. The owners of external MIDI musical instruments are lucky, because they are quite well supported by ALSA.

Windows

The operating system provides the same MIDI support since the days of Windows 3.1 practically without any changes. Windows cannot connect the MIDI output from a program to the input of another program, only to a system driver, so the synthesizer must be external, or having a device driver, or using MidiYoke or any other similar solution. However, Windows provides a software synthesizer unconditionally installed and activated, so the Windows backend does not have or need a soft-synth configuration page.

The MMSystem API does not provide virtual MIDI ports, nor transparent MIDI routing, so the strategy of playing to a loopback port as in Linux is simply not possible. What is possible is to use "custom" midi events and define a callback function that is invoked whenever the time arrives to play a scheduled MIDI event. This is how all the visual feedback is implemented. The system libraries do not provide reading and parsing of MIDI files, so drumstick-file is used.

Mac OSX

The operating system provides all kind of MIDI support services, starting with reading and processing of MIDI files. If we compare the AudioToolkit SMF processing API with drumstick-file, the latter provides a model similar to XML-SAX, while AudioToolkit would be similar to XML-DOM. After reading the MIDI files, the results are explored to extract the required metadata, and an additional track is added containing the "custom" MIDI events for visual feedback.

Virtual MIDI ports are fully supported, with routing and full transparency between applications and devices, so the loopback port strategy works exactly the same as in Linux/ALSA. The Apple software synthesizer is an object of type "AudioUnit", and requires activation before a program can use it, so the Mac OSX backend has a simple soft-synth configuration page. The DLS soundfont provided by Apple is made by Roland, like the Windows one.

Conclusion

The LOC numbers needed to implement each backend are very similar: mac = 2358, windows = 2435, alsa = 2715 (not counting drumstick), and its complexity is also similar. Despite the different features offered by each platform, it is possible to implement KMid backends presenting the same programming interface to the application. We can create new backends in the future using the existing ones as models, or duplicating the "dummy" template that exists in a directory with the same name in the source repository.

Thursday, April 1, 2010

KMid in Mac OSX

This is not an April Fool's joke. KMid is running in Mac OSX, native:


I've developed KMid's Mac native support using Fink, that includes KDE SC 4.4.1

By the way, there are fresh news at Fink web site: "Effective 1 May 2010, we are going to cease work on our Mac efforts, and switch to development for the iPad, iPhone...". Oh, wait! today is April 1st...

Now seriously. You need: Xcode 3.1.4, that provides GCC 4.2
And some dependencies from Fink: kdelibs4-mac-dev, kde4-buildenv, cmake. These packages require some other dependencies.
Recommended: bundle-kde4-mac. This set is very large, and includes everything for a complete KDE environment.

KMid doesn't use Phonon. The native Mac OSX backend uses CoreMIDI and CoreAudio, and the Apple DLS soft synth enabled by default. Everything is included in OSX. Receipt:

1. Get the sources from the repository:
$ svn co svn://anonsvn.kde.org/home/kde/trunk/extragear/multimedia/kmid/

2. Prepare the build environment:
$ export KDE4_TYPE=mac
$ source /sw/sbin/kde4-buildenv.sh

3. Configure, compile, install:
$ cd kmid
$ mkdir build
$ cd build
$ cmake .. -DCMAKE_INSTALL_PREFIX=/sw/opt/kde4/mac -DBUNDLE_INSTALL_DIR=/sw/opt/kde4/mac/bin
$ make
$ sudo make install

Enjoy!