Midi/in/keyb gate outlet not behaving as I expect?

#1

Hi, I've got an issue with a really basic patch, it's a midi/in/keyb connected via gate to edrum/bd1 to an audio/out/stereo. If I press and hold the right most key on my 25key keyboard I hear the drum sound, if I then slide my finger down the rest of the keyboard, I get no sound triggering.

If I keep a key held and hit another note on it's own I get no sound but the next key I hit after that will work and all following keys work as well.

If I swap from using gate to gate2, everything works as expected. I've monitored the midi input and and I'm getting all of the note on/off messages but I do notice that the note off message for the last key arrives after the note on message for the next key.

Axoloti says: NoteOn ch 0 n 72 v 77
Axoloti says: NoteOn ch 0 n 71 v 28
Axoloti says: NoteOff ch 0 n 72 v 0
Axoloti says: NoteOn ch 0 n 69 v 44
Axoloti says: NoteOff ch 0 n 71 v 0
Axoloti says: NoteOn ch 0 n 67 v 41
Axoloti says: NoteOff ch 0 n 69 v 0
Axoloti says: NoteOn ch 0 n 65 v 52
Axoloti says: NoteOff ch 0 n 67 v 0
Axoloti says: NoteOn ch 0 n 64 v 53
Axoloti says: NoteOff ch 0 n 65 v 0
Axoloti says: NoteOn ch 0 n 62 v 54
Axoloti says: NoteOff ch 0 n 64 v 0
Axoloti says: NoteOn ch 0 n 60 v 55
Axoloti says: NoteOff ch 0 n 62 v 0
Axoloti says: NoteOn ch 0 n 59 v 53
Axoloti says: NoteOff ch 0 n 60 v 0
Axoloti says: NoteOn ch 0 n 57 v 41
Axoloti says: NoteOn ch 0 n 55 v 43
Axoloti says: NoteOff ch 0 n 57 v 0
Axoloti says: NoteOn ch 0 n 53 v 33
Axoloti says: NoteOff ch 0 n 55 v 0
Axoloti says: NoteOn ch 0 n 52 v 27
Axoloti says: NoteOff ch 0 n 53 v 0
Axoloti says: NoteOn ch 0 n 50 v 43
Axoloti says: NoteOff ch 0 n 52 v 0
Axoloti says: NoteOn ch 0 n 48 v 54
Axoloti says: NoteOff ch 0 n 50 v 0
Axoloti says: NoteOff ch 0 n 48 v 0

I've checked the behaviour on another synth and that works fine, if I replace the keyb object with a keyb mod object I get the same issues. I've looked at the edrum/bd1 object definition and the only thing I can think of is the env/d or env d lim objects?

#2

gate does not re-trigger on legato (overlapping notes) whereas gate2 does.
your midi trace shows legato, so Id say thats what your seeing... or am i missing something in your description?

#3

I think you've understood most of my description correctly. I had read about no re-trigger for legato on gate, that's why I'm pointing this out, the behaviour isn't consistent between 2 patches, on an edrum/bd1 based patch, it works like I described which is correct according to the way you say it works (no re-trigger) BUT on another patch, it appears that it is re-triggering on legato notes.

#4

ok, had a chance to test it, and Id agree with you, its not quite as i would expect.

if ((status == MIDI_NOTE_ON + attr_midichannel) && (data2)) {
  _velo = data2;
  _note = data1-64;
  _gate = 1<<27;
  _gate2 = 0;
} else if (((status == MIDI_NOTE_ON + attr_midichannel) && (!data2))||
          (status == MIDI_NOTE_OFF + attr_midichannel)) {
  if (_note == data1-64) {
    _rvelo = data2;
    _gate = 0;
  }
} else if ((status == attr_midichannel + MIDI_CONTROL_CHANGE)&&(data1 == MIDI_C_ALL_NOTES_OFF)) {
  _gate = 0;
}

the 'issue' is note changes for every note on*, so the legato is only held for the last note played, as then note change to the latest note played...

I thought that usually legato holds until all notes are release, no? (certainly how it works on my Virus)
ie. if you press and hold GAB, you get one trigger on G, and then just pitch changes, as only as any one of the notes is pressed down.

to do this, the midi handle would have to count note on/off and gate is then count>0.
(ok, ideally object would keep track of notes, in-case some dodgy controller started sending 2 note-offs for the the same note, but I think we can live with this.)

@johannes, bug, intentional?

#5

It's got me a little confused, if it was consistent then it would make sense :smiley: The only real difference between the 2 patches I am comparing is that the one that plays notes all the way down the keyboard and is using an env/adsr compared to the 'broken' patch that's got an env/d and env/d lin m.

Either way, legato doesn't appear to behave how I'd expect it but that doesn't mean it's wrong, I think there's going to be more than one way to implement it, I have seen legato where you hold a note and a sound plays, press another note and a new sound plays, let go of that note and the original note plays (along with glide it makes interesting sounds).

At the moment I see it behave like this: press and hold a note, the note plays, press a new note and the original stops, new note starts to play, let go of 2nd note, note decays to silence. It appears that the current implementation of legato isn't handling the held note?

MIDI Keyboard Object Legato Behaviour
#6

Ah, use "midi/in/keyb zone lru" for that behavior.

I think the source of confusion is the difference in envelope response. "env/adsr" does not reset to zero when interrupted, while "env/d" does.

#7

That's the reverse of what I/we're seeing, because all the keys work on the env/adsr based patch on gate and gate 2 which suggests env/adsr does actually reset to zero when interrupted even though it shouldn't actually be receiving anything through legato'd notes from the gate outlet on keyb objects, I think that's where the confusion lies and it's the interaction between keyb objects and env/adsr?

And excellent, thanks for the lru tip, that's going be very useful.

#8

nope thats not it for me....does the same with ADSR and AD

try this...
play a note (e.g. G)and hold it down, don't release
now play another note (e.g C) , and keep playing it (C) whilst holding other note down.

what will happen is G is played, with trigger (correct) C is played without trigger (correct), then C is played again with trigger (incorrect) ...

what should happen in legato, is the G should be played with trigger but all subsequent notes e.g. C should not trigger, because G is held down still.
this is how my Virus works at least... I don't know if this is a 'standard', or if different synths behave differently.

@Reggie , we need to be careful not to mix legato behaviour, which is triggering and voice strategy (which as you say there are many, e.g. play if higher, lower, last note etc).
axoloti kindly keeps these separate, whereas some synths I think mix this up into a 'voice modes'
e.g. my virus has 1 poly mode, and then 4 mono modes, the mono modes are combinations of legato retriggering and voice allocation.

#9

It's getting weirder then because that's the reverse of what I'm seeing, with an adsr, doesn't matter which gate I use, it fires every time a key is pressed no matter what the state of the other keys are.

I don't mind how the legato behaviour is arranged as long as we can achieve whatever it is we want to achieve, I suspect some people would welcome the ability to easily switch between legato/voice modes but I expect those same people wouldn't mind if it was split up between a handful of functions and an appropriate muxer if it achieves the same result.

#10

I suspect... we need to get some specific examples....

what I'm experiencing, I can see the code implements, so my 'question' is really down to what the intended behaviour is... its quite possible (as I said in previous post) that @johannes has seen the current behaviour in a synth, which would imply there are different possible legator implementations... rather than it being 'wrong'. though personally, i find the current implementation 'odd' but that possibly just down to the synths I use.

(the current implementation, right or wrong, basically says the last key you press becomes the legato hold... so if you don't follow this, it can 'appear' quite random.... also you need to do this with monophonic voices only , as poly will make it appear even more 'random')

#11

Here are the patches I am comparing.

MonoSynth.axp (3.2 KB)

BDtest.axp (1.2 KB)

#12

@reggie in the attached patch you will find an embedded object which Im proposing as an update to the midi/in/keyb , do you want to try it and see if it behaves as you expect.

(you can use cut n paste, to move the embedded object to your own patches should you wish to test there)

ltest.axp

basically, it changes the behaviour of both gate and gate2 to be more consistent with how I believe legato should behave.

note: Ive given to johannes as well to test, so only if he is happy with it, will it be applied to the keyb objects in 1.0.11. but I thought it would be interesting to see if its what your expecting too.

#13

@thetechnobear thank you, I'll give it a test when I get some time later on :smiley: Did you check my patches and see the issues I was seeing? That's the bit that I was mostly concerned about, that the keyb objects were being inconsistent between patches or whether it was my understanding that was lacking.

#14

I did check your patches, and I could see/hear incorrect behaviour in both.
but in fairness, this is probably because I know whats going on, and why I think its wrong in both patches :wink:

(its one of those areas where the behaviour was consistent, but depending on what the patch expects MAY give you roughly what you want... except there are cases where it fails there too, if you know what you looking for)

anyway, I did a quick test with my patch/object from my patch, and I believe it now acts both consistently and correctly.... meaning gate will only trigger when its the first (and only( note pressed, and gate2 will trigger on every new note.

#15

Oh yeah, I definitely bow to yours and johannes superior knowledge!! I've just done a quick test and it appears to work correctly for env/ad_1, swapped out for an env/d (the one I was experiencing issues with) and it's working fine with that too.

I have however spotted something else, gate 2 on your patch/object triggers twice on a legato'd note, hold any key down, press and release a 2nd, you get 2 triggers, is this expected or unusual? It's getting a hit from the note on and the note off.

#16

yeah, this was 'intended' as Ive the same behaviour on my synth BUT Ive realised it cant work like this as the pitch is not as intended.
anyway, here I attached a modified version, which fixes this

Id be grateful if you could test this, and let me know if its better

ltest2.axp (5.0 KB)

#17

Thanks, It seems to be working correctly now, tested on an env/d again as well.