All mechanical switches bounce, it’s just at a rate perceptible to micro computers but not to human beings. Ask Hammond organs who desperately devoted decades to try to get rid of the clicks on their organs that were designed for the sanctity of a church. Nowadays they have click on a volume control. . .
If you want a bounce-less device look to hall effect sensors and magnets which address this remarkably well.
I’ve opened a fair few passive volume pedals and effect switches and have never seen any de-bounce effort outside of the occasional capacitor and it doesn’t take much reading round here to discover what a contentious subject that can be. It’s particularly a problem with encoder switches as these deal in ( relatively) short pulses and edge detect, but it’s been a problem since the early days and many mechanisms exist to address it, it’s just how many machine cycles you wish to loose to it. Active devices ( those with a battery & or PSU) that have any kind of circuitry inside will have some form of debounce, but since the sustain pedals and volume pedals are generally sold as accessories they are kept as cheap and simple as possible.
There are no difference in bounce performance between toggle switches and momentary. They both need some approach to prevent each positive click turning into a succession of bouncy ons and offs before they settle.
I current don’t have enough time as to read all the entries in this thread, but from some cursory reading it seems that it may touch on the issue that I have experienced too with binary sustain pedals recently
It is unclear to me if the aim of a software compensation of the signal debouncing is to improve the behaviour in Zynthian of continuous/stepped pedals, or to solve and clean up the response to on/off toggles like binary damper pedals.
Maybe it makes sense to differentiate between pedals that are directly routed to instrument plugins, kind of passthrough, and pedal signals that are midi learned by Zynthian.
At the weekend I think I will have some time to do some tests. Please tell me how to do this if it makes sense. I never changed the software repository to testing or staging, only have been working with stable until now.
I have pushed a fix for sustain pedal to testing (vangelis). This supports partial pedalling and offers an optional (disabled by default) debounce for toggle controls which may be enabled in the control options menu (bold press a controller). When debounce is enabled, only the last CC is sent from a stream that has less than 20ms between each CC value. This should rarely be required but you may find a MIDI controller which needs it. (I am looking at you, M-Audio!)
Please test to see if this resolves your issues.
It is recommended to use a seperate boot medium for testing, e.g. a spare uSD card. This is to protect your main / production environment from being impacted by changes in the testing environment, e.g. we may change the snapshot format which you may then not be able to resuse in stable. As a minimum, use webconf to backup your data so that you can restore it if things go wrong.
To switch to testing:
Within webconf, navigate to SOFTWARE->Version.
From the dropdown, select “testing (vangelis)” .
Click “Save”.
This should show a banner with a link to “update the software”. Click this or navigate to SOFTWARE->Update.
Click “Update Software” button.
After update completes, you may wish to reboot. It should be automatically detected and notified if a restart is required but it may make you feel more comfortable to prove the system boots into the testing environment at this point.
Going back to stable is a similar process, selecting, “stable (oram 2502.1)” (or whatever the current stable version is at the time) in the version dropdown.
It is fairly easy to switch between stable, staging and testing and most of the time it is painless but, as mentioned above, testing may be significantly different to stable which may cause some issues for normal users.
Hello, now I updated to testing/vangelis and checked the sustain pedal behaviour with my Korg SV-1. It seems to be as before in the Oram October release in 2024.
But there is something still not working as expected, when using the “active midi channel” feature. Here my setup:
When chain 1 is the active chain, then you can play with sustain pedal as expected. Sustain pedal is also working with Surge XT, chain 2.
But when you move to chain 2 (chain 2 selected), then chain 1 (Pianoteq) does not receive the sustain pedal message.
I think this behaviour is the same in Oram October release 2024.
I am doing more work on this which is almost complete but I have a question about desired functionality.
There is a feature called, “Active Chain Mode” (previous know as “Stage Mode”). Note on/off messages are sent to the currently selected chain. This gives a really versatile performance mode where you can switch between instruments by simply selecting another chain in the mixer view. In this mode, a held or sustained note will be stopped when the corresponding key or pedal is released, even after switching chain. This is of course desired behaviour.
My question relates to asserting a held pedal whilst switching chains. The previous / current behaviour is assert the pedal, e.g. sustain to the newly selected chain but consider this workflow:
Press sustain pedal.
Play a chord.
Select another chain.
Play a melody.
The melody would also have sustain applied which may not be desirable.
Thanks @riban for taking note of possible preferences about this. In the best of worlds, and from my standpoint, it would be desirable that the formerly played chain retains the sustain command, while the newly activated one (in active mode) works in no-sustain mode, until the next CC64 command is sent to that chain. This, in your plausible scenario, would avoid clouding the lead with unwanted note trails, while the background chord is held from the previous chain/midi instrument.
This should not be the behaviour but a regression may have been introduced. The dev branch aims to resolve such issues.
I will change the default behaviour to not reassert pedal on switching active chain. If there is a use case identified where the old behaviour is desirable, we could add an option to enable it (but let’s not add extra options unless required).
Sorry, by “current” behaviour I actually mean behaviour at a given time in the past I witnessed it. It may also include switching to the master chain. I should maybe carefully evaluate my words when based on pure remembering.
Switching to a non-MIDI chain leaves the active chain for MIDI events unchanged. This is a behaviour that can confuse users (including me!). You have no indication of what is the current chain consuming active mode MIDI input. This may benefit from some extra indication of the “Active MIDI chain” seperate to the “Active chain”. Maybe the MIDI indication (musical notes on legend strip) could change apperance (colour, shape, etc.) when a chain become the active MIDI chain. I have raised a ticket for this enhancement.
That sounds gorgeous. For the novice (in zynth and endlish language) I am it seems to mean: When switching to a non-midi chain (like the master chain or an audio chain), the focus on the last choosen active midi chain is retained and will receive midi events?
May I asked this: After recent fixes (not sure if this is related) the pedals were taken from the default sfz engine controller screen. Were I did add them in custom controller yml scripts, the onscreen pedal controls do not react to cc64 changes.
The pedal function itself works. Is this behavior intended?
The pedal handling has been refactored in testing (vangelis). Controllers for pedals have been removed and you don’t need to bind MIDI CC manually. CC 64 (sustain), 66 (sostenuto), 67 (soft) and 69 (hold 2) are configured as pass-through by default so will act natively on synth engines. This can be changed in CC menu. In active mode, pedal press is remembered so that the release works even if is the active chain has changed. There is an indication of each pedal state for each chain in the mixer view.
We plan to deploy this to staging (Oram) and then to stable soon so please, test thoroughly and report any issues.
I really hope this resolves everyone’s issues with pedals. I also fixed a stuck note issue that manifested in active MIDI channel mode (which replaced clone functionality).
Wow, @riban, you’ve done a great job! Now you can group layered sounds and seamlessly switch between them live, including the sustain pedal.
I’ve just updated to the latest version and tried it out a bit with this setup:
