Showing posts with label music. Show all posts
Showing posts with label music. 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!

Sunday, August 14, 2022

Drumstick Libraries 2.7.1 Released

Drumstick is a set of MIDI libraries using C++/Qt idioms and style. Includes a C++ wrapper around the ALSA library sequencer interface: ALSA sequencer provides software support for MIDI technology on Linux. A complementary library provides classes for processing SMF (Standard MIDI files: .MID/.KAR), RIFF MIDI (.RMI), and Cakewalk (.WRK) file formats. A multiplatform realtime MIDI I/O library and a GUI Widgets libraries are also provided for Linux, Windows, and Mac OSX.

This is another sonivox related release. Please see: https://github.com/pedrolcl/sonivox

I didn't want to make the sonivox dependency mandatory, because there may be good reasons for an user to avoid building drumstick with all its features. A final user may be interested in FluidSynth output only (which is also an optional feature) or even using ALSA sequencer only, without any soft-synth at all.

But what is a legitimate choice for a final user may be a questionable restriction for a distribution, because you may not know all use cases of your users. In this case, SonivoxEAS is the default Linux output for drumstick-vpiano and VMPK, because I think that any user installing those programs the first time should be able to hear sound by default, without needing to configure/investigate about MIDI or SoundFonts. Otherwise, there will be many users complaining that their Linux virtual pianos do not produce any sound!

On the other hand, until now the sonivox library sources were embedded inside the drumstick source tarballs, and statically linked to the SonivoxEAS backend. This was against most Linux distros packaging policy. Providing an standalone shared library instead, the issue has been fixed.

Changes in v2.7.1:

  • Fixed ticket #45: the sonivox library dependency (for the SonivoxEAS synth backend) is optional, and easily forgotten by 3rd party packagers. The build system configuration now fails with an error message if the sonivox library is missing unless the cmake variables USE_SONIVOX and USE_PULSEAUDIO are set to OFF. Same failure with the FluidSynth backend and the variable USE_FLUIDSYNTH, and the ipMIDI Network backend and USE_NETWORK.
  • Fixed underlinking in some RT backends.

Compilation minimum requirements for all platforms:

  • C++11 compiler
  • CMake 3.14
  • Qt5 >= 5.9 or Qt6 >= 6.2 (with Qt6Core5Compat library dependency for Drumstick::File)

Feature dependencies (for some platforms):

  • ALSA (Linux only)
  • PulseAudio (Unix)
  • D-Bus (Unix)
  • Sonivox (Unix)
  • FluidSynth (All platforms)

Copyright (C) 2009-2022, Pedro Lopez-Cabanillas License: GPL v3 or later

Project web site https://sourceforge.net/p/drumstick

Online documentation https://drumstick.sourceforge.io/docs/

Downloads https://sourceforge.net/projects/drumstick/files/2.7.1/

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.

Sunday, July 31, 2022

Dog days releases

It's hot weather these days here at Barcelona! It is also time for releases...

A new synthesizer library has been released on July 28, 2022: Sonivox. This project is a fork of the Android Open Source Project 'platform_external_sonivox', including a CMake based build system to be used not on Android, but on any other computer Operating System. Google licensed this work originally named Sonivox EAS (Embedded Audio Synthesis) from the company Sonic Network Inc. under the terms of the Apache License 2.0.

This is a Wave Table synthesizer, not using external soundfont files but embedded samples instead. It is also a real time GM synthesizer. It consumes very little resources, so it may be indicated in projects for small embedded devices. There is neither MIDI input nor Audio output facilities included in the library. You need to provide your own input/output.

Until now, the "eassynth" Drumstick::RT backend included the sonivox library sources, compiled and statically linked. Now, the build system search for an external sonivox library like any other dependency, and dynamically links the shared library when found.

Please find here the source tarballs.

There are two other projects/prototypes that use this library in my portfolio. They embed it as a git submodule, or find it as an external dependency:

I prefer to have all the code in a single place, avoiding duplication. But it is not only my personal convenience, Linux users would have a single copy of the library installed in their systems, which will be easier to patch or replace by the distribution vendors when needed. Of course this would be not possible if their only choice is to install the applications as an AppImage, or a Flatpak.

The other release today July 31, 2022 is Drumstick 2.7.0

A brief summary of changes for this release:

  • ticket #44: removed sonivox library sources from the source tree. The Sonivox library is an external dependency.
  • ticket #43: Drumstick::RT dummy plugins now include its own configuration dialogs.
  • ticket #42: Drumstick::Widgets - fixed piano designer plugin to show more properties.
  • ticket #41 Drumstick::Widgets: Option to use subscript octave designation.
  • Drumstick::ALSA registering SequencerEvent with qMetaType.
  • Drumstick::RT FluidSynth plugin updated with changes in fluidsynth 2.2.8
  • Utils: vpiano uses the subscript octave designation option.

Compilation minimum requirements for all platforms:

  • C++11 compiler
  • CMake 3.14
  • Qt5 >= 5.9 or Qt6 >= 6.2 (with Qt6Core5Compat library dependency for Drumstick::File)

Feature dependencies (for some platforms):

  • ALSA (Linux only)
  • PulseAudio (Unix)
  • D-Bus (Unix)
  • Sonivox (Unix)
  • FluidSynth (All platforms)

Downloads

Tuesday, April 5, 2022

Procrustes' Piano

In Greek mythology, Procrustes was a rogue smith and bandit. He had an iron bed, in which he invited every passer-by to spend the night. If the guest was shorter than the bed, he used his smith hammer to stretch them to fit. If the guest proved too tall, Procrustes amputated the excess length; nobody ever fitted the bed exactly. Procrustes continued his reign of terror until he was killed by Theseus.

In common language, a "Procrustean bed" is an arbitrary standard to which exact conformity is forced. Pianos are one example of "One size fits all" disregarding Ergonomics absolutely.

The number of keys is almost always 88, no matter that the lowest notes and the uppermost octave is rarely used. In fact, Mozart's forte piano had only 66 keys, and the keys colors were often reversed. Today, we can find instruments manufactured by Bösendorfer with 92 Keys and even 97 Keys, but other examples are rare.

But the worst arbitrariness is the keys size. As Lionel Yu explains, this is the Piano's Darkest Secret. It is not just the size of the hand that greatly influences performance, given the standardized size of the piano keys, but also may be the cause of musicians' serious injuries or physical disorders. Linda Gould tells his experience with narrower keys in My Piano Has a Secret. There are smaller size violins: 1/2, 3/4 adapted for young people; Why there are not smaller size piano keys as well? This is exactly what the Pianists for Alternatively Sized Keyboards organization is advocating: "If everyone plays the same size, most are playing the wrong size!".

I would like to be able to contribute more to making things better for pianists, but what I can do is making VMPK as flexible as possible. You can configure the number of keys as you wish: 25, 49, 88, up to 121 keys for ten octaves maximum (MIDI has a limit of 128 notes). You may also choose the initial note, and of course the octave shift (base octave) and transposition in semitones. The colors of the keys are also fully configurable, and the key size is the easiest thing: you only need to stretch or shrink the program window to adapt the key size to your taste and needs.

I've just published a new release of Drumstick Libraries 2.6.0 and VMPK 0.8.7, focused on fixing bugs like the handling of low level computer keyboard events (which wasn't working on Wayland before) and touch-screen events on Linux (Wayland and X11). The program can handle as many fingers as the touch-screen supports, but I've noticed that Gnome 41 on Wayland has built-in gestures with three fingers that can't be disabled (or there is not yet an extension/tweak to do so), and those gestures are the cause that you can only use two fingers on VMPK. Sorry!

Friday, March 18, 2022

Spring is coming

I've just released Barcelona Trees, Beta2 v0.0.4, which is just another extremely niche application, totally unrelated to MIDI, but also based on the Qt frameworks like my other free software projects.

The motivation of this program is to help Barcelona visitors or dwellers, answering questions such as:

  • What trees are nearby? (from manual or GPS location)
  • What trees are on a given street or garden?
  • Where can I find specimens of a certain genus/species?
  • For each specimen, obtain more information about its species from existing data on Wikipedia and public images.

screenshot

This may be useful in many ways, from Botany students to simply curious people. Barcelona has plenty of trees: almost 230k at this moment. And the Open Data BCN service periodically publishes several datasets cataloging the Geo-located specimens in public spaces that are used by this application.

Palau GC- tarongers0682-01

As an example, there are more than 3k Bitter Orange trees like the above (the Courtyard of the orange trees is not in a public place, it is inside an official building) used as ornamental. They are not edible in raw, but can be used for cooking. On the other hand, there are a few (dozens) other Citrus gender specimens that are truly edible, and you may find using the program. Enjoy!

Farewell

This release using Qt 5.15 may be the last one for this application. It won't be a Qt6 migration, because the Qt Location Maps have been removed in Qt6, but this may change in the future...

Another functionality lost in Qt6 is the QTextCodec class, removed from QtCore and moved to the Core5Compat module that has been already mentioned here, and provides conversion from many text encodings to Unicode. This issue has impacted applications reading MIDI files, and the Drumstick::File library. Well, I've tested two possible replacements...

iconv() is a POSIX API, and it is included in the C library of many Unix systems, like the GNU libc. This may be detected by cmake, and in this case no additional library needs to be linked to the application program, but the external libiconv is also supported when needed.

Character set detection was never provided by Qt. The iconv() POC uses the latest uchardet library (0.0.7 at the time of writing this), which only supports pkg-config. A newer version will include also support for find_package() and imported targets. On the other hand, libICU provides charset detection in addition to Unicode conversion.

Sunday, December 26, 2021

Winter Releases

In addition to the usual bug fixing, a common pattern across all projects are the changes related to the transition to Qt6, still experimental but mature enough, while keeping compatibility with Qt5. One stopper in this transition is the removal of the QTextCodec class in Qt6 core libraries, moved to the Core5Compat module, risking to be definitely removed at some point in the future. Some methods in Drumstick::File that depend on this class are deprecated now. This functionality is key for data preservation when parsing/importing MIDI files containing text metadata (titles, comments, names, copyrights, lyrics, markers, ...) encoded in any random scheme available in the last 30 years. But the alternative in Qt6 is the QStringConverter and related classes that only supports a very limited set of encodings, mostly Unicode.

This problem deserves deeper thoughts...

If we were talking about pure text files, this could be solved using for instance the iconv command line Unix utility, that converts text files from one encoding to another, for instance from ISO-8859-5 (Cyrillic alphabet) to UTF-8. Then, the new text file encoded in Unicode could be processed by a Qt6 program without limitations. But MIDI files are compact binary structures that can't be processed directly with that utility.

The second root of the problem comes from the SMF nature itself. The Standard MIDI File format was created as an interchange file format, so the music created in sequencers using proprietary storage formats could be exported and retrieved by another sequencer. Sequencer machines and software at one point become deprecated, stopping to work, and can't be used anymore. Composition files created in those systems are now digital garbage for the trash bin, except if the author took the precaution of keeping exported MIDI files. Those are now the equivalent of modern digital manuscripts, which we try to preserve and keep them readable for the foreseeable future within our musical applications.

Changes in Virtual MIDI Piano Keyboard v0.8.6:

  • Fixed advanced setting on connections dialog.
  • Enabled empty input connection after fix on drumstick-ALSA: requires external connections utility.
  • Better inverted piano colors after fix on drumstick-widgets: changed the white keys background picture depending on the key background color.
  • Removed dependency on Qt6::Core5Compat when building with Qt6
  • Requires: drumstick-2.5

Downloads: http://sourceforge.net/projects/vmpk/files/0.8.6/

Changes in Drumstick MIDI Player v1.5.3:

  • After drumstick ticket #37: WRK format markers are supported
  • Replaced deprecated signals from drumstick-file when building with Qt6
  • Requires: drumstick-2.5

Downloads: https://sourceforge.net/projects/dmidiplayer/files/v1.5.3/

Changes in Drumstick Metronome 1.3.0

  • Czech translation updated, by Pavel Fric
  • Qt6 compatibility fixes
  • New build options: USE_QT and BUILD_DOCS
  • Revised and updated documentation system: using Pandoc to create man page and help documents
  • New settings: qt style, forced dark mode, and internal icon theme
  • Added action icons: internal theme based on breeze
  • Desktop icon replaced

Downloads: https://sourceforge.net/projects/kmetronome/files/kmetronome/1.3.0/

Changes in Drumstick MIDI Monitor v1.2.0

  • Czech translation updated, by Pavel Fric
  • Revised and updated documentation system: using Pandoc to create man page and help documents
  • New build options: USE_QT and BUILD_DOCS
  • Qt6 compatibility fixes
  • Save recording fixes
  • Fixed mute track functionality
  • Fixed event playback highlighting
  • Support WRK file format markers, provided by Drumstick 2.5
  • Desktop icon replaced

Downloads: https://sourceforge.net/projects/kmidimon/files/1.2.0/

Changes in WRK2MID v1.1.0

  • New build option: BUILD_DOCS.
  • New Build option: USE_QT to choose between Qt5 and Qt6. Closes ticket #3.
  • Convert WRK track Port parameter. Closes ticket #2.
  • Convert WRK markers into SMF text markers. Closes ticket #1.
  • Displayed compiled and runtime library version information.

Downloads: https://sourceforge.net/projects/wrk2mid/files/v1.1.0/

Changes in Drumstick Libraries v2.5.0:

  • New build options: BUILD_ALSA, BUILD_FILE, BUILD_RT, BUILD_WIDGETS to control building only some of the libraries.
  • RT, VPiano: Fixed ALSA and CoreMIDI backends, enabling empty connections (for using external connection tools).
  • Deprecation of the Drumstick::File functions affected by the QTextCodec class removal on Qt6.
  • Raised macOS deployment target to 10.13 (High Sierra).
  • Widgets: changed the white keys background picture depending on the key background color.
  • VPiano: new option to display inverted key colors.
  • File: WRK format markers processing. Closes ticket #37.

Downloads: https://sourceforge.net/projects/drumstick/files/2.5.0/

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.

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

Friday, December 27, 2013

VMPK for Android

Hi, Blog!

A lot of time since the last post. Let me announce a new port of VMPK, for Android  (4.x) devices. It is available in Google Play.


There are two apps, a paid version (0.5€) and a free one (gratis) with a small advertisement. It is not based on Qt, and it is not open source. It is a Java port rewritten from scratch using the native Android MIDI synthesizer and native Android themes. But on the other hand, is quite similar to the old N9 port, as you can see in the following screenshots, but with several additional features.



Being mostly a Java app, it includes some C code. The internal MIDI synthesizer is Android's "Sonivox EAS", which is part of AOS. The library is included in all recent Android versions, but it is not a public API, so I've compiled the library with a customized configuration and different features resulting a smaller binary and included it in the APK along with some other native code, mainly opensl_stream by Peter Brinkmann for interfacing the synth with Android's OpenSL ES audio output. An interesting aspect of the synth is the embedded GM soundfont using very small amount of memory, and not needing external data files.

Some features are: ipMIDI compatibility (MIDI OUT only) using UDP multicast and Wireless network. Accelerometer driven sliders for velocity, controllers and bender (like the N9 port), configurable number of keys and initial key, among other goodies.


Happy holidays!

Saturday, January 7, 2012

Choosing MIDI or Digital Audio by Analogy

Whenever I talk to someone about the relationship between MIDI and digital audio, one of my favorite analogies is that of computer images.

A digital raster image like a JPG file contains a bitmap. It is equivalent to an MP3 file containing digital audio. Both JPG and MP3 files contain quality loss compressed data, although other formats such as BMP and WAV files can contain pictures and digital sound without compression, respectively. In both cases the files store a set of digitized values. In the case of images, the data are individual pixels or dots that represent colors of the cells in a matrix of rows and columns that divide the digitized image. In the case of sound, individual data are samples that represent moments of time which divides the digitized sound. The digitization consists in dividing alike the image or sound into small fragments, the number of which depends on the resolution we want to get and the size of the scanned original.

Another type of images is called vector graphics. They are not suitable to represent photographs, but drawings. SVG files that are used in many illustrations of Wikipedia are of this type. Instead of image fragments, they contain symbolic descriptions using coordinates of points, distances, lines, and colors... They have the advantage of scalability without loss of quality, and ease of arbitrary modification of some of its components and properties without affecting the rest. The equivalent of this technology in the world of sound is MIDI. A MIDI sequence contains timestamped messages such as notes, instrument changes, controls, etc.. Not a proper format for storing sounds recorded by a microphone, but a symbolic representation of music similar to a score.

Images are two dimensional objects, so the digitized images consist of rows and columns of elements (pixels), and the position of the elements of a drawing is characterized by a pair of numbers that represent its Cartesian coordinates. On the other hand sound recordings are one-dimensional, sound samples are taken at constant time intervals and also MIDI messages are labeled by their position in the time line.

The above similarities have implications that reflect additional parallelism. An uncompressed digitized image consisting of any single solid color takes the same amount of memory than an image of the same size representing a photograph or a complex composition of multiple colors. Similarly, a recording of silence (for example John Cage's 4'33'') takes the same amount of memory than any symphonic piece of the same duration. On the other hand, a simple vector image takes much less memory than a complex picture of the same dimensions. And a few notes MIDI sequence occupies much less memory than a complex sequence of the same duration made up of many notes or other messages.

The problems posed by digital images and sounds on stretch and reduction of dimensions are also similar. In both cases artifacts are generated, an effect known as 'aliasing', which can be offset to some extent by using 'antialiasing' filters. On the other hand, in the case of vector graphics as MIDI sequences, you can easily perform stretching and shrinking of dimensions and duration without risking artifacts or quality loss whatsoever.

Starting from a vector image, it is necessary a rendering engine to get a digital image that can be displayed on the screen or a printer. In the case of MIDI, a sequencer and a MIDI synthesizer are required to produce digital audio that can be used by an audio interface.

The programs Inkscape and Gimp, used in Linux for creating and editing vector graphics and digital images respectively, are comparable to the Adobe programs Illustrator and Photoshop. They cover different needs and audience, thriving on  different niches. An example of this type of niche is the architects, who use vector graphics to design and represent buildings with Autocad or similar programs. These are not watertight compartments. Gimp can import vector graphic files, rendering them as bitmaps. Inkscape can also import a bitmap image as a drawing object. In each case, the users may choose the best tool for each task.

While it has been easy to list some essential image processing programs for Linux and other systems, to do the same exercise in the field of audio and MIDI is much more risky. The problem is that the way musicians work with computers is not homogeneous, with each musician working in a different way. For old school types the ideal work-flow is to note down  musical ideas, develop drafts and refine compositions using tools that work with symbolic elements, producing as a final result a paper copy of the score. Rosegarden could be appropriate at this stage. On the other extreme, there are those who never in his life read or write a score, and whose only tools of creation (other than musical instruments) are the mixer and multi-track recorder. In this case, Ardour could be right.

The two applications mentioned above allow the use of digital audio and MIDI at the same time. In the same way as in the world of images, some applications are focused on the symbolic representation (MIDI) and others in a final product (digital audio). In each case, the use of the other technology will be subordinate. For instance, Ardour MIDI messages are aligned to the audio samples. It has even developed an API (Jack MIDI) to ensure synchronization of MIDI events to digital audio samples, subordinating MIDI to the rules of digital audio. Obviously this strategy does not fit adequately on all scenarios where MIDI is useful.

As in the imaging world, symbolic representation (MIDI) is probably better suited for design, drafting and composition. By contrast, digital audio is the dominant technology in the studio, at mixing stage and production, to obtain a finished product.

Sunday, September 11, 2011

SoundFonts want to be free

A "SoundFont" file  (suffix .SF2) is a definition of one or several musical instruments, which can be used with synthesizers (hardware or software) to render, or convert musical notes (eg MIDI files, suffix. MID) into digital sound, which can be used by an audio interface and speakers to play music. Another file format for the same purpose is DownLoadableSounds (suffix. DLS). Both include sound samples that can be entirely synthetic or digitized from real instruments.

General MIDI is a very popular specification, that among other things define a palette of instruments. The instrument #1 is a piano, #41 a violin, #57 trumpet, #74 flute... GM SoundFonts offer 128 instruments arranged in that particular order. GS and XG are extensions of this specification.

Linux needs GM soundfonts that could be distributed together with GPL programs, similar to the need of typographic fonts for text rendering applications. Many Linux distributions incorporate the FluidR3 soundfont in their repositories. It is free and produce good quality sound, but is not small: more than 140 megabytes. MuseScore distributes "TimGM6mb" soundfont, which "only" weights 5.8 megabytes.

There are several software synthesizers using SoundFonts. Well known are FluidSynth and TiMidity++, both with free licenses. One lesser known, but no less interesting, is Gervill. It is part of OpenJDK, and therefore GPLv2 licensed. It is implemented in Java, of course. I am not very fond of Java, and I do not usually use it except for commercial projects when the customer requires their use, but this time I will do it only for fun.

Gervill can use SoundFonts, DLS, or WAV files. A very interesting feature is the so-called "Emergency Soundbank", used when no other external SoundFont is available. Definitions of this SoundFont instruments are fully synthetic and follow the GM standard.

This EmergencySoundbank is a Java class, and does not reside on a file, therefore it can not be used on another synthesizer. However, nothing prevents us from creating a Java program that instantiates the class, and stores the instrument definitions on a disk file. How complicated may this program be? Let's see:

$ cat MakeEmergencySoundfont.java
import com.sun.media.sound.*;
public class MakeEmergencySoundfont {
        public static void main(String[] args) throws Exception {
                SF2Soundbank sf2 = EmergencySoundbank.createSoundbank();
                sf2.save("GervillEmergencySoundbank.sf2");
        }
}


7 lines is not much after all. Let's compile it:

$ javac MakeEmergencySoundfont.java
MakeEmergencySoundfont.java:5: warning: com.sun.media.sound.SF2Soundbank is internal proprietary API and may be removed in a future release
                SF2Soundbank sf2 = EmergencySoundbank.createSoundbank();
                ^
MakeEmergencySoundfont.java:5: warning: com.sun.media.sound.EmergencySoundbank is internal proprietary API and may be removed in a future release
                SF2Soundbank sf2 = EmergencySoundbank.createSoundbank();
                                   ^
2 warnings


We have earned two warnings for the naughty boys, because it is ugly to directly use classes in the namespace "com.sun.media.sound.*", and if the Oracle finds out our prank, he could lock the pantry. Here, take another cookie, Neo...

To compile and use this program you only need OpenJDK6 (runtime and compiler). For older Java versions you can get a "gervill.jar" from the project website.

Running the program produces a SoundFont file:


$ java MakeEmergencySoundfont
$ ls GervillEmergencySoundbank.sf2
-rw------- 1 pedro users 1.8M 2011-09-11 12:50 GervillEmergencySoundbank.sf2


The result weights less than 2 megabytes. Of course the quality of the SoundFont is not high, but it is better than installing nothing at all by default, leaving users wondering what do they need to hear something in their programs that depend on software synthesizers.

It is interesting that a similar technique, also very simple, can be used to produce other SoundFonts based on samples of arbitrary sounds. For more details, see the MakeSoundFont example in Gervill's repository.

Finally, a question remains about what license we can use to distribute the file "GervillEmergencySoundbank.sf2" generated by our program. As a general rule, the output of a GPL program has no restrictions. However, in this case the program output does not come from processing input data, but simply dumps the results of running the algorithms included in the EmergencySoundbank class. To play it safe, we should release it as GPL.

Saturday, August 27, 2011

Presenting VMPK for Nokia N950

I've been playing with my new and sexy Nokia N950 developer device, and here is the fruit: a newborn VMPK. I've just released a beta for testing, usable but not yet optimized. Please, try it. Your feedback will be appreciated.

Download VMPK & FluidSynth for N950 from sourceforge.net

I've learned two lessons from the Symbian port of VMPK published at Nokia's OVI Store: people expect that if a program looks like a piano, it should sound like a piano. It doesn't matter if the product description says that it doesn't produce any sound by itself. Dozens of comments in OVI Store page confirm that there is no hope that users read the description before downloading a program.

When I was doing some research for the Symbian port, I've discovered that creating sound always used very large audio buffers, no matter the method, producing about one second of latency or more. This is unacceptable for a musical instrument emulation, so network MIDI was the only available option. On the other hand, the Nokia N9xx uses Linux, including ALSA and PulseAudio among other usual infrastructure, so the latency is not a problem and FluidSynth is a perfectly sound complementary addition to VMPK.

Second lesson: an user interface that fits well in the desktop version of the program is barely usable on the mobile phone form factor. The solution is to create a new user interface using QML, the new declarative language for Qt user interfaces. The piano keyboard widget was already built around the Qt Graphics View Framework, so it only required to be wrapped as a QDeclarativeItem subclass and it was readily available as a QML object, to be combined with the Qt Quick Components for Meego library to build the new user interface. Here are some screenshots.

Main page, common controls are shown.

Main menu, note names option activated.

Preferences page.

About page.

Sunday, June 5, 2011

VMPK 0.4.0 Released

This release adds touch screen support (multi-touch) for all platforms, if it is supported by the OS and hardware. New RtMidi classes have been merged, which includes Jack MIDI support and a new network MIDI driver (UDP multicast) compatible with IpMIDI and QMidiNet. A Symbian^3 port has been made. There are new translations to Dutch and Swedish. A bug crashing the program when changing the octave base has been fixed.

My suggestion is to use the packages provided by your distribution when possible. If you prefer to compile the program yourself, I would like to give you some advices to build VMPK with the new features. First of all, you need CMake 2.8. The touch screen feature is available on all platforms, thanks to Qt >= 4.6 (but is better supported in Qt 4.7). There are two new build options:
  • RTMIDI_DRIVER: selects the RtMidi backend. The default one depends on the OS. Allowed values: ALSA, JACK, COREMIDI, IRIX, WINMM, NET.
  • PROGRAM_NAME: selects the executable name.
In Linux, you can compile VMPK with ALSA, JACK or NET drivers, but only one each time. You may build the program with different names, though, if you want several versions installed at once. For instance:

$ mkdir build-jack
$ cd build-jack
$ cmake .. -DRTMIDI_DRIVER=JACK -DPROGRAM_NAME=vmpk-jack -DCMAKE_BUILD_TYPE=release
$ make

$ mkdir build-net
$ cd build-net
$ cmake .. -DRTMIDI_DRIVER=NET -DPROGRAM_NAME=vmpk-net -DCMAKE_BUILD_TYPE=release
$ make

For the network version, there is a new help page here: http://vmpk.sourceforge.net/m/


Enjoy!

Friday, August 6, 2010

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"

Friday, May 21, 2010

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.

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!

Thursday, January 28, 2010

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