You are here

qmidiarp not working in Track/Export Tracks/Audio... (bug?)

I'm using qmidiarp as a LV2 plugin in a song on some tracks and it all works fine when composing and arranging, but when I try to export the song to a wave file with Track/Export Tracks/Audio I can hear the other tracks, but nothing from the tracks using qmidiarp. I think this is a bug, but I am unable to make a ticket in qtractor so I'm reporting it here.

Another observation is that qmidiarp is missing the first note if I start playing from the first beat in the first bar. It is easy to work around by leaving the first bar empty so playback starts before encountering the first note. Perhaps these problems are related?

rncbc's picture

re. qmidiarp not working on export audio:
- what instrument plugin is inserted right after qmidiarp and fed with its MIDI output?

re. qmidiarp missing first note on first bar, firstbeat:
- yes and no, it possibly relates to qmidiarp's own implementation and a off-by-one reading of LV2 time/position; or maybe it can be qtractor's fault to not serving this information on the very first absolute zero-time frame cycle? i shall investigate this later but one thing is for sure, this is not related in any way to the other export issue.

thanks && cheers

I'm attaching a screenshot which shows plugins and configuration. The "bass" track is using qmidiarp and yoshimi. The midi track is just playing long base notes that are modified by qmidiarp.

re missing first note: I understand that it could be a qmidiarp problem as well. qmidiarp is built from source (trunk) about one week ago, so it is the latest copy. I am using qtractor 0.8.1 from kxstudio on Ubuntu 17.04.

rncbc's picture

I realy think that you should address your concerns to qmidiarp developers (Frank Kober? he used to be strolling around here back then :))

on the tests I've been dealing shortly, with latest git head (--enable-qt5, btw.) Arp LV2 at least, often crashes randomly and yes, it doesn't seem to play well on export rendering (jack freewheel mode, faster than real-time) and also, the first note on playback or loop start, regardless of its location in the timeline, is simply ignored--all that to just confirm all of your findings.

note that i am not dissing a bug on qtractor, no way! i'm all full-ticking and willing to help, you and possibly qmidiarp devs.

cheers && thanks again.

Thanks for checking and confirming the problem. I will contact qmidiarp and refer back to this conversation, and I hope they can work something out. In the meantime I'll try to find some other way to dub the tracks down to wave files.

I've just started experimenting with Qtractor. I was using Ardour, but Qtractor feels more suited to my method of composing.

I'm having the same issue with Qmidiarp- my workflow primarily uses Qmidiarp and Zynaddsubfx- and I can't seem to get an export with Qmidiarp enabled. I can mixdown/bounce tracks in real time, but the export function just doesn't want to happen.

rncbc's picture

while this comment quietly doesn't dismiss a deep hidden bug in qtractor, it is rather interesting still that once you deactivate qmidiarp lv2 plugin--ie. turn off the lil'green fake-LED:)--track export (> Audio) just goes normally (and sonically) as it should.

otherwise, I have experienced all these dang crashes quite often and just about when it's all supposed to complete... and still, the resulting exported audio file is there stored as uh,... silence? well, it is in fact not much different from what's played back in normal real time anyway, but that's maybe just me o.O

on the other news, qmidiarp git tree hasn't seen any updates ever since OP. Frank? are you still there?


[UPDATE:] In case you wish to mention to the qmidiarp devs, i have found that when the plugin's "Sync to host" setting is not in effect, it all seems to work fine: Track > Export Tracks > Audio... file is exported alright and no crashes.

Thanks for the quick reply- got sidetracked myself for a bit.

It does look like things are stalled a bit over on QMidiArp right now, Frank was active earlier in the year, but doesn't seem to be responding lately- life gets in the way I guess. Hopefully things will get rolling again at some point.

I can confirm what you've said, when exporting, turning the plugin off allows the midi to pass through and play the source chords, but uneffected- no arpeggiator.

Turning off "Sync to host" does indeed allow the effected midi through, playing the notes instead of the chords, but it's all out of sync. :-(

At this point, I do have a work around- render the arpeggiated track(s) in real time, then mix them out- not ideal, but it gets me where I want to go.

Here's an example of what i'm doing-

Hi Wayne and Rui,
I really apologize for my recent (and less recent) slowness with qmidiarp, didn't have much time lately as you both figured...Anyway thanks for insisting with patience. The problem seems to be related to the transport not syncing correctly in the non-realtime situation (which it was never made for initially). But it maybe also because calculation of the arpeggiation is not done within one single jack period (which is also the reason it fails to play the first note when the input data is simultaneous with transport start). Also when jack transport (host sync) is used, timing is taken from transport (lv2 atoms), and it is sensitive to running or stopped transport info there. So if qtractor provides that also during freewheel mode (which I don't know much about after all) then I need to check for (small or large) errors in the "host timing to frame" calculation. Any help is more than welcome of course, can we exchange by email, Rui? I'm also interested in the crashes you see both of course.

All the best

Not sure if this is helpful or not, but when I was using Ardour, the non-realtime rendering works with QMidiArp while remaining synced.

rncbc's picture

hi Frank,

it's great to have you back.

as a matter of fact, qtractor was sending lv2 transport position during export/freewheeling mode, all the time, all the way, ever since...
however, it wasn't setting the transport speed to 1 until now... (today's commit v0.8.4.53git.104c8f)

maybe this will help things go a little further...

cheers && thanks

Up until now I've been using the KXStudio version of Qtractor. So, I just grabbed the git version, installed the libraries needed for configure not to throw up errors, and got it to make (I also needed libqt5x11extras5-dev for make to complete), now I've got a shiny new Qtractor! As a side note, I'm using Ubuntu Studio 16.04 with many repos added.

The audio track export (non-realtime) works with QMidiArp now- but, it seems like the phasing of the QMA program is different, at least that's what I think I'm hearing (as a side note there is another issue I'm having- I can't record the midi output of QMA- I can give more details on what I've tried- Rui, should I start a new thread for that or do a new post in this one?).

To illustrate, here's one of the sections rendered out in realtime-

Versus exported in non-realtime- ).

Here's the QMA pattern-
PAsting it in the forum can cause issue- the angle brackets don't play nice in the html ;-)

And the midi file of the chord progression-

The folder all that is in is a dump of the working directory-

I'm just thrilled to be making progress!

rncbc's picture

... it seems like the phasing of the QMA program is different
what you mean by phasing in this context? is it that generated events are out of phase or delayed, out of time? i guess the ball is now on Frank's side :)

...I can't record the midi output of QMA
that's actually expected: MIDI produced by plugins are not routed anywhere but in through the plugin chain they're in, so you can't record it; but there's a hack you can do: insert a MIDI Aux-Send after qmidiarp and fork its output into some other MIDI output bus and then bounce/record from its output ports--tricky, but doable ;)


Yep, ball on my side received ;) I suspect this is related to the missed first note when timings of incoming and (to be) outgoing notes are exactly equal. We'll discuss that in qmidiarp bug over at sf. Thanks much Rui anyway!

Yes, I tried using the MIDI Send- going by the earlier method of capturing the audio from the synth plugins- being sure to connect things up in the connections dialogue, but no go. I tried every way I could see of hooking things up. Not sure what the "Dedicated MIDI player outputs" are in the Options > MIDI section, but I enabled it and connected it as well, but still nothing recording.

I started using GMIDImonitor to see if I could tap into things- I can see the QMA output, but it's not being recorded. Here's a screenshot-

I have it sent to a new midi track as well as GMIDImonitor- the QMA notes appear in the monitor, but aren't recorded to the track.

The working folder for the project is here-

rncbc's picture

hi all, who's still here :)

after some hair-pulling and ghost-hunting, it finally come to my attention that regular JACK transport/position is NOT being updated when in freewheeling mode.

so that the host time/position information that is fed to LV2 plugins only happens when export starts and ends, passing the same and current play-head position which is not, almost never, the correct one at all.

this has been corrected on git head today (>= so I pledge your patience to test it all over again.

thanks in advance.

Okay, gave it a try, but now I'm not getting any sound from my MIDI tracks- tried starting a new project, new MIDI track, add an instrument (mda piano), import a MIDI file- no playback, adding an audio insert doesn't help, mixdown/export produces a blank audio file. When I uninstall and install the previous version (, load the file I just created, and all is good again.

The new ( version has this error popping up after I add the audio send-
jack_port_get_all_connections called with an incorrect port 0

Here's an example of that process-

With the earlier version (, things were starting to work with the new QMidiArp- Frank did some updates that has improved things.

rncbc's picture

sorry, there's a regression on today's that should fix it!

thanks for the heads-up!

ps. next time you share a qtractor session you can bundle it on one single archive/zip file by just saving as with the ".qtz" suffix ;)
pps. you also should know that audio export does not handle dedicated output ports, right? audio export only applies to regular audio output buses.

Cool, it's back again- thanks :-)

"you can bundle it on one single archive/zip file by just saving as with the ".qtz" suffix"

I figure there was a way to do that- so obvious- d'oh! Thanks for the heads up, will make transferring projects so much more sane!

Not sure what's meant by "dedicated output port"- I only got the error with the version- it's gone now in

Figured out what I was doing wrong- the midi channel is incremented with each new track, I did not notice this, so now I can capture the midi output of QMidiArp, in realtime at least.

Add new comment