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


Add new comment