I don't see anything wrong with your english!

When you refer to your 'old Roland ', what do you mean by 'old'. Has it been used unused for a while, how was it stored?

I don't know the full details of the mechanics of a keyboard, there could be differences between manufacturers, but your description suggests the possibility that certain micro-switches or sensors are not working reliably.

Something needs to detect the fact that a key has been pressed (to give Note On) and the speed/power with which it was pressed (to give Velocity, if the keyboard in Velocity sensitive). Then something needs to detect that the key was released (to generate Note Off).

I take it from your description that usually the notes play, and end, correctly. But sometimes, when notes are played quickly (I assume you mean that the notes are of VERY small duration, and maybe the keys are not pressed as positively as usual) then the note ON is detected, but the note off is 'lost' (or maybe is not detected).

This could be merely a mechanical problem, maybe caused by dust (or something else) interfering with the contact, which shows up if the contact is not as positive as usual..

I would suggest - pending serious cleaning inside - then you try to well exercise certain keys with normal playing, to determine that they CAN work normally, and then use the same keys to play increasingly quickly to get to the point at which they start to show the same problem (loss of Note Off). Is the point at which this happens consistent for ALL notes. If you then try some other notes NOT previously 'exercised', do they show problem at the same point?

I do not see a way that the other components of your system might generate the same symptoms as you describe.

Geoff

Hi Geoff, Thank you for the response!
This keyboard has been unused for 4 or 5 years, stored into a case. I recently opened it and cleaned the keys' rubber, but not the eletronic part, as I was afraid of disassembling/reassembling everything D:
Every note presents the same strange behavior, and what really make me confused is the fact that, in the MIDI-OX, all the 'note off' are present, but when the problem occurs, instead of being assigned to the same port as the 'note on' (4), they go to the other port (1). Then I was thinking it could be more of a software problem, but I will try what you said and then I report if it worked!

Oh, just dug a little deeper, and I OUGHT to have asked...

What happens when you play the keyboard when it is NOT connected to anything, i.e. no midi signals to interface etc.

If the keyboard works fine on it's own, then the problem is NOT with the keyboard, there's something strange with the interface (which is a ???).

If the keyboard alone has the same problem, then it is mechanical within the keyboard.

geoff

The keyboard itself works really well. The interface is a Brazillian brand one, called E. R. Pires Prelude. I was thinking that maybe the interface is the problem, but before exchanging it, I really wanted to find a solution, because I would have to send it back to a distant state. But I'm going to test it with a friend's keyboard, to see if it will be the same

Yes, sounds like keyboard should be OK.

I don't understand how 'ports' come into it.

All midi data generated by the keyboard should go the same way, as a stream, and be received at the other end as a stream. There may be certain sorts of midi manipulation that involves a split of certain types of event to go one way, and other events to go another, but I would suggest that such a process should NEVER separate midi ON and Midi OFF events.

Not sure if an 'interface' would do such a thing, is there software involved?

Why are you using an 'interface'? Is it because the keyboard has midi connectors and no USB, but the computer has USB and no midi (sound card)? At what point are 'ports' involved, maybe the connection between the interface and the computer?

Geoff

Yep, no midi in sound card and no usb on the keyboard, it's an old model. I don't understand the ports thing, it's just written at the MIDI-OX software, and when the problem triggers, the thing I said related to the 'ports' happens too, it's strange. Did you watch the second video? It shows what I'm talking about

Yes, I watched the two videos, meant nothing at all to me. Not remotely familiar with any of the software illustrated. Pics too small to see anything useful.

I'd guess that either the interface, or the software (kontact ?) is doing something. If this shows in the MIDI-OX, at what point does this happen.

Please show more detail.

Is the link keybd->interface->pc->Kontact->midi-ox or are you using the midi-ox in place of the Kontact or what. And again, where does the 'port' come into it? Is this part of the connection for the interface, or for Kontact, or just for midi-ox?

Usually, the 'port' is a memory location which is assigned so that one device can communicate with another. A sound card, for example, may use one or more defined addresses in the pc memory map so that each puts commands or data in a specific place that the other can then look for and read. The process can be more complicated/sophisticated with the use of IRQs as well, but the port is still there.

Geoff

In the MIDI-OX port activity window, the rows represent ports and the columns 1 to 16 represent MIDI channels. In the monitor output window, the CHAN column shows what MIDI channel the message is for. It looks like your keyboard is trying to send notes on both channels 4 and 1. Edit: It looks like messages are sometimes missing from either channel 4 or 1. There should be Note On and Note Off pairs in both channels, but some are unpaired. Maybe something in your system doesn't like it when messages are sent at the exact same time.

Based on an image search, the Roland Alpha-Jr appears to be the same as the Roland EM-15: Roland Alpha-Jr (click in the address box and press Enter to reload the page with a larger image), Roland EM-15.

Here is the manual for the Roland EM-15: Roland Support - EM-15 Owner's Manual. PDF page 71 (printed page 69) explains the main keyboard part "Upper 1" is sent on channel 4 and the "accomp. 1" part is sent on channel 1.

I am concerned that some of the messages aren't getting through. That sounds like a problem. But here are some ideas that might turn off the channel 1 messages for now as a workaround.

A. Press the PIANO button to turn off the accompaniment mode. Maybe this will turn off the channel 1 messages.

B. Use the FUNCTION button to get to the "MIDI TxRx" setting then change it to KBD. According to PDF page 71 (printed page 69), this will send only the keyboard channel messages and not the accompaniment channel messages.

I had the same issue with Yamaha PSR E-303. It have "split mode" when lower keys (left hand) are mapped to midi channel 3 and upper keys (right hand) to channel 1. I tried to play two channels simultaneously with Yoshimi soft synth: bass (ch 3) on left hand and piano (ch 1) on the right and i got hanging bass notes.

When i press and release bass key, in MIDI-OX i see: Note On in CH3 followed by Note Off in CH1. At first I thought it was a problem with cheap USB-to-MIDI from ebay. But for sure i take raw midi out capture with logical analyzer and here was surprise:

three bytes for note-on sequence:
1001 0010 (Status: note-on in channel 3)
0010 0100 (Note number)
0101 1000 (Velocity 88)

and only two bytes for note-off:
0010 0100 (Note number)
0000 0000 (Velocity 0)

I googled this case and found such pdf: https://www.nyu.edu/classes/bello/FMT_files/9_MIDI_code.pdf
It says Note on, velocity zero is equivalent to note off (see page 8)

So, most probably it's kind of optimization to save midi throughput. Status byte is absent and zero-velocity means note-off for last mentioned channel. When i press and release two keys for different channels in this order:
Bass On -> Piano On -> Bass Off -> Piano Off
then i get full three bytes note-off sequence and no hanging notes.

I think hardware is ok and there is issue with kontakt and MIDI-OX too.

Yes, a Note On message with a zero velocity is equivalent to a Note Off message. This facilitates "running status" which is why the status byte is not present in the second message. This is standard MIDI.

Cheers
Eddie

Thank you all for the efforts!! I tried everything you told me, but sadly none of the solutions worked 🙁
I think I'm just giving up to the idea of using this keyboard. I will get the money to buy a decent controller in a few months, and until then I'll be learning how to use my daw and vstis.
Again, thank you all for being so helpful, I really appreciate what you did here!! 🙂

I've checked the earlier messages, and I don't think there's anything connected with running status here. Operation is usually correct, except some notes played more quickly seem to be having the note OFF assigned to a different channel to the Note On.

The problem is, what is causing some event being assigned to a different channel when it should NOT. Various MUSICAL events can comprise more than one MIDI event. ALL the MIDI events that relate to a single MUSICAL event should stay on the same channel, else mayhem may result.

The comments regarding keyboard split may be far more appropriate, but here, the keyboard split SHOULD result in BOTH note ON and Note OFF being assigned to the same channel. Just that some keys in one part of the keyboard may put the events to one channel, and another area of the keyboard should put the events to another channel.

Geoff

I agree that running status, by itself, isn't causing the problem. But if the MIDI interface is poor quality, maybe it is getting confused by the running status.

Here's a hypothesis I had, but there's not an easy way to confirm this hypothesis. If the MIDI interface is poor quality, maybe it is re-arranging the order of the MIDI messages that happen at the same time.

Hypothetical example

Keyboard sends:

(message 1) 90 3C 64 (Note On channel 1, middle C, velocity 100)

(message 2) 91 3C 64 (Note On channel 2, middle C, velocity 100)

(pause)

(message 3)    3C 00 (  "   "    "    ", middle C, velocity   0)

(message 4) 90 3C 00 (Note On channel 1, middle C, velocity   0)



Interface: rearranges message 3 and 4.



PC gets:

(message 1) 90 3C 64 (Note On channel 1, middle C, velocity 100)

(message 2) 91 3C 64 (Note On channel 2, middle C, velocity 100)

(pause)

(message 4) 90 3C 00 (Note On channel 1, middle C, velocity   0)

(message 3)    3C 00 (  "   "    "    ", middle C, velocity   0)

In this hypothetical example, message 3 uses running status and is supposed to turn off the channel 2 note. But if message 3 gets rearranged to come last, it ends up turning off the channel 1 note again, and the channel 2 note is left hanging.

MIDI-OX can't see incoming running status

If you search online for "MIDI-OX running status" you will find forum posts that explain Windows MIDI drivers add back the missing status bytes implied when running status is used before the application sees the message. (For example: Running status indication (MIDI-OX User Forum)) Since MIDI-OX always shows a status byte, we can't troubleshoot if the original message from the keyboard was using running status by using MIDI-OX.

Continuing the hypothetical example above...

Windows MIDI driver: adds in status bytes implied by

  running status.



MIDI-OX sees:

(message 1) 90 3C 64 (Note On channel 1, middle C, velocity 100)

(message 2) 91 3C 64 (Note On channel 2, middle C, velocity 100)

(pause)

(message 4) 90 3C 00 (Note On channel 1, middle C, velocity   0)

(message 3) 90 3C 00 (Note On channel 1, middle C, velocity   0)

Note: MIDI-OX calls a Note On message with velocity 0 a Note Off because it behaves like a Note Off. But in Jomarx Soares's video you can see they are 9_ __ 00 messages (Note On channel _, __, velocity 0).

My hypothesis is just a guess, but you can begin to see how a poor quality MIDI interface might cause problems like this. If some MIDI messages are re-arranged (or even dropped), then the running status might no longer be correct.

Jomarx,

You might want to try a friend's keyboard, as you suggested earlier, to confirm whether the problem is in the MIDI interface instead of the keyboard.

Some of the companies that make USB-MIDI interfaces simply purchase a chip from China and assemble it into their own package... some of those chips do not function correctly, which might cause a problem like you are having.

Forum Admin
www.midi.org