#9 Midi latency

[brian]

Hi and compliments for your wonderful application! Nice!

I have however been encountering a significany lag when using the arpeggiator, in terms of lag-time between note-on and when the sound of the note is heard. It would seem that when the amplitude envelope release is activated, then the decaying note prevents new notes from being heard right away.
It would be great if this could be resolved! I'm happy to do testing if needed.

Sincerely,

brian

[Frank]

Hi Brian,

thanks for your report, I'll look into it soon, in particular the envelope problem you report is interesting. Just to be sure: are you using the arp with keyboard trigger mode? Otherwise it's normal you're getting delays, since it acts as a running sequencer

[brian]

Hi Frank,
thanks for your help! Yes, I am using key trigger mode. I initially thought it was my system that was set up incorrectly, but I think the issue is in the midi processing, somewhere.
Let me know if I can help in testing or whatever. It's a great application, and really the best standalone arpeggiator in linux that I have found.
Thanks!

brian

[Frank]

Hm I just played around a bit and realize that when release envelope is set, the release notes are handled as if they are still pressed on the keyboard. So if you use the legato trigger mode the arp should get retriggered again at each new note. Is there a reason why you cannot use the legato mode? In that case I'd have to change things a bit.
The trigger mode latency without envelope is fairly low though (at least that's what I hear here) or did you find a problem with that, too?

Thanks!
Frank

[Frank]

Hi Brian,
OK finally got the time to look into it more closely checking the code. What I said in my last reply should not be accurate, at least in the latest git version. Re-triggering should occur also when there are still release notes in the buffer. And testing again this seems to work.
Which qmidiarp version are you using? Could you attach an example qmax file that exposes the problem, and could you re-check with the latest git version?

Thanks again and sorry for the confusion
Frank

[brian]

Hi Frank,
no problem, no confusion! I just finished a longer post and had to re-login and it got lost. Oh well..

Anyway, I think the problem perhaps isn't the midi delay (fortunately!). The problem is that the arpeggiator only allows one arpeggation at a time. The problem with this is that chords/multiple notes cannot be played fluidly (I'm speaking of when the envelope release setting is not at 0). It would be good to have the arpeggiator be able to arpeggiate each note independently, and each note arpeggiation decay independently as well, rather than each note-on cutting off the previous signal. Make any sense?

I'm using version 0.5.2 (KXStudio repos). Should I be using a git version instead? If I should, where should I download it? Will it replace or conflict with my current version?

Thanks!

brian

[Frank]

Ticket moved from /p/qmidiarp/bugs/10/

[Frank]

OK I got it now. Unfortunately by design this doesn't seem possible for me. The only thing I could do is to maintain the notes in the release buffer even after a new trigger event so that they don't get cut off. But they would inevitably still get re-sync'ed to the latest stroke note. This arp uses a common rail for arpeggiation, which is not uncommon. The reason is that for creating the arpeggio, all notes in the input buffer (i.e. those currently played AND those in the release buffer) are used to determine the output pattern. Imagine a "0" pattern, then the arp must decide what to do with say 4 notes in the buffer, and it will use all of them to create and ascending pattern. If these notes were stroke later there is no way to know they do not belong to the "previous" note group.
I'll keep your ticket in the feature requests though, maybe one day I'll have an idea. Maybe another arp you know does handle this type of thing?
Thanks for the idea anyway
Frank