Strange sustain behaviour in Zynthian?

Hi Zynthianers,

I pulled the latest update oram2502.1, put it on my V5.1 kit and after this activated the “Active Midi channel” in the Admin menu, because I like to layer multiple instruments and try out this nice feature - discovered it two days ago. Now it seems that my sustain pedal is randomly recognized. Because of this there are notes not turned off or the sustain pedal is not working.
Then I deactivated the “Active Midi Channel” feature in the admin menu, but nothing changes, hanging notes. And this phenomenon seems to be independent of the instrument you choose.
Then I thought, maybe there is some misconfiguration somewhere. I installed the latest oram2502.01 from scratch on a fresh sd card. After fresh install was done, I activated the “Active Midi Channel” feature again and now hanging notes again. There is only my Korg SV1 connected via Midi-USB to Zynthian, nothing else.
Cleaning up everything does not work either. If I add any instrument, there is this random-sustain thing again. It’s independened from any midi settings. switching between multitimbral, active mode does not change anything. I think I will try a new fresh install from scratch again.

Am I doing something wrong? Is someone able to reproduce this?
Any help is welcome.

I think You did nothing wrong, in my opinion there is a bug somewhere. The same things happen to me also since the last Oram2502 Update. I took a look at the Midi Log. Sustain ON/OFF are listed as MIDI events but not always “executed”. I also recognized that in more cases Sustain OFF is not processed, (that produces hanging notes) in minor cases Sustain ON is not processed.
In the MIDI Log I also saw that pressing the Sustain Pedal sometimes triggers more than one MIDI event, so there may be three lines in a row where the CC64 Value jumps from “127” to “0” to “127” when pressing the pedal. The same things you can see when depressing the pedal, so Values “0” to “127” to “0” may appear. It seems that this behavior was no problem in the past but maybe in the current Oram Version.

Sorry, i can’t reproduce the issue. Could you send me a snapshot that reproduce the issue in a consistent way?

Thanks!

1 Like

Hi jofemodo,

I think I found the cause. Today I connected my simple Akai MPK mini 3 to Zynthian and plugged the sustain pedal into the Akai. There are no problems with sustain messages.
Then I switched back to my Korg SV-1 stage piano and immediately had notes hanging again.
Difference: The Akai MPK mini 3 sends simple sustain CC64 on/off messages. The SV-1 also sends an intermediate step.

Akai MPK mini 3:

Korg SV-1:

Here my simple snapshot for testing, it’s only one chain provided with a simple Dexed Synth.
006-sustain.zss (12.3 KB)

And maybe there are similarities to this issue tracked in git: Issue: Stuck MIDI notes in V5's DIN-5 interface · Issue #1341 · zynthian/zynthian-issue-tracking · GitHub

When using the oram release from October 2024, there seems to be no problem in dealing with “in between sustain CC values”.

It looks like the SV-1 is sending continuous pedal values, compared to the binary on/off from the MPK. I wonder if our pedal handling code is affected by this. I did add some debounce or pedals to help with a noisy pedal that I have so maybe that caused the problem. I will have a look.

1 Like

Hi,

I also have two snap shots
1st one:
You see the CC64 lines, at the end there is a line with value “0” but it was not executed, afterward played notes hang (sustain is still on, and you see the bars on the right top also “on” )
Unfortunately these multiple CC64 lines come random. I tried another pedal, but no change. MIDI Source is a Nord Stage2.

2nd one:
After pushing the pedal another time, all hanging notes go off again
Also two CC64 lines, but both were executed

I belive that my Sustain Pedal has the same behaviour like before, but anyhow Zynthian handles it in a different way since the last update maybe.

I have just measured the original DS-2H sustain pedal from Korg in my workshop. It delivers 4 different values, depending on how hard you press it:

  • 0.2 kOhm (CC64 => 127)
  • 5 kOhm (CC64 => 74)
  • 10 kOhm (CC64 => 38)
  • infinite/released (CC64 =>0)
    Acoustically, this produces slightly different “noises” if you listen carefully. Better piano engines may be able to interpret these intermediate values. This also explains the different CC64 values ​​of the Midi Logger in Zynthian. A typical pressing sustain down and release looks like this:

CH#01 CONTROL_CHANGE 64 => 74
CH#01 CONTROL_CHANGE 64 => 127
CH#01 CONTROL_CHANGE 64 => 74
CH#01 CONTROL_CHANGE 64 => 38
CH#01 CONTROL_CHANGE 64 => 0

I have taken a look at the manual and the editor software, there is no place where you can influence or change this behavior of the sustain pedal. It seems to be built-in.

1 Like

Ooh no …
my second Pedal (it´s a simple momentary switch) behaves even more strange than my 1st Pedal


the value “39” is sent during pressing the button down. “127” at the end of the buttons stroke. In that case, Susatin is ignored as the first value is too low, an dthe second is not executed anymore.
Valu"0" is after releasing the switch. (normal :slight_smile: )

1 Like

In my home setup I don’t use the original Korg DS-2H Pedal. I am using a simple sustain pedal, but the Korg SV-1 Piano always sends these sustain values “in between 0 and 127”, regardless if you have plugged a simple sustain pedal or the special DS-2H.

When you look around, most e-pianos support so called progressive or continuous sustain pedals, like Nord Stage, Korg and also Modartt Pianoteq.

Hi riban, please let me know as soon as you have adjusted the code for the sustain pedal handling. I can test it if you like. Until then, I’ll stick with the oram stable release from last year.

Not seen a sustain pedal with velocity before!

Some pianos support “half damping” to allow more expressive playing. Pianoteq supports continuous pedal control whilst others only support three states; off, half, full. Pianos that support half damping tend to use a pedal with a TRS jack that provides a resistance between two poles with ability to bias with other pole. (I forget which poles but it isn’t what you would initially guess, because it avoids inadverent short of bias to ground via mono jack.) A half pedal may provide three state or continuous variable value but many pianos only support the three states and most only support two (off / full).

I have been working on a Hall effect pedal that gives continuous control that would benfit Pianoteq but that project is on hold (on the floor somewhere…) due to other commitments. One day I will find time (and the project itself) to continue.

I would be happy if the sustain pedal would simply behave like it does in the ORAM October release of 2024, since I can no longer use my setup with Korg SV-1 as a master keyboard due to the note hanging in connection with the current Zynthian SW releases.

@riban , i suspect the cause of this problems could be this commit:

It seems this debounce algorithm can’t work for non binary pedals. What do you think?
Could some of the affected users confirm if the issue vanishes by undoing this commit? (simply disable the debounce lines)

Regards

1 Like

Yes, that was what I was thinking. I think the debounce may be over simplistic and removing any closely timed values.

1 Like

I just did some tests and this debounce will account for most (all) of the reports above.

The first 74 is over 64 so triggers sustain and 127 is irellevant. The next 74 is also over 64 so retriggers sustain and 38 and 0 are probably in the debounce window and are ignored.

@zast’s 39 is below 64 so does not trigger sustain then 127 is probably within debounce windows so is ignored, hence sustain is never triggered.

The debounce should be looking for change of state, not just change of value. I am too busy today to look at this further.

1 Like

Hi riban
Thanks for your work
I also came to this finding :slight_smile:
Is it enough to make a Software Update in webconfig to get this improvement or do I have to do something by hand or so?
Greetings!!

I have written a fix but am not in the lab today to test it. As soon as I am back I will validate the fix, push it to the testing branch and notify you here.

For those with an interest in the innards: The previous debounce code simply filtered out rapid changing values which resulted in earlier values being asserted but not later (and more valid) values. The code I need to test adds an option to debounce toggle controls (disabled by default). When enabled, a MIDI CC value will start a 20ms timer which is replaced by any further CC received within the 20ms debounce period. If no further messages are received, the timer triggers and the CC is asserted to the control. This filters out streams of CC less than 20ms apart and asserts the last received. This adds 20ms latency when enabled. It is only available for toggle controls (like pedal switches).

We need to check that any instrument that supports continuous pedals, e.g. Pianoteq have their pedal controllers configured for continuous and not toggle.

[Edit] I just checked and our Pianoteq integration supports 1/4 pedal steps.

Can I just ask some questions out of pure interest?

Do Midi controllers from major manufacturers not debounce internally somehow? In my uninformed worldview I thought one could rely on external hardware controllers functionality for midi cc messages, only needing debounce mechanisms for some kind of DIY ADC-controls?

Also: Is there a difference between toggle controls and momentary switches? I would be interested if a momentary switch like a sustain pedal must be debounced at all, while a toggle button would be cause multiple triggers if not?

They mostly do but I found that a pedal supplied with a Roland digital piano, plugged into a M-Audio Axiom 61 sustain pedal input was sending jittery CC64 which is why I added the debounce stuff.

For toggle controls we offer the ability to configure the MIDI binding to be momentary or latching. The former sets the control to on/off based on the CC value. The latter toggles between on/off, each time the CC value exceeds 64. This is maybe more susceptable to noise and I hope the new debounce code helps.