#7 Behaviour of arpeggiator keyboard trigger mode is confusing

0.6.1
closed-fixed
Frank
None
5
2014-06-29
2013-09-16
Burkhard Ritter
No

In the arpeggiator module, I find the keyboard trigger mode confusing and its behaviour not as I would expect. Hence, either my expectation is wrong or its behaviour is not optimal.

For example, for a simple arp pattern "0" with "Up" selected, pressing the keys C and E results in the sequence "C C E C E ..." being played, whereas I would expect "C E C E C E ...". Similarily, with a pattern like "012" and "Static" selected, for pressing the keys "C E G" most of the time I get "C E G C E G ..." as expected, but sometimes I trigger the pattern starting with "E G ...". It looks to me (but I might be wrong), that as I am pressing a chord and in doing so pressing one key ever so slightly earlier than the others, QMidiArp immediately starts arpeggiating the (at this time) incomplete chord. Ideally, it would wait a couple of milliseconds and start arpeggiating the whole chord I am pressing.

This is with QMidiArp 0.5.2 on Ubuntu 13.04. I am using the internal time source for this (i.e. not Jack Transport). My aim is to use QMidiArp together with SooperLooper, where I set the same tempo in both applications and then trigger recording in SooperLooper just by starting playing.

Discussion

  • Frank
    Frank
    2013-09-17

    • status: unread --> wont-fix
    • assigned_to: Frank
     
  • Frank
    Frank
    2013-09-17

    Hi Burkhard,
    what you are describing very precisely here is related to the trigger mode. It is somewhat inevitable in the current way QMidiArp works. The trigger mode is designed to respond the earliest possible, with minimum 'latency' to a note stroke, so it will immediately output a note even when you press a chord with a small delay between the single notes. One way to 'avoid' this would be the legato trigger mode, but that one will re-emit all previous notes in the chord as well upon every new stroke.
    You suggest that ideally QMidiArp would wait a bit until the other notes come in, but this is against shortest latency, which I don't want to compromise. So what about having another trigger mode called 'delayed trigger' or similar? That one could wait a fixed amount of time to give the keyboarder a chance to form the entire chord within say 30ms?

    Regards
    Frank

     
  • Frank
    Frank
    2013-09-17

    • status: wont-fix --> accepted
     
  • Hi Frank,

    a delayed trigger mode would certainly work. I wouldn't be suprised if the delay required is actually very small (maybe 10ms or even 5ms is already enough?), but that's just guesswork from my side. I think I tried the legato trigger mode and saw the same behaviour as with the normal trigger mode (in that the first note of the chord gets sequenced twice), but I am not sure if I remember correctly and have to experiment more with it.

    Out of curiosity, how does QMidiArp determine whether notes are coming in simultaneously? If I input three notes at exactly the same time (I am tempted to try this with a Sequencer later today or this week), will they be considered as one chord or will QMidiArp start sequencing the arp pattern immediately when it has only received the first of the three notes?

    The goal of minimum latency makes perfect sense, of course. However, to be honest, I am not sure what the use case of the current keyboard trigger mode is. Unless I have a arp pattern that's only used with one input note, or the sequence is built up by slowly pressing more and more keys on the keyboard. That being said, a delayed trigger mode would certainly solve my problem.

    Cheers,
    Burkhard

     
  • Frank
    Frank
    2013-09-21

    Hi there,
    sorry for the late answer.
    What the trigger mode currently does. When a note comes in through the engine, it is first added to the arpeggio buffer, and a "got trig" flag is set that causes a resync of the arpeggiator loop to the timing of that note plus a small delay (2 ticks). When the driver reaches this timing, notes processed according to the arp settings are put into a queue and should be sent to the output during the same jack period or with 'zero' delay when alsa is used. This is, also in the jack case, no "hard realtime' between input and output notes anyway, and I have to check whether it would make sense to simply increase this 2 ticks delay.
    But I realize there seem to be some additional hicks regarding the order across multiple notes on the keyboard. Will test more and keep you posted, but it may take some time, which I don't have right now.
    Still planning to write a sequencer?

    Cheers
    Frank

     
  • Hi Frank,

    thanks for your explanation. If I understand you correctly, all notes that are received within two ticks should be sequenced together according to the current arp pattern. How many ticks are there per beat?

    I did some very quick and not necessarily conclusive tests, with harmomySEQ (an alsa sequencer) sending midi to qmidiarp (with Jack, and a2j in-between both applications). With a simple arp pattern "0" and "Up" mode and keybord trigger, four notes sequenced at the same time in harmonySEQ (i.e. a chord) still results in the behaviour described in my original bug report above, i.e. the first note gets sequenced twice, e.g. "0 0 1 2 3". With the same settings, but no pause between the chords, QMidiArp plays the arp sequence as above plus the whole chord by itself. So it looks like there are some more quirks and also, it does not seem to depend on how much time is between the input notes / keys (assuming that the notes coming from harmomySEQ are virtually same-time).

    I was working on Jack midi support for harmomySEQ. It's far from complete and still lots of work to do (it also turned out to be much more work than I ever had anticipated) and unfortunately I haven't been able to spend much time on it more recently. Still, I am hopeful that I can complete that work, before the end of the year.

    Cheers,
    Burkhard

     
  • Frank
    Frank
    2013-10-22

    • status: accepted --> open-fixed
     
  • Frank
    Frank
    2013-10-22

    Hi Burkhard,

    I think I fixed the problem you reported. There was indeed no chance to get chords correctly sorted before the first triggered note came out, since the first note in the queue produced a direct output. There is now a ~5-10ms delay (depending on tempo...) for pressing the next note in a chord so that it is possible to play the triggered mode as expected (I think). Would you require a longer delay as a keyboarder? This might become part of the settings then.

    Thanks for having insisted on this

    Cheers
    Frank

     
  • Hi Frank,

    thanks so much, that's fabulous news! I haven't had too much time to play around with it yet, but I quickly tried it out and the trigger mode seems to work as expected! Regarding the delay, I get the chords right most of time, but not always; that's probably a question of practising a bit; I am not sure whether the trigger delay should be configurable. I am not a keyboarder, though, so it might be worthwhile asking somebody who actually knows how to play those keys properly. ;)

    However, it seems that in some cases the note-offs are sent out of order. For example, with the pattern "ddd01" I get the following output in Ardour's Midi Tracer (Channel 1 is directly from the keyboard, Channel 2 is from QMidiArp):

    00:10:13.394661          NoteOn chn  1 60  67 
    00:10:13.394760          NoteOn chn  1 64  74 
    00:10:13.416823          NoteOn chn  2 60  53 
    00:10:14.002859          NoteOn chn  2 64  59 
    00:10:14.600816          NoteOn chn  2 60  53 
    00:10:15.197774          NoteOn chn  2 64  59 
    00:10:15.794894          NoteOn chn  2 60  0  
    00:10:15.794997          NoteOn chn  2 60  53 
    00:10:16.146906         NoteOff chn  1 64  64 
    00:10:16.147008         NoteOff chn  1 60  64 
    00:10:16.392881          NoteOn chn  2 64  0  
    00:10:16.989862          NoteOn chn  2 60  0  
    00:10:17.597756          NoteOn chn  2 64  0  
    00:10:18.194846          NoteOn chn  2 60  0
    

    Cheers,
    Burkhard

     
  • Frank
    Frank
    2014-06-29

    • status: open-fixed --> closed-fixed
    • Group: 0.5.3 --> 0.6.1