qmidiarp LV2 plugin missing the first note
Linux MIDI arpeggiator, phrase generator and controller LFO
Status: Alpha
Brought to you by:
emuse
Menu
▾
▴
#21 qmidiarp LV2 plugin missing the first note
I'm using qmidiarp as a LV2 plugin in Qtractor and the first note on playback or loop start, regardless of its location in the timeline, is simply ignored. qmidiarp is built from git trunk about one week ago (using --enable-qt5) and qtractor is version 0.8.1 from kxstudio on Ubuntu 17.04).
More discussion here : http://www.rncbc.org/drupal/node/1823
Gen AI apps are built with MongoDB Atlas
Atlas offers built-in vector search and global availability across 125+ regions. Start building AI apps faster, all in one place.
Hi,
does this happen with all modules or only with the arp ?
Thanks again
Frank
It seems like this only happens with the arp. Seq doesn't have this issue, haven't been able to validate LFO.
Hi Wayne,
read your report on qtractor's forum. I'm not sure if I understand right, but I think this is related to a conceptional problem with qmidiarp, and it is also the reason why it misses the very first note in a sequence in qtractor. When it runs in normal (i.e. non triggered) mode it will ensure that outgoing notes are sent exactly at the time they should according to the running transport band. If an incoming note occurs exactly at that time (and that is what happens when your notes are quantized in qtractor) it may not process it to output for that time point, but only at the next step. Now it may for some reason still take these notes up when playing in normal speed, but miss them when processed quickly, which may explain the shift between real time play and audio export. This is not satisfying (I'm a bit surprised to see a difference between real time and audio export) and I will see whether this could be changed, but it would require a big rework.
For the time being you have two options, either you place your sequenced notes slightly before a full beat (or whatever grid you use in the arp) OR you use the triggered mode in qmidiarp, that will set the timing to that of the received notes each time it receives a new note. Could you try either of these and tell me whether they work?
Best
Frank
PS: We can continue discussion on this bug, I think it's related. And I'll close the other (export) bug since that works now.
Thank you for explaining- it seems like there's notes being missed rather than it being a phasing issue as I had thought- I couldn't quite tell what was happening, just that there was a difference between the realtime and non-realtime.
I suspected QMA had a different approach somehow, which may be causing some glitches, but it's also what draws me to it- it's a bit unpredictable, so it's always surprising me- the trick is to capture the happy accidents while avoiding train wrecks. ;-)
I will do some experimenting with triggered mode and get back to you on what I find.
Got a chance to test the trigger mode- yes it exports out in non-realtime in exactly the same way as it plays back in realtime- yay!
That's cool, I can use trigger mode, setting up my chord sequences accordingly.
I think I fixed the missed first note bug. Unlike the standalone app, I had the LV2 plugin do a reset of the input note buffer when it received transport start. This is now done on transport stop as it should. But the "dephasing" problem persists, the note order (within a chord it should be lowest first) on the first chunk isn't respected and I'll have to find out why. This is also true for the standalone app.
Yes, the first note works now! Right on!
There is a difference between the realtime and non-realtime, not nearly as much as before though. Not sure what exactly is different (dephasing or note dropping), I'm hoping Rui will be able to get the MIDI capture working, it will be easier to see what exactly is going on.
Thanks so much for your work on this.
Grabbed the latest git version to try today- feels more stable somehow, nice!
Just wanted to update/clarify where this bug is for me- the first note is playing the first time it's played and exports (nonrealtime) without issue, but it misses the first note when Qtractor loops. So, while the bug isn't totally squashed, it's feeling the squeeze.
It still misses notes on export when Trigger is disabled- it feels like there's a pattern to the notes it's missing, but I can't quite make out what it is- might be faces in clouds. ;-)
Again, thanks for what you've accomplished so far.
Wayne,
After a lot of testing and some changes I'm afraid the situation won't change. I think there may be a difference in Qtractor's timing between transport start and the notes depending on whether it is playing realtime or export, and maybe qmidiarp shouldn't be sensitive to that, but it is. The 'missing first note' should, however, now be fixed in realtime play including looping. I'll leave the bug open, maybe things get clearer later.
Hi Frank, thanks for the update.
I think this bug, as opened by yena, is fixed. The latest version plays the first note, including on loop- yay!
I came across a new wrinkle with the "missing notes" issue I'm having- I managed to capture the midi output from the plugin- the notes are there, but they are played at a velocity of 1 out of 100- too quiet to be heard- so they are there. Here's a file to illustrate- http://sketchbin.webmadman.net/2017/QtractorQMAdev/miditest.4.qtz
So that would seem to be a different issue. Could close this bug and open a new one or just continue on with this one- up to you really, but there's defintie progress.
Hi Wayne, you actually found a new bug !
It hasn't anything to do with this one, but thank you for the nice analysis that helped me solving it. The vel 1 notes should actually just not be there, this was an annoying regression. Should be fixed in the last commit I just did.