Future of KMid

The next version of KMid is in the kitchen right now, and it will have 2.4.0 as identifier. Tentatively, August 15th shall be the release date.

The main novelty is KMidPart, a component that implements the interface KMediaPlayer, playing MIDI/Karaoke files and using KMid infrastructure. The component shares the same configuration as the main program, so by default the MIDI port selection and Soft Synth will be common. This component by default shows only a play/stop combined button and a slider for the time position, in addition to the actions Play/Pause/Stop. Hidden, but selectable by means of KMediaPlayer::View interface methods, there are several additional controls: pause button, volume, pitch transpose and tempo (speed). The following pictures show the minimum and complete user interface respectively.

Once installed the new version of KMid, the KMidPart component is immediately available in Konqueror, either as file manager or web browser, since it is a simple standard KParts/ReadOnlyPart service. Examples of web sites that can benefit from this component can be anaigeon.free.fr and greekmidi.com.

Of course, this component is available to all fellow KDE developers so they can include MIDI playback in other programs. The programming API is quite simple, as demonstrated by two examples in C++ and Python included in the examples directory. If the KMediaPlayer interface is not enough, there are other methods and additional signals available through DBus.

From here, KMid will continue to evolve. I am considering further integration with KDE desktop technologies. For example, standard MIDI files are not scanned or indexed currently, but much of their metadata could be exploited with Nepomuk: tonality, rhythm, tempo, number of tracks and instruments. The settings of the songs, now stored in individual text files, may also be candidates for better integration. Another candidate for integration would be Solid, publishing system MIDI ports. Integrating KMid backends in Phonon can not be addressed at this time, but maybe in the future Phonon may evolve and such integration become possible.

Further integration into KDE unfortunately means less chance for KMid users of using it on Windows and Mac OSX. Although there are ports of KDE for those operating systems, both communities are not very active. I have received a suggestion that KMid does not need to depend on KDE, but only Qt4. This would make possible to distribute KMid binaries for Windows and Mac easily. I'm not especially interested in this option, followed for instance by the Rosegarden project, sacrificing both functionality and community by this way.

MIDI en las Jornadas

El pasado viernes 2 de Julio se celebraron en Barcelona las IX Jornades de Programari Lliure (jornadas de software libre). Este año han tenido un formato abreviado de un solo día, y han sido organizadas por la Politécnica de Catalunya. Los contenidos han girado en torno a dos ejes: el software libre y los contenidos libres en la educación, y el software libre en la empresa.

Al tratar de educación y software libre, lógicamente se ha hablado del programa eduCAT1x1 de la Generalitat, que básicamente consiste en entregar un ultraportátil a cada alumno e implantar el libro de texto digital; así como de Linkat, la distribución de Linux educativa del Departament d'Educació.

Mi intervención se ha titulado "MIDI en Linux". He presentado brevemente los programas KMid, KMetronome y VMPK con especial énfasis en las posibilidades didácticas en el ámbito musical de dichos programas y de la tecnología MIDI en general. Muchísimas gracias al público asistente y a la organización por su cálida acogida.

A pesar de su brevedad, el contenido de las mesas redondas y las conferencias ha sido interesante, ameno y en algunos casos no exento de polémica, lo cual también es enriquecedor. Espero con impaciencia las jornadas del próximo año.

D-Bus in VMPK

Yesterday, I've released VMPK 0.3.2 with a new D-Bus interface. VMPK is not a KDE application, it uses only Qt4, so a D-Bus interface wasn't included by default. This VMPK feature is far from perfect, and it will require some improvements in future releases, but it is a start.

What can be done with this D-Bus thing? D-Bus provides a mechanism to send and receive messages between processes (it is an IPC, inter process communication mechanism). This allows one application to be controlled from another one, or from a script. This is the classic application automation scenario solved in Windows with COM/DCOM, and in Mac OSX with AppleScript. D-Bus is a cross platform solution, with nice Qt4 bindings: the module QtDBus. The Qt4 SDK for Windows doesn't include this module, and anyway the bus daemon and libraries are external dependencies. D-Bus has been adopted in Linux by the KDE and Gnome desktops replacing other former solutions.

As use case demos, in a directory named "dbus" of the VMPK source tarball, there are a Bash script playing a simple tune and two Python scripts showing how to remotely execute actions and receive signals from VMPK. Another interesting use case for this D-Bus interface is to define new hot keys to send MIDI messages using VMPK. For instance, let's define Alt+S to send a sustain=100 control change, and Alt+Z to send sustain=0. Here is a brief how-to for the KDE desktop.

To configure hot keys in KDE, run the program "Personal Settings (Configure Desktop)", and select "Computer Administration" -> "Input Actions", or launch the command 'kcmshell4 khotkeys' from a terminal. Here you can create a new group with the name "VMPK", and two new actions (new -> global shortcut -> D-Bus command) for your controllers. Name your actions for instance "sustain on" and "sustain off", and assign the key strokes in the tab labeled "Trigger". In the tab "Action", the data for "sustain on" is:

Remote application: net.sourceforge.vmpk
Remote object: /
Function: controlchange
Arguments: 64 100

The arguments are a pair of numbers, first the controller number, and then the control value. 64 is the sustain (hold1) controller, and 100 is the value. The arguments for the "Sustain Off" are "64 0".

You must activate the check boxes in the actions tree, to enable the new hot keys. You can also set conditions for the group, for instance checking that the window title or class matches the VMPK main window.

Note that you need to compile VMPK with ENABLE_DBUS activated. The binary packages for Windows and Mac OSX don't have this option enabled.

Binary packages? didn't say I something about stopping to ship binary packages of my programs? Yes, there are no binary Linux packages for this VMPK release. The question is that I can provide a single VMPK package for Windows that includes all dependencies (a few Qt4 and runtime DLL), and this package runs in XP, Server, Vista and Windows7. Same for Mac OSX, where I can provide a single application bundle compiled in Universal mode (x86 and PPC) including all the dependencies as well. The burden for Linux is the existence of RPM and DEB package types, with differences among several distros, and several versions, and processors, and whatever. VMPK is provided by several major distros already. If it is not yet included in your distro, open a request in the distribution tracker or compile it from sources.

Weird KMetronome

After a long development cycle focused almost exclusively on KMid, it's time to give some love to other projects. I've been working lately on KMetronome, a MIDI metronome for KDE and ALSA. It is the oldest project of my little family.

The only issue in KMetronome's tracker is this one year old request, which has suggested the title of this post. The "Weird Metronome" is a popular simple MIDI metronome for Windows, which is the origin of "Open Metronome".

The major advantage of Weird / Open Metronome is the definition of rhythm patterns. The drawback is that it only works on Windows. It may be a good idea to make a Linux port. His definition of patterns is very simple and elegant, if somewhat limited. It has two branches: one producing MIDI events, and the other producing digital audio.

Although I can't rule out porting Open Metronome to Linux in the future, I've decided to implement the pattern editor differently. Here are some screenshots of the upcoming version 0.10 of KMetronome, dressed in Skulpture style.

Settings

Like KMidimon and VMPK, now KMetronome also uses an instrument definition file in .INS format, the same format as Qtractor, TSE3, Cakewalk and Sonar. I've added an "Output instrument" drop-down list in order to choose one among the standard General MIDI, Roland GS and Yamaha XG drum maps. You can add more definitions creating a file named "drums.ins" at $HOME/.kde4/share/apps/kmetronome. The options "Bank", "Program", "Weak note" and "Strong note" are now drop-down lists as well.

Main Window

There is a new button "Patterns" opening the rhythm pattern editor, and a drop-down list to choose the pattern. The default "Automatic" value means that the program generates the pattern as usual, using the notes set in the configuration dialog (Strong / Weak) and the rhythm definition provided by "Beats / Bar" and "Rhythm figure". The same drop-down list contains also the names of the user-defined patterns.

Pattern Editor

This is a new dialog box. You may edit, test and select patterns with it. To create new patterns, you simply save the current definition under a new name. Patterns are represented by a table. The rows in the table correspond to the percussion sounds. You can remove and add rows from a list of sounds defined by the instrument settings in the configuration dialog. The number of columns in the table determine the length of the pattern, between 1 and 99 elements of any rhythm figure.

Each table cell accepts values between N = 1 and 9, corresponding to the MIDI velocity (N * 127 / 9) of the notes, or 0 to cancel the sound. Valid values are also "f" (forte) and "p" (piano) corresponding to variable velocities defined by the rotary knobs (Strong / Weak) in the main window. The cell values can be selected and modified using either the keyboard or the mouse. No need to press the stop button before modifying the cells ...

This version is not ready yet, but will be probably published by the middle of next month. For now, you can get the sources from the Subversion repository. You need to install Drumstick before compiling it.

By the way, I'm planning to stop distributing binaries for all programs. If you like them and your favorite Linux distribution does not include Drumstick or KMetronome, it would be a good idea to start opening bug reports in its  enhancement request system, or sending messages to the distribution's mailing lists or web forum.

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.