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?

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.

Drumstick Time

A new Drumstick version is in the oven, with two tasty novelties:

1. OVE file parsing support (files created by the Overture program).
The code for this feature has been contributed by Rui Fan. This file format can be played by the included program drumstick-guiplayer, in addition to the SMF and WRK formats. There is also a new drumstick-dumpove CLI utility to inspect the file contents as text.

2. Acquisition of real-time priority, using RealtimeKit.
Until now, the thread processing MIDI input from ALSA tried to acquire real-time priority using the RLIMIT_RTPRIO mechanism, which requires some configuration and administration work. If the above mechanism is not available, now Drumstick tries to acquire real-time priority from RealtimeKit.

This release is scheduled for sometime during next week.

What's next?

At this moment there are two libraries: drumstick-alsa (Linux) and drumstick-file. There will be two more: drumstick-win and drumstick-mac. The foundations of these two new libraries are already implemented in KMid2. On the other hand, it is desirable to unify all the backends for all platforms and file formats under a single set of multiplatform interfaces: drumstick-simple. VMPK will benefit from this, because replacing RtMIDI by Drumstick will be easier to implement features like MIDI file recording, playback and arpeggiator.

Electronic Music Stands

We are in full swing of electronic books, bubbles that are likely to explode into a new phase of the war between the old and new generations of publishers, content providers and consumers. It is likely that sheet music enter the battlefield.

Before proceeding I must warn you about two facts. One: despite the name of the blog, I am a Trekkie. Two: I am not a neutral observer. In my opinion traditional books publishing, as well as media labels, are going to lose. Those not able to adapt to changing times will disappear. Resistance is futile.

The musicians are going to adopt electronic lecterns sooner rather than later. The electronic scores begin to replace the editions printed on dead trees, as is already happening with books. There are some solutions on the market, more or less primitive.

MusicPad: Hardware and software.
How could you describe it? It is like a Kindle with legs. There is a "Master" version with twice the surface. Among its outstanding features: it is completely silent. Great virtue, because silence is also music.

MusicReader: Software only.
"The facto MusicPad Killer", they say. It is a program with Windows and Mac versions, which has more than just a page viewer. There is an optional accessory for turning pages with the foot. It can display half pages enlarged, as an aid to accessibility. Integrated additional functions: recorder, player, metronome and tuner.

eStand: Software for Windows, page viewer.

All of them are readers for electronic formats such as PDF or similar, showing pages, sections or page sets. MusicReader seems the most complete, yet is far from perfect. Some desirable features for an electronic music stand:

• Pages no, thanks. The pages have no musical function and are mainly a nuisance. No pedal to turn pages, automatic scrolling is much better. Bookmarks, notes, sections, movements, labels, individually numbered bars. Everything indexed and easily searchable.

• Size does matter. The musicians are supposed to have good ear, but nothing is said about sight. So it is better if the size of the staves is adjustable. For this reason, PDF is not very well suited for scores, it may be necessary to adjust the layout depending on the available area of representation. In this sense, the graphical representation of music resembles the visual organization of the widgets in graphical user interfaces.

• Content indexing, cross referenced, not only metadata but all the data resulting from semantic content analysis. For example: tessitura of the parts (lowest and highest notes used by each voice and instrument in the composition) for each one of the scores in the library. With this data available, it may be possible to filter the appropriate pieces for different levels of students. Publishers must provide rich metadata, MIDI sequences, critical texts, and musicological analysis. It is not just changing the medium of the product, it is about changing the cellulose based mindset, into another way of thinking based on information.

• Metronome. Probably many of the users will be students, so it will be convenient to have a metronome at the same place, taking the rhythm meter and the speed automatically from the values in the score. And of course, in addition to the optional audio reference, each bar should be highlighted while playing, keeping the current bar clearly visible in a central position, taking control of the scroll function, even when the metronome is quiet. Something like this.

• Pitch tuner, recorder, playback. Computer: add an accompaniment. Computer: change the clarinet by an oboe. Computer: pause recording ...

Star Trek TNG 6/8: "A Fistful of Datas"

• High connectivity: USB, Bluetooth, WiFi, Ethernet ...

• If there is a small or large group of musicians, they may want to synchronize the electronic stands, loading and unloading documents and synchronizing the timers/metronomes.

We already have almost all the required technology as free software:

• Music Typesetting, engraving PDF or PostScript scores: Lilypond.
• Programs, libraries and components to display these documents: Okular.
• Sequencers, synthesizers and MIDI players: KMid.
• Free content: www.mutopiaproject.org

We have the opportunity to occupy a niche in musical education, and from here future musicians shall develop the habit of using free software. Perhaps with time, even to generate free content.

Star Trek Voyager 5/22: "Someone to Watch Over Me"

Diagramas de Venn de las tribus de software

A los calores propios de la temporada estival, se han unido hace poco los de la última polémica sobre los males del tribalismo. El artículo de Aaron se abre con una frase hecha, que significa que cuando tomas una decisión debes aceptar sus consecuencias. Algo así como nuestro "cosechar lo  sembrado". Supongo que se refiere a las decisiones de Canonical, y que el chorreo que le está cayendo es su consecuencia. También se puede traducir literalmente al castellano e interpretar como una metáfora: hemos construido nuestras camas, y ahora dormimos en ellas. Eso es lo que hacemos las comunidades humanas. Los del software libre también, pero en general los humanos vivimos en tribus de forma cómoda y natural, y lo difícil es superar ese tribalismo atávico e innato colaborando en metas comunes a toda la especie. Y el problema es que la rivalidad entre tribus degenera a menudo en sectarismo de la peor especie, y de ahí la amarga queja de Shuttleworth.

El hecho de que existan dos tribus independientes, Gnome y KDE, en el mundo de los escritorios de software libre a mi me preocupa bastante poco. Cuando necesito un programa para solucionar un problema concreto suelo buscar entre las ofertas de opendesktop.org, que me presentan distintas opciones a elegir entre kde-aps.org, qt-apps.org, gtk-apps.org y otras. Hago aquí un inciso para decir que no me gusta demasiado esa organización, que sugiere alguna especie de guetos. Al final me quedo con la aplicación que me guste más, y a veces con más de una por el mismo precio, y ya elegiré con el tiempo. Otros no comparten la misma filosofía, y van de compras con el requisito irrenunciable de que los programas han de estar construidos con una única materia prima, pura y sin contaminación. Casi como una cuestión religiosa. Sus juguetes del Sect'R'Us, si se me permite el juego de palabras.

En este diagrama de Venn que es el Mundo, comparto una pequeña intersección con los habitantes de la tribu de los linux-audios. En algunos artículos recientes del planet.linuxaudio.org, alguien buscaba un reemplazo a su querido y viejo editor de textos NEdit de toda la vida para escribir programas. Gedit sería su alternativa natural, salvo que no satisface algunas características:

• Buscar y reemplazar usando expresiones regulares o texto simple.
• Buscar y reemplazar en todo el documento o solamente el área seleccionada.
• Resaltado de parejas de llaves, paréntesis y corchetes.
• Modos de edición específicos para lenguajes de programación, con auto-indentación.
• Macros, como mecanismo de extensibilidad que permita una mayor personalización.
• Atajos de teclado, por ejemplo para saltar a una línea concreta del documento.

Como el blog en cuestión no permite publicar comentarios, me he quedado con las ganas de recomendar Kate, que cumple de sobra con todos los puntos anteriores y no es muy diferente del reemplazo elegido: Geany. De hecho, Kate es el editor preferido por buena parte de mi tribu en esta otra intersección del diagrama de Venn. Pero a pesar de todas sus ventajas, algunos ni se plantearían su uso simplemente porque está basado en KDE.

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.

KMid in Windows

KMid is aimed at a wider audience in this next version. This song was generated with MMA (Musical MIDI Accompaniment), and it is included as a new example.

History of KMid

KMid was originally created by Antonio Larrosa. According to his website, the exact birth date was the 11th of September of 1997.

KMid initially ran in Linux and FreeBSD using the OSSv3 MIDI sequencer. The release 1.0 coincided with the KDE1 publication in 1998, and version 2.0 with KDE2 in 2000. It was ported later to KDE3. Version 2.0 and was functionally very similar to KMid2, having already ALSA support.

I've started using KDE by 2002, along with the initial KDE3 releases. At that time I also became involved in the development of Rosegarden, a KDE program for music edition using MIDI technology, and used KMid frequently. The main drawback was the inability of teaming KMid with other ALSA sequencer based programs, because the play/pause/stop actions created and destroyed KMid's MIDI ports, preventing reliable external connections made by other programs like aconnect or qjackctl.

In Akademy-es 2006, that was held in Barcelona, I met Antonio and explained him my concerns about KMid, and subsequently exchanged some patches by email trying to solve the implementation of libkmid regarding the ALSA sequencer. However, any solution explored involved binary incompatibilities, so the issue was out of the question within the KDE 3.5 development cycle.

On the other hand, KDE4 development started and OSSv4 was published, so there was no need to support OSSv3 anymore. The transfer of KMid in the SVN repository from kde-multimedia to extragear provided more time and freedom to rethink the software architecture and develop a new implementation.

KMid2 was developed as a revamping of the original KMid, with the following main features and goals:

• Playback to external MIDI devices.
• Allow to use software synths as well, like TiMidity++ and FluidSynth.
• Change tempo and volume controls. Add a key (transpose) control.
• Independent MIDI channel mute control.
• Support for many character encodings for lyrics, and configurable fonts.

Additional short-term goals:

• Remove the deprecated OSSv3 /dev/sequencer interface support, dropped from OSSv4 anyway.
• A fair ALSA sequencer backend implementation: do not create/destroy the client and port instances on each play/pause/stop action. This enables the usage of a MIDI Patch Bay application like aconnect or qjackctl.
• More native backends for other platforms.

Version 2.2.2 was released on March 15th, 2010, closing the initial implementation cycle. The next release 2.3.0 will be published within a few weeks, including new native backends for Windows and Mac OSX.

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!

Loving Music

I love music even more than I love computers. And here is a new KMid2 release, for all the music and KDE lovers. It has several new features, but that is something that you can read in the announcements or the ChangeLog. There are also four new songs replacing the old examples coming from the original KMid. It was not clear the license of those files, so I've created new ones. Like the two first examples (Ay Linda Amiga and Mozart's Ave Verum) the songs were edited in Rosegarden, more or less tweaked, and finally exported in SMF format. The sources of all the songs are the scores published by the Mutopia project. The LilyPond process that creates the beautiful PDF scores also produces MIDI files that have been imported into Rosegarden as the foundation for the final products. Here are the addresses and references, and one rendering as audio.

Schubert (1797-1828): Ave Maria (Ellens dritter Gesang)
Mutopia score
Wikipedia article

The following rendering has been produced in FluidSynth using the General User soundfont.


Mozart (1756-1791):
Der Hölle Rache kocht in meinem Herzen (Die Zauberflöte / The Magic Flute - No. 14 Arie)
Mutopia score
Wikipedia article

Dies Irae (Requiem)
Mutopia score

Handel (1685-1759): Hallelujah (Messiah)
Mutopia score

MP3 killed MIDI?

Of course not. At the turn of the 20th century everybody was saying that photography killed painting. And later cinema killed theatre, and television killed cinema. The last technological revolution, the digital one, killed the business of the record companies. And this time, it may be finally true...

MIDI is about making music, and making music is about musical instruments. After all, a business that remains still alive is the musical instruments industry. Not all the musical instruments sold around the world are bought by professional musicians. Most of the market are aficionados and hobbyists. Everybody would like, in one or another point of the life, to become a musician, or learn to play a musical instrument. Well, this is the place of the MIDI software in the desktop ecosystem. It is not about passively listening music, but using tools to inspect, interact, learn, modify, understand music. That may explain how VMPK had more than 5000 downloads from SourceForge last month. Even when it is not able to play songs by itself!

There was once a day something called "Pianola", a piano player product manufactured by the Aeolian Company. It was so popular that the trade mark has been adopted in Spanish (and in other languages as well) as a generic name, and entered the official dictionary. The company ended in bankruptcy about only 25 years ago, but the idea behind it still exists. The Disklavier models by Yamaha are offering today a similar functionality, but using MIDI files instead of punched paper rolls.

Well. All the above small talk was, of course, an excuse and introduction for another KMid post. The next week there will be a new release (0.2) of the program, after some changes triggered by an usability review. Big kudos to the KDE usability team and Diego Moya for his report! One of the new included features is the ability to launch soft-synths (TiMidity++ or FluidSynth) from inside KMid2, as child processes. The communication between KMid and the soft synths is handled by the ALSA sequencer, using the standard MIDI protocol. This has two consequences: the soft synths are still loosely tied optional dependencies, and the program is still able to communicate with external musical instruments, hardware synths, or many other soft synths, which is a very important feature for me. This also means that KMid is still for Linux only, because ALSA is only available for Linux (the Salsa library has only very basic ALSA features, and it is not enough for KMid).

There will be in the future other backends for KMid. I'm planning native backends for Mac OSX and Windows, using the native MIDI subsystems of each operating system, and also a backend based on libfluidsynth, which may be very comfortable for casual users, and available for more platforms.