Transforming MIDI from a tri-sensor keyboard?

My keyboard has a "tri-sensor" action, which allows it to more closely mimic the behaviour of the double-escapement mechanism of a grand piano. I.e - it allows note repeats for relatively shallow key releases, and when this occurs, the keyboard actually doesn't send a Note-Off - it will just keep sending Note-Ons, until the key is fully released, at which point it blasts out all the outstanding Note-Offs at once.
So that some software I'm using works correctly, I'd like to be able to transform the MIDI data, in real time, to standard Note-On/Note-Off pairs.
Looking at the Bome documentation, this looks like it could be tricky, because it doesn't support arrays. Is there a way to do this transformation using Bome?  I see that it supports global variables, so that's a start. I guess I could use a single variable and treat it as a bit-mask, and somehow do bit arithmetic?
Any plans to support Python or Javascript etc?

Well with most MIDI, sending additional note-ons, with no note-offs shouldn't hurt any thing.  However yes, you could use global variables as a bitmap to track note-on messages so that only the first note-off message of that same key position is sent (if that is what you are looking for).  You could also suppress sending additiona note-on messages if you see the note is already depressed (a note on without a corresponding note-off). 

Each global variable handles 32 bits so if you have a 61 key keyboard you would need 2 global variables 2*32=64 (so 3 bits to spare). If you want to track 127 keys (the maximum MIDI allows) it would take 127/32 or 4 global variables. 

 

The logic for note-on would be to identify the bit to turn on, determine its current state and then if already on, do nothing.  If it is not on, you would set the bit and send the note on message.

For note-off, it is similar. Identify the bit to turn off, determine its current state and if already off do nothing. If it is currently set, you unset the bit and send a note-off message.

 

In both cases, defining the right bit would be first determined by the right global variable to use, then the right bit within the target global variable.

 

This post has some of the basic logic for bit mapping using the current scripting language.

https://www.bomeloft.com/support/kb/bitwise-how-much-do-i-gain

Creating an entire project for you is beyond the scope of this support, but if you can't find the post, I can help further.

As far s Python or Javascript, I know there are plans for a new scripting engine/language but I don't have any timelines and as yet, have not seen any Beta program. I'm not sure that the target language is yet decided but I imagine it will be something with a small footprint and a lot of common language and maybe even object oriented features. 

 

I'll let Florian Bomers elaborate further on that if he wishes to do so, however future plans and timelines are seldom discussed here until they get pretty close to release.

 

 

Steve Caldwell
Bome Customer Care

---

Also available for paid consulting services: bome@sniz.biz

 

 

 

 

Thankyou for your rapid and very helpful response - MUCH appreciated.

Working like a champ.
Btw, not that it matters, but it doesn't do exactly what you suggested. When it encounters a Note-On for an already sounding note, it will catch it, and send a Note-Off, and THEN send a Note-On immediately after it.  At the end, when an actual Note-Off is received, it passes it through normally.

I'd have to check, but I thought I got it right. It should not send a note-off then another note on after that. Maybe the bitmap was not set correctly.

I was lazy - I let all the Note-Offs go through. They're not the problem. :D The subtlety that I don't see reflected in your initial reply is this: for each consecutive Note-On, we still need to play, or record, that note. So, when we encounter such a Note-On, we inject a Note-Off just before it, into the stream, and then immediately send the Note-On. Information has been lost (the fact that the note was repeated "legato"), but the receiving end records it as a note - that's the important thing.

Just by the way - I think you're right - most things handle the consecutive Note-Ons reasonably well - that's my experience.  I'm using a scoring program at the moment though, and it definitely doesn't like it at all. Having said that, it's rare that I will play in this fashion, and it's common to have to make edits after live recording into a scoring application anyway, so this fix won't make me more productive, but it just gives me a good feeling there's one less thing to go wrong. Also, I'm having another problem with the scoring app, and it's good that I can now eliminate the contiguous Note-Ons as a possible factor with that problem.

I'm sure the project file can be tweaked to meet your needs of your scoring app is consistent on how it treats incoming messages.

 

It's working already, yes. I can do a legato repeat, and the app records the repeat. I can now relax, knowing that when this happens, the note won't be missed.

Good deal!