I changed the behaviour for both the SFZ engine and gig engine to distinguish by note-off velocity being exactly zero for now: http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=4020
That should fix expected release trigger behaviour for both keyboards with and without key release sensors appropriately. If it turns out that some MIDI keyboards with release sensors do send note-off velocity zero (which I doubt), then this behaviour can still be changed to some more complicated MIDI-learn mechanism. BTW the original MIDI v1 specs say keyboards that do not support note-off velocity should send 64 as note-off velocity value. Probably one of the very few mistakes made in the ancient MIDI specs, at least IMO. I haven't looked into latest MIDI v2 specs yet. I noticed though there was some voting process on a note-off related change on midi.org, that thread on midi.org is password protected though, so no idea what this was exactly about. CU Christian On Montag, 3. Januar 2022 19:29:58 CET Raphaël Mouneyres wrote: > thanks for the tests, it makes sense from a firmware perspective to set > 0x01 as a minimum. > > I'll try to have a look at how another keyboard reacts when I have one > at hand, probably during this week or next one, and I'll report back. > > Raphaël > > Le 03/01/2022 à 02:58, Doug Gray a écrit : > > I have run a test on the SL-88, the lowest reported release velocity seems > > to be 0x01. I have tried to release keys as gently as I can but have not > > yet seen a release velocity of zero. It’s easy to hit the 0x01 so I’m > > quite confident it is the lowest possible value. This was not what I > > expected but makes good sense. > > Doug Gray > > > > > > Sent from my iPhone > > > >> On 3 Jan 2022, at 4:19 am, Jerash music <rmouney...@gmail.com> wrote: > >> > >> > >> > >>> Le 2 janv. 2022 à 14:53, Christian Schoenebeck <schoeneb...@linuxsampler.org> a écrit : > >>>> On Sonntag, 2. Januar 2022 14:42:55 CET Jerash music wrote: > >>>> Having worked with (and repairing) many midi keyboard controllers, I > >>>> can say that release velocity is not very common. Mainly available on > >>>> high range keyboard, often with weighted keys, piano style. > >>>> > >>>> Keyboard rubbers with triple sensors offer greater definition so to > >>>> have > >>>> the release velocity, but it can be implemented in the device firmware > >>>> or > >>>> not, at manufacturer’s choice. Keyboard rubber with double sensor could > >>>> also do release velocity, but may miss some when the key is not fully > >>>> pressed before actual release. Here, again, the sent message depends on > >>>> firmware implementation. > >>>> > >>>>> I suggest that that should only be the case when note off velocity is > >>>>> actually zero. > >>>> > >>>> I do agree with this, it totally makes sense to me. > >>>> > >>>> My 2 cents, > >>>> Raphaël > >>> > >>> Ok, but the core question still is: can we expect keyboards *with* > >>> note-off > >>> velocity sensors to *never* send note-off velocity zero? > >> > >> Mmm, …yes it may be possible. > >> it may be possible to send a zero release velocity if the firmware > >> calculates a release velocity and includes a « timeout » for the maximum > >> release time, and then decides that timed out values are zero. But I > >> have not expressly tested it, and each manufacturer could have his own > >> vision. > >> > >> I’ve been explained by Yamaha that the three contact rubbers are > >> especially useful for retriggering calculation of half pressed keys, but > >> they did not talk about release velocity calculation. Maybe Doug Gray > >> could try the following on his SL88 : « Release the key as slow as > >> possible in about 4 seconds » to try to reach the minimum release > >> velocity value. As the keyboard rubber has three contacts, it could > >> potentially send a zero release velocity if you reach a timeout between > >> two contacts releases. I’m not sure if it is humanly possible to reach > >> this potential timeout, as the contact points are really really close. > >> The real duration of this timeout is not documented so needs testing. > >> > >> Raphaël > >> > >> _______________________________________________ > >> Linuxsampler-devel mailing list > >> Linuxsampler-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > > _______________________________________________ > > Linuxsampler-devel mailing list > > Linuxsampler-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
