Music, Programming and a Cat

Laborejo 2 Alpha Video DevLog


Youtube link to watch the videos

Here are five short videos so far.

I think they are good to watch.

So "like" and share and comment all this stuff, please!


The Linux Audio Company

money money money... is so ... *sob* -- 6/22/2014 -- Comments: 3

This is an article of the category "Let's talk about Next-Gen. Future ideas for Linux Audio" where I elaborate(!) on realistic near future improvements or unrealistic science fiction scenarios.


What we want

Music produced with Linux, assuming equal human skill and resources (=programs), will be better than music produced on other systems because the ecosystem, the concept, the workflow and the ideas are superior in Linux. And better tools and a better work environment leads to better music.


That said there is a resources mismatch between different operating systems, and Linux is not on the upside. To level out the playing field we need better resources (which is software, assets, presets, knowledge etc. )

Resources get better by throwing money at them. Because behind things are humans and they focus their work and concentration on things that keep them alive, at minimum. To stay alive you need money.

Money makes you happy, at least to the threshold that you have enough of it to don‘t think about money all the time.

We want happy and alive human creators. Creators of the above mentioned resources.


What we get

It sums down to the plain and simple thing: Creators of Linux Audio resources do not do what they love and want to do because the Linux Audio scene is mostly a place for hobbyist. Individuals who dedicate their spare time into a project, like a program, they love.

To sustain their live they are forced to maintain databases for insurance companies, put stuff into supermarket-shelfs and so on...

That is wrong.


Creating a Linux Audio company to hire the creators

It is not unheard of that people try to get money for their LA related work. In the vast majority of cases that totally failed.

I am not the perfect business man but I acquired some knowledge over time and watched my fair share of reports, talks and conversations about „Open Source and Money“.

So my conclusion is that not all options have been explored. A very big one is indeed missing: creating a company that hires the Linux Audio creators.

The important question is: What is a company able to do that individuals can‘t do? A few answers:


  • Other Companies like to talk to companies, not to individuals. And these other companies have money they would like to invest and spent. For various financial and reliability reasons it is much easier to deal with a company than with a single person, let alone a whole herd of individualistic programmers. A company can exchange staff and other companies (and individuals) can still talk about ongoing matters.
  • Contracts with a company are more reliable. This is especially true for for example support contracts. Not even death can stop such a contract.
  • Subsidy, Grants, Investments. Those are much easier to apply for if you are a company, especially the ones given out by a states or the European Union. Especially in the beginning these are important.
  • Concentrate efforts. Fund raising campaigns, donations, subscriptions. All those are much easier to handle legally and financially as well. No matter if they come from a company or individuals. On top of that the combined experience and knowledge how to handle and market those can be used to all the employees‘ advantage.
  • Financial and legal counselling. A company should care about its employees. It is much cheaper and effective to handle the legal and financial counselling for all involved people instead of each individual handling their own matters.
  • Protection. I don‘t know about non-EU businesses but at least here we have ways to protect businesses and companies so that people actually risk founding one. Even if a company goes bankrupt this does not mean that all the employees are in debt forever. But that would happen to individuals.
  • Public- and medial attention. Some cellar-nerd releases a piece of software? Who cares. An „open source team“ makes a point release? Boring. A company promises vapor-ware? World-news! (as seen countless times in actual media and on social media sites). There is simply more trust that a company can create and release things than individuals. That might not even be true but it certainly is the public opinion.
  • Easier Acknowledgement for serving the public good by other institutions and states. A new chance for the „Don‘t do evil“ motto.

How does such a company look like?

What I imagine sums up as „Let‘s keep it the way it currently is, but make our collaboration official“.

Open Source creators already collaborate and are dependent of each other. They make agreements to produce mutual beneficially products.

And they produce open-source licensed software, most prominent the GPL license and related products (assets, presets, knowledge etc.)

It should stay this way with the additional benefit that these people get paid regularly for their work.

Let‘s get to the important bits:


  • The goal of the company is to make profit. This profit, after investments, reserves and expenses, will be shared fairly amongst the employees. Therefore an equally important goal is to keep Linux audio creators alive and happy through a sustainable and predictable income.
  • Income will be generated by selling products, support-contracts, fund-raising, donations, events.
  • Authors keep their copyrights, intellectual property, the right to choose the license and so on. You create something, it belongs to you, no matter if you are at home or „at work“.
  • If your work is worth supporting financially by the company is decided the moment you get hired. There is no inner competition which software is most successful or popular. We are aware that the public opinion of a tool has little to do with its quality or usefulness. Correction: Not your work will be evaluated but you will be, through your work. If you are in the company all your future work will be supported.
  • Therefore authors choose what they are doing. There will be no company enforced projects on you.
  • Stay where you are. Do what you want. Work from home or your personal work-space. Keep your other jobs as piano teacher and your band.
  • To get hired (or to found the company in the first place) your ideology and license-philosophy must match the current views what is „good“ and „right“. In other words: Create GPL, MIT, BSD or other well licensed software or other resources or you will not get to participate.


On the other side there are some reasonable obligations:


  • „One for all and all for one.“. Above I wrote that it does not matter if your work is unpopular to the public if it is considered important by the company. The reverse is true as well. If you create popular products that generate more revenue you will still get the same share of the money as the other staff. This is to minimize risks and a fundamental principle of fairness and sustainability.
  • Support requests. It is to be expected that money will come in through support contracts or individual paid requests. Especially in the first phase after the company was founded this needs to be done by the authors themselves. There will be dedicated timeslots where you must be available for support to customers.
  • You are expected to route financial donations, sells etc. through the company. Maybe? Maybe not? I am uncertain. Maybe it really does not matter and if you want a donation button on your page or run or fund-raiser of your own then it is ok. The optimal situation should be that nobody wants to go on their own anyway, without any company-enforcement. That any campaign and sell through the company will be more successful anyway. This does NOT mean that you have to give up your brand or identity. Never forgot: You get hired because you are already doing a good job and deserve to get paid for that


Is this an unrealistic scenario?

Let me answer that with a famous internet quote: „idk lol!

I do not have magical abilities and I don‘t have private money to invest in this company to get it running in the beginning. This means we start at zero, or more likely a negative number, and there will be risk and work involved, especially in the beginning.

If you are interested in such a collaboration and live in the European Union feel free to contact me (or if you are very knowledgeable and know how to create a truly international company).

Let‘s do it!

Cologne Audio Meeting #01 - Done!

We hope to see YOU next time as well! -- 6/21/2014

Last wednesday I organized the first Open Source Audio Meeting Cologne  (which really translates to Linux Audio). It was great! There were nine people, as you can see in the picture. below.

Nine persons for an event with such a niche topic, in a rather local area, with little advertisment to get people to notice. That is huge!


The next one will be held on 20.08.2014 . If you are in the area you are welcome to visit, too! Just put your name on the list here!
The website for this event is

Naturally for a local meeting most of the people will speak German but if you want to present software, music or hold a talk in English please do so, by any means!






General Purpose Midi Import and Convert library

and the midi file said: "I'll be back..." -- 4/15/2014

This is an article of the category "Let's talk about Next-Gen. Future ideas for Linux Audio" where I elaborate(!) on realistic near future improvements or unrealistic science fiction scenarios. 


„Does this program import midi files?“ is a very common question. In fact it might be a FAQ for all sequencers, trackers and even wave editors(oh yes... you know that happens). 

Despite all its shortcomings (which will be described in this article in some detail) the midi format is the very devil to kill. It is still used as primitive but widespread exchange format between programs or as final format in the antique General Midi Standard. .mid in all its variants and purposes is still hip!

It would be wonderful to have a software library, open source license of course, which is capable of reading midi data and generate missing & more information to end up with a good universal file format which holds many information and is a perfect starting point to import the music data into an actual program, be it a standard piano roll sequencer or something more sophisticated, like a notation editor or a harmony/song generator from an existing melody.

These missing, but important, information are essential for the music itself and therefore for programs dealing with music. For example the question if a certain note is a G-sharp (gis) or A-flat (aes). On the piano both share the same key; in the midi protocol both share the same integer value. But in musical reality those are two different tones. This is true not only for non-equal tuning (like just intonation), where the g-sharp has a higher pitch (Hz value) than a-flat but also on a perfectly tuned synthetic instrument with equal temperament.  If a human player on such an instrument sees a G-sharp she or he will play it differently than an A-Flat. Maybe louder, maybe modify the tempo a bit to emphasis it… 

Point is: there is a meaningful difference in musical parameters that the midi protocol (and therefore software following it strictly) treats as the same thing. 

„Wait a minute“, you‘ll probably say, „there are many programs who do midi import. I have never encountered an A-flat where I expected a G-sharp“.   This would mean two things: You don‘t know many programs and the one you know were aware that this information may be retrieved by interpreting the context the note is in.  If you see the melody: „A e f# ? a“ you can bet that this is a g sharp, as leading note to the final a. 

If a human does this process by ear, listening to music and then writing it down as notation of any kind, this is called transcription. And this is what we want to simulate.

libTranscribe - Why do we want it?

A lib that is able to gain musical data indirectly is luckily a project of clear boundaries with simple programming interfaces: Data goes in, more data comes out.

Even without using it in another program, just as standalone command line program like imageMagicks convert, this is useful: transcribe in.mid out.musicXML .  
You can bet that even programs that already have both midi import and musicXML import will benefit from a dedicated converter. 

To what extent audio to midi conversion will be implemented into libTranscribe will be discovered during development and implementation. Right now it is clear that some information are already lost in the step audio to midi. If you convert audio to midi outside of libTranscribe, like through aubio, you maybe end up with a sub-optimal starting point. But the question is of what kind these losses are. Maybe exactly this data turns out to be generated most easily and most accurately anyway and we never had a real problem in the first place.  So for now, we just assume that we already have a midi file, no matter where it came from.

A bonus effect: Even if there never existed a midi and you did everything by hand this lib can be used as „spell checking“ or even a test if you really wrote a piece which sounds like a Mozart minuet, like you intended.

Vast Encoded Musical Knowledge - Crowdsourcing FTW!

Such a project obviously needs musical knowledge and experience of many kinds. 80s New Wave is different from Mozart. 80s New Wave is even different from the German „Neue Deutsche Welle“ from the same time!   And young Mozart is different from ‚old‘ Mozart (not very old though).

So it makes sense to create a modular libTranscribe system where many people and A.Is can work on their special field without getting in each others way. Obviously not all musical styles have to on the same level of implementation, be it that a music style is very hard to describe (Wagner harmony and pitches may be really hard to do, Palestrina will be a piece of cake) or just that nobody did the work yet.

Background information: Why is midi import mostly bad and you end up doing it by hand and ear in the end anyway.

So.. why do we need a shared library for that task? After all each program does its midi export without one as well and that works just fine.

Midi import and export are not synchronous tasks.

If you want to generate a midi file from relatively complete data, like music xml (which sucks huge time itself! see explanation below) all you have to do is to „forget“ certain data and get inaccurate. You don‘t need times signatures, key signatures and other musical meta-data. You don‘t need to know if a note is a staccato quarter note or a eighth note followed by a rest because now you are not dealing with rhythm anymore but with duration in absolute seconds.

Now imagine to convert the same file back to musicXML. What is the time signature? 3/4 or 6/8? You have to make an educated guess now.

Is this a general problem or specific to a computer?

It is exactly the same for a human. Writing logically correct music from insufficient data takes training and can never be 100%.  It is what we do as humans when listening to music. It may take a while to find out if a piece is in 2/4 or 4/4. You must wait for the right moment when rhythm and melody leaves no doubt so that you can reverse engineer the meter.

This is not about „ear training“. Identifying pitches and rhythm by ear is not a useful thing, even if countless people and programs try to sell that to you.  If you reached the master level in an ear training software  or university course you just learned the basics for the real tasks. The craft for the art. Only combined with knowledge about music theory and music history you can really use this skill.

Because now you need to add semantic and logical information, based on those basic parameters like pitch, rhythm and dynamics. And the context switches for every piece. Even within a piece of music. 

State of the Art

There are many questions and problems that need to be solved. The more knowledge goes into such a library the better will be the results of a low information density format like midi to a high density format (which is not musicXml, again, see the end of this article).

A music listening A.I. with expert knowledge in all musical styles and genres may be a few decades or centuries away but in the mean time we can work at least step by step to improve the situation. Keeping it simple in the beginning.  Every step should make at least midi import easier right now already.

Of course: Don‘t forget the human part. We don‘t need the all knowing program, at least not yet. If you know already if a piece of music is from the 16th century Italy, 18th century Vienna or 20th century Hollywood: Very good, just input this as precondition to the transcription.

If you see this in relation to where we are now (to my knowledge) even something as deciding if a chord is C-Eb-G or C-D#-G is an improvement. (the answer is not 100% C-Eb-G. This can not be solved with a look-up table. D# is the leading note to E which is the major third of a C Major chord. Leading notes into thirds are not uncommon). 

Now you know...

By now it should be a bit easier to understand why many people give the advice „Just write it down by hand, don‘t convert midi data“ if you want something like notation in the end. You simply can‘t trust the current midi conversion methods. 

So, even more basic than the example above, a library that would give you a list of the places where it was uncertain would be a step in the right direction.

Current midi importers suck also because it is too much work and unviable for the developers. You don‘t need it for the really serious work, like composing new pieces or creating high quality notation editions on PDF or paper. Data entry is the smallest problem in both of these examples and it really doesn‘t matter if it takes a a few days more if you have to input the data by hand instead of importing midi. 

An open source approach can help here by dividing the work and multiplying the usefulness if used by more than one program.

Let‘s do it!

Supplement: MusicXML

MusicXML is not a good. And I mean that aside from the fact that it is XML. Many people would already disregard a file format as bad simply because they consider XML itself bad-
Many aspects (playback fine control) that midi CAN do are lost in mxml.  I chose mxml as an example throughout the article because it is widely known through the propaganda of it beeing a universal notation exchange format. So we really don‘t want convert midi to mxml, that would be putting out a fire with gasoline.
We want the format that has midi as well as mxml as subset. 

Round 2: Meta Applications and „Out-Of-The-Box“ bundles

It does not have to be perfect, it just needs to be good enough. -- 4/9/2014

Last week I wrote about a near-future scenario where the idiom of Linux Audio modularity is taken to the next level. The biggest problem was to hide certain connections from the user.

After a week of research and talking to experienced JACK developers this is my current knowledge about the topic:

  1. Netjack and similar tools are not the right solution. It may considered just a lack of feature that some of them do not forward MIDI and Transport. But the real issue is that this is meant to run one server on one computer and we need one server for each bundle. This just shows that this solution would have ended in a hack with virtual IP addresses, temporary Linux user accounts and other abominations. There are doors we don‘t use :)
  2. I began to write a client that, without any networking, connected to two jack servers and then copied data from one server to another. This however turned out not to be a very solid and future proof solution either. Introducing latency etc.
  3. From that train of thought it was suggested by a knowledgeable person in #lad@freenode (I did not ask him for a quote so no name yet, sorry) that a client could be just a normal jack client on one side (the ‚bundle‘ sides way to receive the finalized audio stream for example) and a jack driver (like dummy, net or alsa) on the main jack servers side. This sounds like a clean solution, but needs a new jack release at least. Maybe not that unrealistic, but somebody needs to do this. Feel free to contact me if you want to be a part in a glorious future! (by writing this driver/client).
  4. There is Jack Meta data which is able to hide connections. This implementation requires no extra jack server (which is good) but needs more work on the client sides. Jack connection managers like QJackCtl and Catia need to follow the meta data. Since we would inject the „hidden“ property not from within a jack client like ZynAddSubFx but from our own bundle-manager we could switch on and off this hidden property so that updates and editions can be made. Since we already know which clients belong to which bundle there is no need to add a group tag to the meta data. So at least the jack control programs don‘t have to to know anything about that.

The last solution might have some (unknown) problems of its own and is not the one that comes closest to an „virtual machine“ idiom so it may be a bit flaky when connections show up in the wrong places or you will use a way to store jack connections that grabs the hidden connections as well and messes up your session.

But it is also the most realistic. Not perfect, but good enough. And this is all we need.