hi guys
just raised the severity level on this one after some extended testing in our rehearsal room this weekend.
it has become clear that for live usage (controlling pattern selection by the drummer using drumpads) this one is absolutely blocking :-(
currently you can use select_next in stacked mode where it works as intended, but for our live setup we are working in pattern mode and we need to be able to enable/disable a pattern instantly (be it in stacked mode or non-stacked mode)

is probably solved wit the select_next_pattern_promptly action (by Wolke)

some more info about this : i found a dirty workaround
- create a pattern and set the resolution rather high (32 or 64)
- create a simple pattern (kick + snare)
- move the note that is on the '1' just 1 step further in the pattern (to the next possible position that is allowed by the resolution)
- use the lead/lag setting to configure a lead that compensates for the fact that the not has been moved 1 step (this is trial end error : adjust the lead/lag value while the pattern loops and trust your ears to find the right value)
- if you now play this pattern it sounds totally normal
- repeat the test done to trigger this issue (switch between this pattern and another using select_next) and you will notice that the first beat of this modified pattern is no longer skipped

i know, i know it's a VERY dirty work around but it works, and maybe this is also helpful info for fixing this bug ?

retested on the undo branch today and the issue is also present there :-(
(in non-stacked mode > did not test stacked mode)

hi thijs,
i am working on bugs. so i try to understand if this is a bug, or an enhancement question. only to understand right what you mean with skipped notes, one more questions here.

in normal pattern mode hydrogen switch promptly to the next pattern. if you select an new pattern. it is normal that notes which are in position (e.g. 1) cannot be played because you are already on position x in the moment you select the new pattern. and here is my question. happens this skipping of notes also in the next cycle from the currently selected pattern?

because if not, in this case everything works as expected and we need some brainstorming about an mixed pattern mode which work like stacked mode but without stacking.
stacked mode select the pattern all time in the next cycle independent on which transport position you are.
maybe if i am understand your problem right would be this what you need. normal pattern mode which activate the new assigned pattern exactly to the next cycle.

greetings wolke

ahh ok i got it its a bug.
my scenario:
crate two patterns
use two note keys e.g. 60&61 and assign them to midi action selext_next_pattern.
note key 60 to selext_next_pattern par 0
note key 61 to selext_next_pattern par 1
switch ing in stacked mode workes as expected but in normal mode the first beat of the new selected pattern will dropped into the NEXT cycle. imo this is a bug.

fixed in rev.2353

bug is still present in rev 2376 :-(

can be tested very easily :
-use the config as described above (by Wolke)
-make sure that bothe patterns have a note 'on the 1' (the first note in the bar)
-assign midi keys to 'select_next_pattern 0' and 'select_next_pattern 1'
-press play in hydrogen (manually)
-hit midi key 1 > pattern 0 plays
-hit midi key 2 > pattern 1 plays
when you press one of the midi keys you will hear that the first note of the pattern that is linked to that midi key is NOT played. It works both ways 0>1 or 1>0, but it is always the first note of the newly selected pattern that will not play.

some more info : you dont even have to switch between patterns.
if you press the midi key that is assigned to the pattern that is already playing, you will hear that the first note is skipped.
in the terminal window i get this message every time a note is skipped :

(E) InstrumentList::get idx 54 out of [0;16]
or
(E) InstrumentList::get idx 56 out of [0;16]

depending on the midi key i press

i just noticed that i even get these error messages when the transport is not running ??

changeset 2423. recommit my changes from changeset 2353 and close this bug as fixed.