BUG: arp-up/down latches when no longer latched intentionally

[matrix12x]

I press arp up/dn I hold a chord I press the sustain pedal twice (latch on then latch off, then latch on then latch off) while still holding the chord the chord remains latched until I hit the arp button (meanwhile the record led is off)

record button does same thing

[el-folie]

Alpha13: I can confirm the bug. After the first latch on/off: the lowest note of 3-note-chord is being held with keys released. After two latch on/offs: the 3-note-chord is being held but the pattern changes to top/bottom notes being triggered twice with and without keys being held. Also the top note is only double triggered every second time in the pattern. Funny! :-) And while the arp is still running despite latch off, one can add new notes to the arp and even change them on the fly.

[matrix12x]

The other arp buttons do not seem to replicate this bug.

re: the notes I have the same behavior as @el-folie

[image-et-son]

Should be fixed in 13.2. When reverting the u/d logic to the v2.1 implementation I failed to also change the function which removes held notes once hold is deactivated. Since the logic of the other arp variants is completely different but uses the same array, that caused unpredictable errors. It is fixed now.

[el-folie]

Tested, confirmed no unwanted latching anymore.

[el-folie]

But found something else only now, sorry, don´t know yet if it was there before alpha 13.2 (will go back to test):

When in ASSIGN/RNDM arp modes and using the hold pedal for latching, when changing the chord and shortly releasing the hold pedal to latch the new chord, the old notes seem to be interpreted as pauses in the pattern. This leads to different rhythms which can be nice but a simple chord latch with changes is hard to do.

[el-folie]

Yep, bug in ASSIGN/RNDM modes when latched confirmed for alpha13.2, as it´s not there on 13.1.

[image-et-son]

I have a look to see if that can be avoided by placing BLOCKS around the reshuffle or by queuing the hold event. But with the recent experience I would expect some more side effects from that. As I grow more confident with the entire code I am also ready to do more drastic things through which I learn more implicit dependencies at the expense of having new bugs in the versions. Thanks for the support.

[el-folie]

Always happy to help when I can... I´m just glad that you´re so extremely competent with coding.

Better bug description: When latching the chord by hold pedal and then changing the chord and then releasing the hold pedal, the old notes are being kept in arp memory as "ghost notes" and do make for pauses. The pauses even add up when adding further chords and latching and releasing hold pedal. Funny and interesting!

[matrix12x]

Alpha 13.2 I confirm the bug I reported re: arp up/down is fixed. I also confirm I get exactly the same ASSIGN/RNDM arp mode when using the hold pedal bugs. (the pauses)

[el-folie]

A question concerning the arp while you´re at it: Could the arp be made to never reset its timing grid on a new key press? So that after a playing pause a new key press would alway gets quantized to the timing grid still running silently in the background. That would make the arp perfect for live playing.

[image-et-son]

Hm, am not sure if I understand your idea. First which modes do you mean? U/D? Do you mean that if you have a 3 note / 4 beat U/D sequence an you stop it, it still runs 1..4 in the background, so if you press a key again if will resume at the position? In this case I think there are many questions, for instance, what time signature should run in the background? What if you play more notes or less notes when you resume, etc.. But maybe I completely misunderstood you?

[el-folie]

Yes, I think I wasn´t clear enough... It´s nothing complicated:

Now it´s like this: With the arp running any new notes are being quantized to the speed of the arp. Fine if one always holds at least one key to not lose the timing/clocked grid. But when shortly releasing all keys and then pressing new keys the timing is broken, it is reset to the new "note on" moment.

Every bar = one spot for a note = arp timing grid: |---|---|---|---| = when keys are being held/latched

But after releasing all keys there´s a reset in timing which throws the consistency off: |---|---|---|------|---|---|---|---|---|---|-|---|---|---| ____long____short ____pause___pause ____reset____reset

On a Juno 60 (which´ arp is perfect) it´s like this: The arp always quantizes new notes to the timiing grid, no matter if keys are still being held or not. So if one releases all keys and then press new ones, the timing is still intact in relation the moment when the last keys were released.

On a Juno60 the timing runs through, any note can only fall into the grid and is always correct in timing: |---|---|---|---|---|---|---|---|---|---|---|---|---|---|

So, it´s nothing complicated like syncopations or different resolution for timing, just a hard quantized timing for any note, whether being held or pressed new after a pause.

[el-folie]

A more simple explanation: Any new note is quantized hard to the beat of the arp speed. That also means that when a "note on" falls between two beats of the arp grid it is not triggered instantly but only on the next arp beat. So, no timing restart on "note ons".

[matrix12x]

I thought for live playing, people would want the timing to reset on a key press so you are in better sync with the drummer, et cetera.

Although, I personally like the proposal from @el-folie.

[el-folie]

If the arp and the drummer are in sync/same clock/beat, the keyboard player can never be out of timing with the above arp method, whether he presses keys or not, that´s the trick... That´s how the Juno 60 was, I miss that machine.

And I agree that it´s a special behaviour. So maybe best as switch like "arp restart"-"Yes/No".

But if too complicated to implement please don´t bother...

[el-folie]

The more I think about it, maybe it´s just "internal sync" without restart? I never tried MIDI sync for the arp but assumed it would then behave like in my proposal.

[image-et-son]

Hi, I now understand what you mean - was thinking too complicated. But I think the situation is as follows: if in sync with other instruments / musicians, that would be via a common clock. I can't imagine that anyone could hold the time that precisely over a longer pause. Since the P600 can never be the clock master (not supported) it will need to receive a clock. In that case, the behaviour is exactly as you describe, e.g. next tone on the next global clock beat. If, however, you playing freely and rely on internal clock, I think that MX is right, you'd want to start on cue (just hoping that the band hasn't changed the tempo during your pause :-)) . Long story short: I think it effectively already does what you describe. To mimic the Juno 60 behaviour would just need an external clock.

[el-folie]

Oh yes, I quite good remember the "timing" of my various band mates when we were young, haha... ;-)

And yes, will have to checkout the arp with an external clock...

[matrix12x]

I just compiled a771b63 and it seems to have fixed the arp bugs.

[image-et-son]

Thanks

[el-folie]

Can confirm arp modes/latching work flawlessly now.