Inappropriate repetition of piano pedal noise on automation
Closed this issue · 28 comments
Setup:
- Ardour 6.9,
- Salamander Grand Piano from sfzinstruments, commit f974189f4d12c99f4f214aadfb4538faf7e7f54f
When the sustain pedal (channel 64) is automated via Automation > Processor automation in Ardour, then the pedal noise sounds repeatedly (up to 37 voices playing at once on my machine) when the pedal is fully depressed or released, even if no playback is happening. I have raised the issue with the Ardour developers and they say it is most likely a bug in sfizz. Refer to the Ardour bug report for a bit more information, and sfzinstruments/SalamanderGrandPiano#3 for a possibly inappropriate workaround.
Which sfizz version do you have? If you're not on the latest please try it, I've corrected many such bugs recently (not to say all are gone 😄 ).
In general yes, Ardour has nothing to do with this kind of issues.
I'm on 1.1.1
Is that what you mean by latest, or do you mean HEAD?
Hi,
I think it's me to blame.
I didn't change the original group/off_by assignment. It should be set to one group with polyphony=1
I'll fix that soon when I got time, maybe tomorrow.
Is that what you mean by latest, or do you mean HEAD?
Should be fine, I'll test tonight.
I just check the Salamander piano, in sfizz version that I got last week.
The pedal noise works fine here. It only has 1 voice polyphony, same as in sforzando.
So, I guess I''m not to blame, neither sfizz I think.
Something maybe a problem in your setup?
And if you use Half-pedalling sustain, maybe that cause the problem?
@kinwie please reference the Ardour bug report. The issue seems reproducible, and appears only on automation of the plugin parameter that sfizz exposes for the sustain pedal, not sustain pedal MIDI messages.
From the Ardour discussion the problem in fact seems unrelated to the SFZ file, so I'll take over :)
Ahh yeah, I just read that Ardour link.
Seems like something VST3 thing with the exposed parameters problem.
If relevant, for example, sforzando not exposing it's parameters to the host, both VST2 and RTAS/AAX that I use.
Parameters automation done with MIDI CC only.
Most Sampler synths that I know also the same (Kontakt, Structure, SampleTank, etc). only exposing its player-level parameters to the host, but not the instrument-level parameters. Sustain pedal usually automated with MIDI CC, not as plugin's parameter. Seems like VST3 exposed it as plugin's parameter?
Anyway, I hope @paulfd don't mind with another bug :))
Anyway, I hope @paulfd don't mind with another bug :))
I have to admit I was happy to clear the bugs last WE and now I have new ones, but what can you do... 😄
But yes it's something like this apparently. However, VST3 allows to publish parameters and indicate to the host that they should be midi-bound by default, which is what we want actually. This way you have high-resolution automation and good user experience.
This way you have high-resolution automation and good user experience.
I do not quite understand how this works. If the channel is bound to MIDI, will the parameter not be effectively limited to the integer range [0..127] anyway?
Not necessarily no. Since you have updated MIDI specifications with high-resolution, the goal is to support "arbitrary" precision on CC inputs (as in velocity, and everything). Internally in sfizz all such parameters are in fact floats, and you have high-precision APIs (e.g. hd_cc, hd_note_on, etc) to call on them. Lower precision APIs actually call the high-precision APIs.
To enable a transition towards this, VST3 chose to not forward MIDI controller messages to plugins directly. Basically, you have to register a full-precision parameter (say "CC001") and use a VST3 API callback to inform the host that you wish to receive MIDI CC 001 messages on the parameter named "CC001". Now, the host is responsible to translate the MIDI CC messages to parameter changes. You can think of it as an automated "MIDI learn". The good part of this design is that if the MIDI CC message does not come from a controller, but for example from a user-drawn automation curve, the host can send high-resolution floats to the plugin as it wishes. If the MIDI CC message does indeed come from a controller or a MIDI file, the host knows it and is responsible for the translation.
LV2 doesn't support such behavior by default. An extension was proposed to do so, except it did not get much traction yet. That said, I'm free to take it into my own hands and propose a patch to Ardour to do so, which would definitely help it gain some coverage.
I still need to find some time to test and debug this. If it is indeed the problem, we'll find a solution.
Thank you for the explanation. So typically, once the parameter is actually MIDI-bound, the host application would allow a higher resolution only if it supports one of those updated MIDI specifications. After all it should also save the data as part of the MIDI track.
My own strong suspicion is indeed also that Ardour sends frequent updates with the same value on the automation track, and that some misunderstandings in the conversation at the Ardour bug tracker led to this being wrongly denied at first. I have not read the source or confirmed this in another way, though.
Something to potentially keep in mind here: if the host does support higher resolutions, then even if it does not send repeat messages with the same value, the pedal noise could be triggered repeatedly by several high resolution messages that fall into the range that Salamander Grand Piano specifies in 7-bit precision.
So typically, once the parameter is actually MIDI-bound, the host application would allow a higher resolution only if it supports one of those updated MIDI specifications. After all it should also save the data as part of the MIDI track.
Yes or some internal automation curve. 7-bit values in MIDI are an exchange standard, internally nothing forces you to use 7 bits to represent a velocity or a CC value.
the pedal noise could be triggered repeatedly by several high resolution messages that fall into the range that Salamander Grand Piano specifies in 7-bit precision.
I have yet to test but it's probably what happens.
My own strong suspicion is indeed also that Ardour sends frequent updates with the same value on the automation track, and that some misunderstandings in the conversation at the Ardour bug tracker led to this being wrongly denied at first.
It's OK I'll sort this out with Robin and Paul. If anything and if sforzando/sfz.dll has the same behavior, a potential fix on sfizz's side would be to ignore a new CC value if it's the same as the last one.
I've read from some great devs that publishing a lot of parameters in VST3 could consume some amount of unnecassary CPU power. Not sure if that has impact on this kind of case, but just a note for Paulfd to consider.
Just because of quirky MIDi support in vst3, they said.
Maybe, but usually we only publish as much as necessary.
Would you mind trying #1054? There would be no 064 parameter anymore, only MIDI by default. However, you can configure it with SFIZZ_LV2_PSA and recover the previous parameters, in which case it wouldn't respond to midi CC at all.
Also note that in both ARIA and sfizz, you can have start_locc1=0 start_hicc1=0 and the thing will trigger only on cc 0 (although for high-resolution CC, it will still trigger for any value between 0 and 0.0078..., which leads me to believe that Sforzando did the same thing we did with the high-res/low-res matching). So you will still need to have some polyphony=... control for CC triggers, which are ill-defined anyway.
Thank you for you work. I have tested #1054. As the LV2 parameter is gone, so is the main problem. There is a small issue in that the pedal noise triggers at the beginning of a track, with MIDI automation starting at level 0. But this may be an issue in the sfz file?
Setting SFIZZ_LV2_PSA=ON, and reusing the build directory, the expected files were rebuilt, but the behaviour of the plugin did not change at all. There was still no parameter 64 listed under processor automation in Ardour. Apologies if this is just an artefact of my being too lazy to rebuild from scratch, or of a failure to clear some sort of plugin cache in Ardour.
it will still trigger for any value between 0 and 0.0078 [...] So you will still need to have some
polyphony=
I do not really know how this works, but it seems to me that the choice may now be for the pedal noise to trigger multiple times on highly resolved movement starting at 0, or for multiple complete movements of the pedal in a short time frame to trigger the noise only once. Both of those seem wrong.
Edit: I have rebuilt the plugin from scratch and I still do not see LV2 plugin parameters below 128 in Ardour.
On a side note, I realized working on this is that this idea of CC triggers is terribly inadequate when automation comes into play... MIDI CCs are discrete in essence, but an automation lane is usually a continuous function for most hosts, which leads to our current conundrum. This is true for both VST3 and LV2 by the way...
There is a small issue in that the pedal noise triggers at the beginning of a track, with MIDI automation starting at level 0.
If you send a CC message with a 0 value then yes the voice triggers.
Edit: I have rebuilt the plugin from scratch and I still do not see LV2 plugin parameters below 128 in Ardour.
You can only access these though midi if plugin-side automation is active. Those parameters appear if PSA is disabled, and they're marked as midi:binding so that hosts that support this functionality (to my knowledge only Carla does) automatically binds midi CCs to the parameters. If not, you'd need to bind them manually.
the choice may now be for the pedal noise to trigger multiple times on highly resolved movement starting at 0
It always was like this, and it is like this for ARIA too.
multiple complete movements of the pedal in a short time frame to trigger the noise only once.
With polyphony=1 that is true, but that's mostly an artefact of the idea of "starting a note on a CC range" which is somewhat contrived.
@kinwie what is really the absolute standard way of doing a pedal noise properly in SFZ?
@kinwie what is really the absolute standard way of doing a pedal noise properly in SFZ?
This question should goes to Rene, hahh! Anyway, for my opinion, the current way in SFZ is the ideal one. I can't think of any other method yet. The use of start_locc / start_hicc + lokey/hikey=-1 is mimic'ing well the mechanism of piano-pedal noise triggering, imho, since the noise samples need to be triggered by foot, not hand.
I think the problem is the issue with the sustain-pedal type and the MIDI data. Afaik, there two :
- Common sustain pedal which act just as on/off (midi value 0 or 127)
- Half-pedaling sustain pedal, which sent a continuous midi value from 0 to 127
There won't be much issue with the common sustain pedal. But likely, most issues are with the half-pedaling type. (I remember Jeff Learman also reported one to me for the Maestro Piano as he used a half-pedaling sustain type). I just checked some piano midi recording I made with a pianist friend in the past, and yeah I saw that two type of CC 64 data in the tracks. One is just on/off and another one is a little bit continuous.
I think the best way at the moment is to optimizing the opcode programming in the sfz. I'll update Salamander piano noise in this short and see if it will be less problematic (as I said earlier, I didn't change the original opcodes of the pedal noise).
Couple weeks ago, I tested Naked Drums (in sforzando) with a Roland TD e-drums and the Polyphonic Aftertouch cymbal choke works just fine. It use the same trick as piano noise triggering in SFZ. So, who knows adding some more opcode can make it better.
There is a small issue in that the pedal noise triggers at the beginning of a track, with MIDI automation starting at level 0. But this may be an issue in the sfz file?
I think it isn't the sfz file. It's a normal case, if your piano midi track has the sustain pedal CC 64 automation from beginning of the track.
If you want to remove that noise, you can just delete the automation dot at the start in the automation lane, or by opening MIDI Event List and delete CC 64 entry at the start position, so the CC 64 is at 'neutral' state in the beginning of the track.
If you play the piano with MIDI keyboard controller, you won't experience such issue, right? The pedal noise only will sound when you press or release the pedal.
I think it isn't the sfz file. It's a normal case, if your piano midi track has the sustain pedal CC 64 automation from beginning of the track.
Alright, sorry. I thought starting at 0 was neutral, but I understand now that one can omit an initial value. Thank you both for clearing that up. I do not have a hardware sustain pedal, so I had entered the values using the automation lane editor of Ardour.
Meanwhile, I just updated the Salamander pedal that hope it'll be less problematic. If you don't want to re-download it from sfzinstruments.github repo, then you can just copy/paste and replace with this script into pedal.txt in Data folder :
master_label=pedalAction
lokey=-1
hikey=-1
group=1
polyphony=1
off_time=0.1
<group>
group_label=pedalD
volume=-20
on_locc64=127
on_hicc64=127
locc64=127
hicc64=127
<region> region_label=1 lorand=0 hirand=0.5 sample=pedalD1.$EXT
<region> region_label=2 lorand=0.5 hirand=1 sample=pedalD2.$EXT
<group>
group_label=pedalU
volume=-19
on_locc64=0
on_hicc64=0
locc64=0
hicc64=0
<region> region_label=1 lorand=0 hirand=0.5 sample=pedalU1.$EXT
<region> region_label=2 lorand=0.5 hirand=1 sample=pedalU2.$EXT
There won't be much issue with the common sustain pedal. But likely, most issues are with the half-pedaling type. (I remember Jeff Learman also reported one to me for the Maestro Piano as he used a half-pedaling sustain type). I just checked some piano midi recording I made with a pianist friend in the past, and yeah I saw that two type of CC 64 data in the tracks. One is just on/off and another one is a little bit continuous.
The thing that doesn't work really is automation lanes. For example take Sforzando VST3, put it in a Reaper track on with some file with the following sfz file
<region> sample=closedhat.wav hikey=-1 start_locc1=0 start_hicc1=0
Activate the automation track number 1 by clicking on the Trim button and select the CC001.
The voice will play infinitely, because the host sends the value of the automation in each callback. Same with Ardour.
Obviously you need a sample named closedhat.wav :)
The voice will play infinitely, because the host sends the value of the automation in each callback. Same with Ardour.
You mean it played infinitely even the playback is stop? Or I don't understand how it works with those 2 DAWs.
With your example above I can have a proper playback with my daw, here's a screenshot :
I draw dots in beat 2 and 4 of two bars (in that red box) so when I playback from start, beat 1 doesn't trigger the closedhat, which is correct. You can also see the MIDI Even List, that first CC 1 start at bar 1, beat 2.
The first dot in the automation lane (bar 1, beat 1) is the default dot but not automated dot so it doesn't have data in the MIDI even List.
I don't experienced the infinite playback sound like you said, or maybe I get it wrong?
<region> sample=closedhat.wav hikey=-1 start_locc1=0 start_hicc1=0
I write up again for this lokey/hikey=-1 behavior to disabling key mapping :
- sfz.dll : Need both
lokey=-1andhikey=-1 - DropZone & DimPro :
lokey=-1alone can do it, buthikey=-1alone won't - Rapture : The opposite of DZ and DP,
hikey=-1alone can, butlokey=-1alone can't - sforzando : Either one present will do it
- Now, sfizz behave like Rapture
I have no suggestion for this :p as I always put both lokey/hikey=-1, but at least some detailed info might be useful for you