I tried with another MIDI source beforehand and I got no message lost. I played stupidly fast, I played chords, and it worked perfectly fine. I did not think about a short overload causing the loss of a message.
With your message, I guess it's related to how inputs are managed within MIDI sources and not a specific type of message the PK5 can potentially send.

Thankfully I managed to link my Roland device to my computer using a Roland cable

Lisa,

It doesn't matter, now it's working, but to be fair all around, I don't think it's anything to do with Running Status.

Running Status is totally optional, if it's there, or not there, it should be handled OK. If a sending device does it sometimes, and not others, this should not matter. If messages come too fast, this should not matter.

Far far more likely, the interface you WERE using was just not good enough to handle two instant messages, and was messing up the data.

The Roland interface however can handle the same data no problem, and this works.

Geoff

Hello everyone!

I received a Roland UM-ONE cable and used it to link my roland PK5 pedalboard and my computer.
It turns out Running Status were indeed the missing piece of the puzzle!
Both MIDI-OX and my software print notes termination when I brush a pedal now.

I'm convinced now that brushing a pedal causes the pedalboard to get 2 messages to send really quick and ends up sending a running status as second message.

Thanks everyone for your help and your time!

Lise

The only thing I can think of is perhaps all of your USB MIDI interfaces have the same problem: If two messages are sent very close together, the second message is getting dropped. (Perhaps all the USB MIDI interfaces you have are built from the same chipset or firmware and have the same problem.) Unfortunately, the only solution I can think of is to get another MIDI interface.

This problem you are having could maybe be caused by your USB MIDI interfaces all mishandling Running Status in the same way, but I'm not sure. (They may just be mishandling any messages that are very close together.) I can't tell if focusing on getting Running Status all the way to you computer will be a sure solution for your problem.

I wonder if getting a USB MIDI interface with an "advanced driver" might help ensure you don't get another interface with this same problem.

When a USB MIDI interface lets you use a manufacturer-specific "advanced driver" that you install, this can let it do more things than the class-compliant USB MIDI ability that comes with your OS. I found a blog comment suggesting that the Roland UM-ONE sends Running Status to the computer using its advanced driver mode. I'm not sure if Running Status itself is the solution, but using an advanced driver mode instead of the class-compliant mode sounds like an idea possibly worth checking out, if you are willing to get another USB MIDI interface.

(The UM-ONE manual describes it has a COMP/TAB (computer/tablet) switch you set depending on if you use it with a computer or a tablet. The computer mode requires a driver installation and the tablet mode doesn't require a driver, so it sounds like this switch effectively chooses between "advanced driver" or "class-compliant" modes.)

Hi! And thank you for your response!

First of all, your 3 statements are correct Bavi_H.
About your question, I also have the missing end messages problem when printing the activity on MIDI_OX. I've tested with a couple of different cables and the result is identical.

How can I test running status then? Does a MIDI2USB solution allowing running status exist? Or should I invest in a more recent pedalboard?

In practice, it's almost impossible to trigger a note with a velocity bellow 30 on the PK5 I would say. Most of the time, notes get a velocity between 60 and 127. A velocity issue is unlikely in my opinion

Lise, do I understand the following correctly?:

When you connect the PK-5 to a keyboard using a DIN MIDI cable, the end of notes are always correctly received.

When you connect a keyboard to your Java program using your M-Audio USB MIDI interface, the end of notes are always correctly received.

When you connect the PK-5 to your Java program using your M-Audio USB MIDI interface, then end of notes are sometimes missing.


Question: When you examine the messages from your PK-5 in MIDI-OX, do the end of the notes always appear?

If yes, then maybe there is something about your Java code that causes it to miss messages if they are too close to the previous message.

If no, then maybe the USB MIDI interface might be faulty and dropping messages that are too close to the previous message. Perhaps test with another MIDI interface if you can.



Running Status

Geoff and everyone: Be aware that MIDI-OX can't see if Running Status is used because the Windows MIDI system adds any missing status bytes before MIDI-OX sees the messages. (For example, see this running status post on the MIDI-OX user forum.)

Also, as Clemens Ladisch says, MIDI messages over USB must always contain a status byte, so when using USB, any missing status bytes were already added back by the USB MIDI interface before Windows even sees them.

I think that tracing the exact use of Running Status might be helpful if you think a USB MIDI interface is faulty and you need to confirm exactly how it is failing. But I suspect that trying to trace the exact use of Running Status might be a distraction for Lise's problem.



Velocity

Geoff pointed out the PK-5 manual says it can be set to a velocity range of 0 to 127, but I suspect this is a mistake and it should say 1 to 127. If the PK-5 really does let you start a note with velocity zero, then if you press a pedal very lightly, you might see two sequential Note On messages with velocity zero, one for the start of the note and one for the end of the note. But I can't figure out a way that could cause the the issue Lise is having: Lise's Java program is reporting notes that begin with velocities in the 120s, but sometimes not seeing the end of a note (a Note On message with velocity zero).

Velocity does not affect the results. The only difference is the velocity byte set to 64 when the feature is on, apart from that the output is the same... including the bug.
The owner manual of the Roland PK5 does not explain a lot of technical stuff, it's purely functional.

When catching messages from a keyboard , I have no problem receiving NOTE_OFF messages (understand NOTE_ON with velocity = 0).

Active Sensing messages occur every 300 milliseconds.

Do you know a way to test running status? I need a solution I can use with my Java program :'(

The USB MIDI protocol does not use running status (because the USB bandwidth is so high that saving bytes is not necessary). Therefore, all USB/MIDI interfaces must insert the 'missing' status bytes when converting from MIDI to USB.

It's possible that the PK5 uses Running Status only if not too much time has elapsed since the last channel message. This would imply that the Uno does not handle Running Status correctly. Does the Uno work when receiving from the keyboard?

What is the time between those Active Sensing messages?

Hello,

I'm not sure if you have a manual for this, but there's one here you can download/print:

https://static.roland.com/assets/media/pdf/PK-5_OM.pdf

This may be a help, but it doesn't say anything about the Midi Implementation.

I do see an oddity that may be relevant. There is the ability to set the Velocity sensitivity. The default is ON. If this is set to OFF then all Velocity is set to 64 (mid range).
If this is ON, then Velocity is in a range of 0 to 127. So the very slightest touch will be implemented as 0, which is NOTE OFF, not NOTE ON but quietest setting. This may be causing some confusion. There is no indication that the PK-5 supports Running Status. I have not read the manual fully.

How do things work if the Velocity Sensitivity is set to OFF. This may help indicate where the problem is coming from.

Geoff

If I understood you correctly, I should see running status in the logs if they are sent by the pedalboard?
The Roland PK5 is quite old now, I would guess it sends running status in specific scenarios, but there is no in-depth documentation about it so it's just an assumption I make here.
You talked about voltage further up, and that may be a thing. If it is, is it possible to get a voltage such as messages are sent without any loss across a classic MIDI cable but fail to reach a computer with a USB2MIDI cable?

If none of these are possible, I'm out of clues

Lise

Running Status. When the first byte (the Status Byte) of a three byte standard message is the same as the first byte of the previous message, then it is discarded and not sent. At the receiving end, when the receiving device receives a message with no Status Byte, then Russing Status is assumed and the last Status Byte is repeated to replace the missing byte.

A specific Note Off message would be started by a different Status Byte, therefore it would cancel any Running Status. Using the Note On with zero Velocity would allow Running Status to continue.

Depending on the music, that process can save quite a few bytes, and reduce the data flow along the cable. With faster computers and more complex data, then RS is less important. Receiving devices SHOULD support RS, but increasingly sending devices (such as keyboards) may not generate RS.

I would say that MIDI-OX SHOULD show RS messages. They are fully valid messages. Maybe there's a box to tick as to showing them, or not showing them. The default should be to show them.

There is no reason why the cable should turn a 2 byte RS message into a 3 byte message, as the destination system should do this anyway. If the cable does this correctly and reliably, then OK, no problem. If the cable tries to do this, but messes things up and produces an incomplete message, or no message at all, then this is NO HELP AT ALL!

Geoff

Here you will find a list of messages caught from my Java program during my test.
I used an M-audio UNO cable to perform the test.

You can spot when I brushed the pedal, whenever there is no message with v=0 between two NOTE_ON messages with v>0.
There is no messages of 2 bytes, is it a cable issue?

Thanks,

Lise

Hi Geoff!

First of all thank you very much for the response!

I tested with both cheap Chinese cables and with an M-Audio Cable. The latter one costs around 30 dollars and supports SysEx messages.
I'm glad you speak about Running Status! Yesterday I spent my evening investigating towards running status and I had the feeling that it was the missing piece of the puzzle.

Here are my results:
1- MIDI-OX software does not show running status messages
2- When listening to midi messages within a Java program, I only receive 1-byte-messages (active sensing 0xFE) or 3-byte-messages (NOTE_ON/NOTE_OFF messages).
3- I've read on forums that some USB2MIDI cables keep track of the last status received to build a 3-byte-message if a running status is received afterward, do you know something about that?

I will test once again to print my results and show missing NOTE_OFF messages

Lise

First of all, what is the MIDI2USB cable you're using. There are Chinese variants of these which are notoroius for giving problems, they work under some circumstances, and do not work properly/fully under others.

Check other threads on this forum, and on the web re Chinese USB MIDI CABLES..

Secondly, the use of MIDI ON with a velocity of zero is a perfectly normal and legitimate way of doing NOTE OFF, this is to facilitate the use of Running Status. However, one of the things that the Chinese interface can have trouble with is Running Status.

Apart from this, you seem to make a specific distinction between PRESSing the pedal, and BRUSHING the pedal. How different are these two. Maybe the PRESScreates a better voltage, or maybe the BRUSH is more easily treated as Running Status. These may indicate a fault with the pedal. To investigate this, can you 'capture' some of the data coming into the computer, which includes data that seems to be OK, and data that shows the problem, and post that data here so it can be investigated byte-by-byte?

Geoff