MIDI Happenings

Dave "MIDI" Robillard writes: Hi all. Thought I’d make a little post on MIDI stuff so things appear alive to you weirdos who aren’t on IRC 24 hours a day. Just some random not-very-prepared screenshots:

An older shot showing multi-line controllers, and the editor controllers: Editor controls. On MIDI controller tracks (CC) the bar controllers can be used to record/touch, or twiddled in realtime to control MIDI apps/gear.

MIDI import was introduced yesterday (Importing MIDI is done with the same dialog as audio, though it doesn’t look appropriate yet..). Here’s some Mozart imported into Ardour from a (single, multi-track) Standard MIDI File: Mozart Import.

Other new stuff is correct handling of MIDI streams/files with several channels, ability to create controller tracks for a specific channel, fixed the infamous “all region notes stuck at random times” bug, and several other crash bugs. The import shots above also show the newer version of the ClearLooks GTK engine used, with a ’gloss’ effect (just because). It’s not designed or coloured well at all though - if anyone out there wants to make a pretty colour theme for 3.0 we’re taking applications :)

Next up: more bug fixes, MIDI export, implement remaining MIDI features (so passing MIDI through Ardour is completely lossless), then MIDI effect plugins (and possibly instrument plugins).

What about Staff Notation?

What about Staff Notation? Using Lilypond or similar for lines with noteheads instead of piano roll. What linux lacks is an note editor which is capable of mixing midi/audio and left to right writing while seeing all staves at once instead of just Paper-like sites which are only because of "reality" where it is not possible to write endless. But in fact that is how music works and musicians think: from left to right without page- or linebreaks.

So in short: Lines with traditionall noteheads instead of piano roll?
like this.. http://www.pcrevue.sk/buxus_dev/images/2005/sw0705_SW_Shareware_noteworth_b.jpg

Hi Dave, is it planned to

Hi Dave,

is it planned to bundle a MIDI play engine with Ardour so that a user could effortlessly play MIDI as opposed to setting up Timidity which can be cumbersome, doesn't always work, and lacks a graphical way to load soundfonts?

Looks great! I can’t wait

Looks great! I can't wait to play with it.


Hooray! Hooray! Hooray! Any

Hooray! Hooray! Hooray!

Any word on an alpha release or some kind of roadmap? I'd really like to test the midi functionality, but if the code and features are still moving targets, testing it would be quite pointless...

No. Ardour will record &

No. Ardour will record & playback MIDI, enable editing of MIDI data, and will host instrument plugins, but we're not going to bundle a sampler with it. This is not necessary in a world where the software is a command or mouse click away, and all connected via JACK.

Steele, if and when Lilypond


if and when Lilypond can render to a Cairo surface (cairo is a 2D drawing library), we will look forward to use lilypond for staff notation. Until then, we're not planning to spend even 1 second looking at notation support when Lilypond has already got it all.

Staff notation is not a

Staff notation is not a priority right now, and isn't likely to be any time soon, to be honest.

However: Lossless/robust MIDI import and export is a high priority, so you can use whatever tool you like to edit MIDI with a score editor, until Ardour has support.

Writing a score editor from scratch is a huge undertaking, and isn't something the Ardour team will ever do (bad design anyway). That said, there is a new score editor in town, NtEd, which uses the same graphics stuff as Ardour (Gtk/Cairo and friends). If the code there is easily reusable, score editing in Ardour may be feasible.

In short: maybe eventually, but definitely post 3.0.

Testing is far from

Testing is far from pointless! Please fill the tracker up with whatever you find, even if you think it's "obvious". Bugs in the tracker are bugs that are likely to be fixed. Bugs not in the tracker.... not so much.

Sooo I didn’t read the

Sooo I didn't read the whole thread before replying... What he said. :)

The ardour’s ability to

The ardour's ability to edit and record/playback midi data while playing/recording audio tracks, is the feature that, in my point of view, will make it the true pro linux DAW.

About staff notation, yes I too need it, but doing some import/export with Lilypound, I think, its not a major drawback.
I. ex, why not arrange a key-binding script that does both the jobs.

Multiple stave notation like

Multiple stave notation like what you are looking for can be done. I don't know if ardour does this, but I know rosegarden4 does. What I usually do, Is this:

RG4 for MIDI editing, Then I'll use a less memory intensive program like Seq24 to pipe the tracks into Ardour.

You could use RG4 to "bounce" the MIDI to wav, but then you could have latency issues with Hi resolution audio (I record at 96KHz) which RG4 seems to not be good for.

Hope that helps


Thanks for the tip! So, RG4

Thanks for the tip!
So, RG4 does multiple tracks midi editing/play/record in staff notation?

Piping with Seq24, ok, I understand.

About "bouncing" MIDI to wav, I'm not sure if I've understood..
I record some audio instruments [piano, wurlitzer, guitars, bass] at 192khz, and my midi instruments will be only some physical samplers, drum-machines, linuxsampler connected with jack, and maybe something like Hydrogen.
I will not use the RG "internal" provided instruments.

Will each track support

Will each track support multiple MIDI channels (instead of just one channel per track) ? I was impressed with Master Tracks Pro and other sequencers that did this in the later 1980s, it would be nice to see such support in Ardour3 in the 21st century.

ok, what i meant by

ok, what i meant by "bouncing" is this:
mute all the MIDI except the one you want to "bounce" and then recors it as a 192KHz wav and then export it (I usually just right click and choose "edit with default editor" which opens the wav in audacity. Then i save it into my ardour project folder and import it to ardour. I think there is a way to export each MIDI at the same time, but this would require more outputs from the midi controller. IE: In Qsynth, you would need to be able to increase your audio outs to accommodate 16 channels. (I can't do this lol cause my setup only allows me 1 stereo out that will work)

As for Hydrogen, I just export it as a wav file sice I mix the individual drums in hydrogen, so my drum tracks are a single file complete with the effects I want (But that is purely choice.)

I never use the rosegarden internals either except maybe the analog synth plugins, but i rarely use that.


no, I don’t believe that

no, I don't believe that it will. But you *can* have more than one track per MIDI channel. What happens when you use that is that RG will use the levels of one track for all tracks onthat channel.

What I usually do is increase Qsynth's amount of midi channels and then plug away. In Qsynth's setup under the midi tab, you can adjust how many channels it will accept. In RG Setup, you can choose which ones are connected to what. This will give me up to 256 channels of midi. Then i can use the Qsynth Channels dialogue to pop what ever sounfont I want in there.


DavePhillips: Each track can

DavePhillips: Each track can support multiple MIDI channels, but there's nothing on the GUI side and no specific plans yet, I think. This topic came up on IRC recently.

Good to know, thank you.

Good to know, thank you. Such a feature would be invaluable for many MIDI-based composers.

“Channels” in MIDI

"Channels" in MIDI aren't really channels at all, just a number in every event. So yes, you can have multi-channel data in a MIDI track currently (it requires effort not to do this, really). Operations to split (or merge) tracks by channel so you can edit them independently in separate tracks aren't there yet, but will be soon enough.

However: I'm not sure if there is a reasonable way to independently edit multiple channels in a single track though. Even just from the interface point of view, how would that work? The best I can think of is a selector on the track header to only show events of a certain channel (with an option to show all events of course). This is very feasible.

If that's not good enough, I'm not sure what else could be done that isn't just separate tracks. Examples/Screenshots?

(All that aside, keep in mind that with Jack MIDI, or any patchable port-based MIDI system (including Alsa Sequencer) channel really isn't as useful as it once was...)

Dave, there’s quite a few

Dave, there's quite a few examples in various programmes (most commercial i think) of editable multiple midi channels per track. The easiest (and this could well be just subjective on my part) is a drop list of midi channels and pick one. At this point, options diversify, with some programmes then showing only the selected channel, and others merely highlighting the selected channel for edit.
Personally, i'd opt every time for a 'highlighted' editable channel, because it would enable me to match up instrument articulations, i.e., 1st violins downbow=mcha1, 1st violins upbow=mcha2. Being able to see both, or as another example, complex chord structures across instrument assigned channels, would be extremely useful.

In addition, with shortcuts for each channel, either qwerty or cc based(midi channels able to be switched from a second midikbd, or a dedicated control surface.) a user would be able to dedicate a port per track, and edit various channels, articulations, etc. from within the inline editor, including, if possible, changing the midi channel of a note. So a user would play a line in for say strings, then go back and assign the right channel for each note to trigger a particular articulation. (Another mention for a great step forward, inline editing.) Matching string bow positions is a pain at the best of times, but in a multiple midi channel per track paradigm, much of that pain is allayed, with simple qwerty or midikbd keyswitched channel allocation per note. (violins downbow=mcha1, violins upbow=mcha2, etc..)

As for why we would want mutiple channels per track, and why not just 1 track=1 channel? Well, my full orchestra template runs to 300+ tracks if 1 channel=1 track. On top of that, there's the routing for all those tracks, and of course,a lot of scrolling. If i want to double the flute with the 1st violin in this scenario, there's a long way to travel down the canvas to get there, and that takes a considerable amount of time.

If all my 1st violin articulations can be put into 'port' tracks,each with 16 channels, then i would use about 4 tracks, instead of over 60.
Makes a big difference when doing film or orchestral work.

And i guess you could say, better to have this option than not. After all, if you want just 1 channel, you have it, and don't lose anything, and with the option, multiple channel per track users get to join in as well.

Here's a screenshot of just one way of doing this, in a midi editor. In the top left of the image, you'll see a drop down list of channels, including all. Each channel (including all) is key shortcut assignable, both in qwerty, and cc midi. (I have this setup to be switched from the black and whites on a second midikbd i use as a control surface.)



Alex: Some of the things you

Alex: Some of the things you are describing is already possible using "underlays". Any number of tracks can be used as backgrounds for an existing track. I agree it should be possible to have several channels in one track, highlighting the active channel so you don't have to have 16 independent ardour tracks to have 16 voices.

Dave: Implementation wise this could be done by filtering the active channel and showing it in the visible streamview, then create ghost regions of the inactive midi channels and then show them as underlay.

Interesting Audun. I

Interesting Audun. I haven't explored underlays as much just yet.
Your response brings a question.
If i were to employ 16 'underlays', how would i cycle quickly through them?
Because if the top layer was '16' channel capable, with the ability to assign specific mchas' to notes AFTER they'd been inputted, then one layer would seem to suffice?

Or do i have the wrong end of this somewhere? (Which may well be highly likely.)

I'm keen to reduce the number of tracks wherever possible., and if i have multiple articulations for one instrument or section, it would make sense to keep all the relavent work and input in one track, or a minimum number of tracks.


Alex: The idea isn’t

Alex: The idea isn't developed yet. What's possible now is you have e.g. midi track 1-5; disregarding channels, you can display midi track 2, 3, 4 and 5 under track 1, using the same vertical range, seeing voices on top of each other.

As shown here:
(Midi1 shows the contents of Midi2 (as well as some audio, the screenshot just demonstrates the underlay concept in general))

I haven't thought about much else outside that domain. Channels could be analogous to "voices", but it seems a bit limiting to only have 16 voices per track. I think a design goal of ardour is not to have fixed limits on anything, the only limit should be system memory.

Alex: The idea isn’t

Alex: The idea isn't developed yet. What's possible now is you have e.g. midi track 1-5; disregarding channels, you can display midi track 2, 3, 4 and 5 under track 1, using the same vertical range, seeing voices on top of each other.

As shown here:
(Midi1 shows the contents of Midi2 (as well as some audio, the screenshot just demonstrates the underlay concept in general))

I haven't thought about much else outside that domain. Channels could be analogous to "voices", but it seems a bit limiting to only have 16 voices per track. I think a design goal of ardour is not to have fixed limits on anything, the only limit should be system memory.

Aaah, now i understand what

Aaah, now i understand what you're saying Audun. So you'd create 16 tracks, one for each channel, then layer them in one track.

Hehe, I can't let this go without a further question. What happens to the other 15 tracks, you've removed or aliased regions from. Can they be hidden in any way? In other words, if i create 300+ midi tracks, and with layering multiple 'voices' (good analogy) i can get it down to 60 tracks (including busses), i can then hide the 'unused' tracks from view.
I gather from what you're saying, that the 'hidden' tracks are still needed for their ports and channel connections.

Wouldn't it be a lot easier to have multiple midi channels per tracks?


p.s. Thanks for chipping in.

Alex, of course it would be

Alex, of course it would be easier. It's not possible per se, but it certainly might be in the future.

What we're saying is this: As opposed to audio view, midi views are more easily stacked on top of each other, not just for vertical screen real estate saving, but also for musical purposes (seeing how "voices" relate to each other on the same axis). Then we're saying that each such voice doesn't have to come from a unique track, several independent voices can belong in the same track. One way to separate voices in the same track would be to use a different MIDI channel for each of them, but then you're limited to 16 voices per track. Possibly you'll want more than that, assuming that the voices are grouped together in the same track for _view_ purposes, not for the purpose of sending them through the same MIDI software-port (this shouldn't be necessary unless you absolutely need your software midi setup to behave exactly as your hardware setup, remember, software midi cables are cheap:)

Audio tracks can have multiple channels, but here we're talking about channels as JACK ports. In my opinion the way to go is to have each voice in a midi track have it's own MIDI port, effectively making the MIDI tracks "multichannel" in the sense that audio tracks are multichannel. That way you can connect plugins and ports independently for each voice (because they all have unique ports), and not be limited by 16 voices.

Ok, a dim bulb’s come on

Ok, a dim bulb's come on in the skull.

I'm definitely up for a non limited track voice count. And if i took this to the extreme, i could (in a momentary fit of genius/insanity pick one) have a layer for each violin articulation voice in a track. In a complex work with many articulations, i might use 40 or 50 of them. So, that many layers in a track poses an obvious question (and i'm not dismissing this paradigm by any stretch of imagination) that may, by nature of speedy workflow intent, crop up. How do i handle that many layers at speed? It's also fair to say, that within reason, i might use 5 or 6 layers in a bar. (legato down bow release, legato down bow non release, legato up bow release, legato up bow non release, etc...)How do i input quickly, then switch between layers quickly to match sample start finishes, add automation per layer, etc..
The idea of unlimited voices in a track is fantastic, imho, (and means i, as you rightly say, have more than 16 channel options per track), but from a practical workflow perspective, it might take some getting used to, to get it all married up smoothly.

But i also note that voices can be stacked in a track, and that begs the question of a couple more height parameters added, as i wrote previously. I can visualise about 5 or 6 layers stacked, and be able to line the notes up fairly quickly that way, if the track height was sufficient to get a clear visual of alignment, without peering at the screen to see tiny dots and blips.

I'm open to this as a potential working method, and think the paradigm, at least in theory, is....state of the art. Hats off to the team for some creative thinking outside the box. Truly a 21st Century idea!

So, more practically, how do i assign multiple ports to a track,and define specifically a particular port, and channel, from inside an ardour midi, multi voice, track? I have at least 4 ports worth of just 1st violins. At the moment, i would need to manually connect and disconnect each port, so the right channel (selected from my midi controller i guess) would be available at the right time, for the right layer?

Is it possible to consider, relavent to a drop down list of some sort in the track face, a choice of whatever's actually track connected ports? If the track could 'recognise' the connected ports, and automatically 'build' a list, at least it would remove having to go to jack manually. Click the port, click the channel, press record sort of stuff.

I think this perspective is intelligent, sharp, and open minded thinking, and I would be highly interested in trying it out, to see if it's practical in 'realtime.'


Onwards and upwards.

If I understand you

If I understand you correctly, you don't want the different articulations to be played back simultaneously, they are rather variations of one voice that you want to cycle through, listening to them and eventually finding the best one. The concept in ardour dedicated to this kind of thing are "playlists", analogous to takes. Each track has an active playlist and an unlimited number of inactive playlists, and tracks can even use playlists originating from other tracks.

(An obvious problem here is how do you keep inactive playlists/articulatory variations up to date when working on a specific instance of them?)

To further elaborate on the multichannel audio/multichannel midi (voice) relationship: Multichannel audio is bound to regions, every region in an n-channeled audio track ideally has n channels (not necessarily true in the MIDI domain, but leave this for later). If we're going to design something like this, the multichannel analogy between track types should be fairly consistent. This would imply that an n-channeled MIDI track contains n-channeled MIDI regions. A problem arises when you want to control different voice instances (voice playlists). Playlists (currently) work on the top level of tracks, and cannot control the individual channels of a multichannel audio track, only the multichannel regions themselves. This may result in not having a multi-voice MIDI track being the same as a multichannel audio track after all.

The way to do it could be track grouping, or composite tracks. That is, each voice is a standalone midi route at the low level, but shares view axis with several different other tracks, making up the "voices" of that track. Operations and settings for such a track may (or may not) apply to all voices. This way you'll get one independent playlist and one MIDI port (routable to anywhere you like) for each voice. Voices could also be regroupable (move voice A from track 1 into track 2...) making it very versatile.

This is just quick brainstorming, and I don't expect the core developers to agree with me, or that I even agree with myself tomorrow:)

Maybe a simpler solution is

Maybe a simpler solution is to make each midi region capable of 16 channel input from one port as default, and let layers take care of the rest. As you've written, each playlist can accept regions from anywhere else (within reason) within the confines of n-track/n-channel setup.
You're right, it's brainstorming, and not a bad thing at a that.


Thanks, Dave. I understand

Thanks, Dave. I understand the channels clarification, and I hope a reasonable solution can be reached for Ardour. Re: the editing: IIRC Master Tracks had a popup menu for editing an individual note, but I'll check that and report back to you. I'll try to get some screenshots together too (MT Pro runs in Xsteem).

The selector you suggest sounds perfect from the users POV. Perhaps it would be possible to show only notes on selected MIDI channels (e.g. only notes recorded on channels 4,7, and 11) ?

I've been wondering how JACK MIDI will impact future sequencer designs. Alas, my understanding is still dim, and I've only used it for checking out the AZR3 LV2 plugin (which worked perfectly). So much to get into, too little time. :(

from a quick reading, i’d

from a quick reading, i'd say we have a new concept to manage: the "voice".

default mapping: 1 channel-> 1 voice -> 1 (virtual) MIDI port
possible other mappings: you decide

this would workaround the 16 channel limit, and let a user do creative things variably mapping 3 voices to the same port and then breaking them apart again.

this would mean storing a note's "voice" info in addition to "channel" info, even though in 90+% of cases voice == channel. delivery logic would then look up the port in a voice<=>port map, and dump the note event data to the correct port.