|
|
Could you provide an Arodur session or .mid file that causes this? I cannot explain this, nor reproduce it. CC parameter changes are only sent when there is a value change (see ACE MIDI Monitor) MIDI-CC-playback.png (17,406 bytes) |
|
|
My setup is as follows: Ardour 6.9 (flathub, commit 0bdbac43f4bfcdacb69bc5f61d8dbd0ffa01e4ef893553be676877b00147351f), sfizz 1.1.1 (flathub, runtime 21.08, commit a7bc503d34572af978b163d9f6f6fb04c95790622936f06a2fa9b0884e6a1d83), Salamander Grand Piano ( https://github.com/sfzinstruments/SalamanderGrandPiano , commit f974189f4d12c99f4f214aadfb4538faf7e7f54f) New Ardour session, new MIDI track with sfizz, Salamander loaded in sfizz; add an automation lane for controller 64. Simply witching the automation lane from Manual to Play (no need to start playback) causes the track to emit constant low level noise, and for sfizz to show 32-37 voices playing at once. Increasing the the trigger level for the pedal noise from 0 to 1, as here: https://github.com/sfzinstruments/SalamanderGrandPiano/pull/3/files resolves this. Oddly enough for me the ACE MIDI Monitor shows no MIDI messages from the automation lane at all. I am probably using it wrong. |
|
|
could you check what the mode selection for the CC lane (right click on the CC track header) ? |
|
|
On the previous automation track, which I had added through Automation > Processor automation > sfizz > Parameters 65-96 > Controller 64 I see no mode selection. But I have now noticed that there is also Automation > Controllers > 64: Sus Pedal > Channel 1 which shows discrete mode, only has states Off and Play, and **does not have this problem**. Does that mean this is a bug in sfizz? |
|
|
Right click on automation track header. A menu will appear that has "Mode" at the bottom. |
|
|
> Does that mean this is a bug in sfizz? We have too little information, and also some imprecise info on the subject. Could you create a session that produces the problem. save and .zip it up and share it? That would be helpful. Does anyone else also have this issue? Have sfizz authors been able to reduce it? |
|
|
I thought that after my last post the instructions for reproduction were unambiguous, but I have attached a project per your request; also a screenshot which shows that no "Mode" entry appears in the menu for me. no_mode.png (5,963 bytes) |
|
|
I have now debugged this with sfizz and salamander from current git, and I'm extremely certain that it's a bug in sfizz. Ardour does not send repeat messages, and sfizz' behavior is not replicated by other synths that are sustain-pedal aware (e.g. Pianoteq with a piano model that has a loud pedal noise). |
|
|
I also just tested this using an actual sustain pedal. If the pedal is held down, the pedal "noise" (i used an amplifier to hear it more clearly) plays continuously until I release the pedal. |
|
|
Thank you. I will raise the issue with the sfizz developers. Just to help my understanding, if such questions are appropriate here: The Automation > Controllers lane is part of the MIDI data and generates messages in a standardised way, whereas the Automation > Processor automation lane is separate and sends floating point numbers to sfizz via some plugin interface, generating the floating point numbers by linearly interpolating (time, value) pairs and sending an update to sfizz every frame (?) where the floating point value compares unequal to the last one? |
|
|
When the CC lane is in Mode > Discrete there is zero interpolation at all. Ardour simply sends individual CC events, the same ones displayed as control points in the lane display. It sends no data that was not recorded or explicitly drawn for the CC track. When the CC lane is in Mode > Linear, Ardour will interpolate between the points (linear interpolation) and sends a new (potentially interpolated) value periodically. It will not resend the same value, ever. In both cses, no floating point numbers are involved. The CC track display/represents actual CC messages, and Ardour delivers CC messages to the plugin as MIDI data. This is quite different from generalized plugin automation (which is not CC data, and is presented as floating point). I do not know why your version of Ardour does not show the Mode option in that context menu. My impression is that it's not an official Ardour build, which makes it harder to offer support for issues like that. |
|
|
@paul : the label is "sfizz Controller 064" which is a plugin parameter (and hence float). Also note the automation label "Manual" MIDI CC lanes show "Damper Pedal" (depending on MIDNAM) but neither track or plugin label. That also explains why there is "Manual" (and not "Off"). |
|
|
One explanation would be an internal conflict in sfizz. Plugin-parameter (Controller 064) vs. MIDI data CC64. A plugin must only ever expose one, otherwise there can be ambiguities. |
|
|
So this is a plugin parameter automation track and not a MIDI one is that it? In this case, does Ardour send the current parameter value in each block for example? Does the same thing happen if you actually automate the CC64 track? The underlying behavior is that you can have a voice play when receiving a CC message with value in a certain range. This is typically used by piano libraries for sustain pedal noises. Robin is probably onto something however. Since sfizz allows user-defined parameters beyond the actual number of CCs in the midi spec, and with higher-than-7-bit resolution, these are advertised as plugins parameters, and the first 127 are bound to midi in the VST3 plugin, and (should be) marked with `midi:binding` in the LV2 spec. However the latter has proven problematic because if the host doesn't support the `midi:binding` annotation, you have the terrible UX of having your sustain pedal basically do nothing until you manually bind "plugin parameter 64" to "input midi CC 64". If this is the issue, I'll just remove the first 127 parameters from the LV2 until the binding is more common. |
|
|
I've described what happens with the "actual" MIDI CC 64 controller, both via automation in ardour and also when using a physical sustain pedal. When I get a chance, I'll check the sfizz "exported" Controller064 parameter. |
|
|
> In this case, does Ardour send the current parameter value in each block for example? In case of VST3 automation playback: Yes, implicit curve points at the end of each cycle are always queued explicitly. This applied to the dashed circles in the diagram: https://developer.steinberg.help/display/VST/Parameters+and+Automation#ParametersandAutomation-AutomationPlayback This is something on our long list of VST3 things to tweak. Since one can do arbitrary locations or change the loop-point while looping, the only sane way to determine if implicit points have to be transmitted is compare the value with a the most recently sent value (and unset it if automation playback mode changed). Since a plugin will have to do this anyway internally in order to dezipper control parameters, I opted to not implement the discrimination logic in the host, assuming no harm is done my making the curve explicit. |
|
|
A somewhat off topic observation here is that Ardour seems to continually pass arguments even while playback is paused. In general I have noticed that Ardour uses more resources than necessary while "idle". I understand that things could happen even then, and that because Ardour does not know what plugins are up to it may be difficult to determine just when nothing is happening. So maybe this issue cannot be solved completely, but any improvements would be nice. Then one does not have to worry so much about leaving Ardour running in the background, especially on a mobile device. One example I noticed is that simply adding some MIDI tracks without any plugins seems to increase idle resource usage significantly, and I see absolutely no reason for that. I can open a new issue about idle resource usage if you want. |
|
|
> One example I noticed is that simply adding some MIDI tracks without any plugins seems to increase idle resource usage significantly, and I see absolutely no reason for that. That should not be the case, at least there should not be any significant DSP load increase after the first track. But yes, by design Ardour's mixer is never idle and constantly processes, like a hardware mixer would. One benefit of that is that the load is constant. > A somewhat off topic observation here is that Ardour seems to continually pass arguments even while playback is paused. Not arguments, only port parameters. The MIDI event-list is sparse and those are discrete events. The plugin should really use MIDI CCs and not expose a control port for those. I know VST3 makes this complicated and many plugin-devs despise Steinberg's implementation, but at least conceptually it's sound. |
|
|
> I opted to not implement the discrimination logic in the host, assuming no harm is done my making the curve explicit Another fix would be for sfizz to disregard controller events that match the current controller state. I'll check if this is indeed what happens in other SFZ implementations and do so if necessary. > The plugin should really use MIDI CCs and not expose a control port for those. Technically it's an LV2 parameter :) > I know VST3 makes this complicated and many plugin-devs despise Steinberg's implementation, but at least conceptually it's sound. I've come to like it because it avoid such headaches to be honest. If anything, I'd like to be able to capture all channels at once for a given controller. Anyway I think we can agree the fixes are probably more on sfizz's side so I'll get back to you guys if needed, thanks for your time! |
|
|
> One benefit of that is that the load is constant. That may be true for Ardour itself, but for some popular plugins at least it appears to be false. So I do not think one can reliably judge if the hardware can handle a particular setup just by looking at idle usage, in which case I see only two direct user-facing benefits to any significant idle usage at all: potentially better latency and less overhead under load. Of course users may indirectly benefit from a simpler implementation in other ways. |
|
|
> Technically it's an LV2 parameter :) In this case Ardour will *not* repeat the parameter change. This is only done for VST3, because the spec demands the value to be sent at the end of each cycle so a plugin can internally interpolate. |
|
|
> but for some popular plugins at least it appears to be false. sadly, yes. This is where pro-audio plugin vendors go to great length to make difference. When live on stage, for FOH mixes, or during a recording-session with a client reliability is key. > I see only two direct user-facing benefits to any significant idle usage at all: potentially better latency and less overhead under load. Latency is not affected by this at all. -- Well, if the load is lower, you could use a smaller block-size. But as soon as the system is not idle anymore that is no longer an option. In case of Ardour, the "overhead" is only to do metering and apply gain (trim and fader). There is dedicated asm code for both of those operations, and one can easily use 1000 tracks without significant DSP load (unless you use the debug version, not an optimized build, which might explain what you're seeing). Anyway, this is not something that can be changed. This was an early design decision that is deeply ingrained in Ardour's processing engine. |
|
|
> unless you use the debug version, not an optimized build, which might explain what you're seeing I have just checked. The relevant flags that I could see in the Waf output were `-O3 -g -DNDEBUG`, so I am using an optimised build. The DSP load as reported by Ardour indeed does not increase, but adding 8 MIDI tracks to an empty project roughly doubles the CPU use of Ardour reported by `top` (the value is fluctuating in both cases), independently of whether the Ardour windows are visible or not. |
- Anonymous
