[SOLVED, sort of] CC64 damper pedal vagaries on latest Oram Stable / Pi5 / V5.1

[Aethermind]

@zynthianers, @jofemodo, @riban

I am experiencing a strange behaviour of the sustain/damper pedal in latest Oram Stable, both on V5.1 and my custom Pi5 build. While evaluating a recently downloaded soundfonts collection, I realised that there were issues with unrecognised pedal-off messages, that caused notes to be stuck. After further analysis, I discovered that:

1] The problem is engine-unrelated, and happens with every synth or Rompler processor.

2] The issue shows equally on USB-B Midi and DIN-5 Midi, with no appreciable differences.

I attach here two Midi logs from USB-B and DIN-5 Midi damper pedal operation, where it is obvious that more CC64 messages of various values, besides the regular initial 127, are received by the Zynth, and arguably processed wrongly. Sometimes, resetting to 0/released pedal requires a further isolated damper pressure, and long-pressed pedal action seems to create the issue the most, while quick pressures and pedal releases cause the problem less frequently, but this is unpredictable and inconsistent behaviour.

[Example of Midi log on DIN-5]

CH#01 CONTROL_CHANGE 64 => 127

CH#01 CONTROL_CHANGE 64 => 20

CH#01 CONTROL_CHANGE 64 => 0

CH#01 CONTROL_CHANGE 64 => 127

CH#01 CONTROL_CHANGE 64 => 73

CH#01 CONTROL_CHANGE 64 => 0

CH#01 CONTROL_CHANGE 64 => 127

CH#01 CONTROL_CHANGE 64 => 94

CH#01 CONTROL_CHANGE 64 => 0

CH#01 CONTROL_CHANGE 64 => 127

CH#01 CONTROL_CHANGE 64 => 123

CH#01 CONTROL_CHANGE 64 => 127

CH#01 CONTROL_CHANGE 64 => 58

CH#01 CONTROL_CHANGE 64 => 0

CH#01 CONTROL_CHANGE 64 => 127

CH#01 CONTROL_CHANGE 64 => 107

CH#01 CONTROL_CHANGE 64 => 0

CH#01 CONTROL_CHANGE 64 => 127

CH#01 CONTROL_CHANGE 64 => 87

CH#01 CONTROL_CHANGE 64 => 0

CH#01 CONTROL_CHANGE 64 => 127

CH#01 CONTROL_CHANGE 64 => 0

CH#01 CONTROL_CHANGE 64 => 127

CH#01 CONTROL_CHANGE 64 => 0

CH#01 CONTROL_CHANGE 64 => 127

CH#01 CONTROL_CHANGE 64 => 0

CH#01 CONTROL_CHANGE 64 => 127

CH#01 CONTROL_CHANGE 64 => 37

CH#01 CONTROL_CHANGE 64 => 0

[Example of Midi log on USB-B]

CH#01 CONTROL_CHANGE 64 => 127

CH#01 CONTROL_CHANGE 64 => 114

CH#01 CONTROL_CHANGE 64 => 0

CH#01 CONTROL_CHANGE 64 => 127

CH#01 CONTROL_CHANGE 64 => 122

CH#01 CONTROL_CHANGE 64 => 127

CH#01 CONTROL_CHANGE 64 => 0

CH#01 CONTROL_CHANGE 64 => 127

CH#01 CONTROL_CHANGE 64 => 1

CH#01 CONTROL_CHANGE 64 => 0

CH#01 CONTROL_CHANGE 64 => 127

CH#01 CONTROL_CHANGE 64 => 0

CH#01 CONTROL_CHANGE 64 => 127

CH#01 CONTROL_CHANGE 64 => 0

CH#01 CONTROL_CHANGE 64 => 127

CH#01 CONTROL_CHANGE 64 => 10

CH#01 CONTROL_CHANGE 64 => 0

CH#01 CONTROL_CHANGE 64 => 127

CH#01 CONTROL_CHANGE 64 => 0

CH#01 CONTROL_CHANGE 64 => 127

CH#01 CONTROL_CHANGE 64 => 0

CH#01 CONTROL_CHANGE 64 => 127

CH#01 CONTROL_CHANGE 64 => 41

CH#01 CONTROL_CHANGE 64 => 0

CH#01 CONTROL_CHANGE 64 => 127

CH#01 CONTROL_CHANGE 64 => 45

CH#01 CONTROL_CHANGE 64 => 0

CH#01 CONTROL_CHANGE 64 => 127

CH#01 CONTROL_CHANGE 64 => 33

CH#01 CONTROL_CHANGE 64 => 0

I know that a similar but more engine-specific problem has been discussed previously, in a thread on Salamander Piano sfz with Sfizz.

Any ideas? Should I open an issue ticket on GitHub?

Regards

[jofemodo]

I think the problem is developers assumed binary damper action because most damper pedals works in this way. We have to rethink damper action having in mind all possibilities.

Regards

[Aethermind]

Hi @jofemodo,

Actually, I am using only binary action pedals, except on my Roland piano which here is not involved.

I have tried with two different good-quality M-Audio damper pedals, and checked the Midi output log of Cubase (my DAW and Midi router): outgoing CC64 messages are just 127 On / 0 Off. So I don’t think that the issue is pedal-related…

Regards

[Aethermind]

Edit: I now realise that there are two other threads which could be directly or partially related to my reported issue:

@jofemodo

I’m starting to suspect that the MIDI overlay for the Pi5 is not working totally fine. We never had this problems with the Pi4. The zynthian MIDI circuit has not changed, but the Pi5 clock subsystem has changed a lot and a timing issue could cause this kind of behavior

As a matter of fact, I did not experience this unexpected stuck notes behaviour with the same binary damper pedals before, neither on any of my synthesisers or softsynths nor on the Zynthian itself.

Just FYI.

Regards!

[Aethermind]

Hi everybody

Update on the issue of inconsistent behaviour of the damper pedal, on the MIDI controller sending notes to my Oram Stable V5.1.

I seem to have found the reason for the repeated non-binary CC64 messages, and I think it might be of some interest for all users.

I investigated on the web, and discovered with a certain surprise (not having ever encountered the problem across more than three decades with music technology in my life) that:

• Not all sustain pedals sold as binary switches are built and designed accurately enough, as to work actually in this way. Some manufacturers assume, in order to obtain some assembly and components economy, that at the receiving end of the CC64 messages there will be an engine, be it HW or SW, capable of discriminating automatically between a lower and upper CC value, approximating them to 0 and 127 respectively.

• For similar reasons, not every Midi Out circuitry on controller keyboards affords equally reliable Midi timing and filtering. No surprise then, when I discovered that the cheap and sturdy - but until now quite dependable - Thomann’s Swissonic Easykey mounted below my computer desk was sending often but not always strings of repeated and inconsistent CC64 values, both on pedal on and off. Needless to say that the quality keyboard synthesisers in my studio are sending instead accurate and non-redundant 0/127 CC binary messages, processing the same damper pedal.

• In order to keep on using the Swisskey temporarily - albeit I think that it is in order to be replaced soon I’m afraid -, I have programmed two dedicated Midi Transformer filters in Cubase, which I can share as XML presets should there be someone in need of using them, to force values to 0 and 127. Even so, some Zynthian engines cope better than others with repeated CC64 messages (Sfizz for example goes nuts!), because close Midi doubles cannot be deleted in real-time with the Midi processors available in Cubase 13 (I suspect however that something like that might be done in PD…).

So, for the time being the issue is partially solved for me, and I will be using a different controller with Zynthian. I suggest that it could be useful to implement some kind of Midi Input filter, with options for reducing and normalising incoming data.

Thanks, all best regards