Need advice for debugging plugin

[AdmiralQuality]

there are hosts that do other wacko (you might even say "fruity") things like changing the sampleFrames size in successive calls to processReplacing.

Variable block size is, like, the least wacko behavior in any host. That's why it's a parameter to process/processReplacing() instead of a parameter to resume().

Right. But if they're daring to change block size, are they also checking the deltaFrames of the pending events to make sure that they don't overshoot the next block? (Not that that's technically illegal, but I bet you'll cause a bunch of instruments to break if you do that in a host.)

Also, block size often has audible artifacts in many plug-ins. (In particular, the update rate for automation.) So to change it on the fly is, in my opinion, not a great idea.

Unless, of course, they're matching the block size to the actual varying number of samples between recorded automation events.

Sure, but automation is performed into the GUI thread, so there isn't sample-accurate timing in that data. And usually it's smoothed into some kind of envelope by the host rather than being a sample-for-sample, or frame-for-frame (either video or audio, take your pick!) stream of discreet values, evenly spaced in time.

This is part of why I like the idea of 1 sample buffers. I'd also like to see no conceptual difference between automation and an audio signal. Then you could, say, build modular synths and effects out of plug-ins from different developers.

Maybe someday.

[martin_l]

OK, found a minute to get back to this discussion...

That should be a fairly rare case as well. Really, it's the users' fault if they're sending MIDI and automation messages to the same control at the same time. If the control jumps around like crazy, that's exactly what they've asked it to do. But the MIDI will usually "win" because it will usually have a deltaFrames value. Where automation has no timestamp at all, other than do it as soon as possible.

Well, I am not sure whether it really is such a rare case. Does that not always happen if one uses MIDI Learn?

Imagine I record a filter sweep (assume that I use a certain MIDI CC for controlling the fader). The host will probably record the MIDI events, as well as the automation from the corresponding fader. Should one, in such a case, always filter out the MIDI CC for recording (within the host)?

To be honest, I am still not quite sure how to handle this situation within the plugin.

The really smart way to handle this would be to decrement the deltaFrames value for every queue element at every sample. When the count reaches zero, the event fires. Then the events could easily overlap into the next buffer.

This might sound crazy, but there are some crazy hosts out there. I'm not sure offhand if it ever happens, but I wouldn't be surprised as there are hosts that do other wacko (you might even say "fruity") things like changing the sampleFrames size in successive calls to processReplacing.

What I am doing at the moment is that I create audio buffers for the parameters before the actual synth engine is called. When I am processing the host's event queue, I create events in private event queues. Those are processed at the beginning of processReplacing, and there I create audio buffers which represent the parameter changes. Some of the parameters (such as filter cutoff, vca levels, etc. are smoothed by ramping linearly to the new value. This is still a temporary solution, as the ramping time depends on the deltaFrame and always starts at deltaFrame=0. I just hope, that those effects will not really be audible, as the parameter changes should appear on a much longer timescale anyway, and I only try to avoid sudden jumps, which could lead to clicks.



Cheers,
Martin

[martin_l]

This is part of why I like the idea of 1 sample buffers. I'd also like to see no conceptual difference between automation and an audio signal. Then you could, say, build modular synths and effects out of plug-ins from different developers.

Maybe someday.

I am not so sure whether a 1 sample buffer would be so great. I guess it would create a huge overhead by all the function calls which would occur at every sample. It is definitely more efficient to have larger buffers. Also some of the optimization using SSE instructions would be out of the window, since you cant vectorize the loops anymore.

I rather would like to see parameters treated as audio rate buffers, which should include a 'sleep/awake' status, so that I know whether I have to process them, or not. In case they are asleep, the buffer should still be filled with the constant values, so that plugins which don't listen to the sleep/awake, will still get a valid buffer.

Anyway, that's basically how I treat parameters at the stage of the synth engine anyway, only that I first gave to generate these buffers from the events.


Cheers,
Martin



P.S. I should add that I have not yet looked sufficiently into the VST3 standard, whether this is not already happening...

[AdmiralQuality]

OK, found a minute to get back to this discussion...

That should be a fairly rare case as well. Really, it's the users' fault if they're sending MIDI and automation messages to the same control at the same time. If the control jumps around like crazy, that's exactly what they've asked it to do. But the MIDI will usually "win" because it will usually have a deltaFrames value. Where automation has no timestamp at all, other than do it as soon as possible.

Well, I am not sure whether it really is such a rare case. Does that not always happen if one uses MIDI Learn?

I started out making my synth convert MIDI actions into automation. I thought it would be cool and provide options. I very quickly decided to take this feature out as it created the obvious conflict. I'd recommend against it. Any motion of a knob from MIDI should always be controlled by MIDI, not converted to automation. (Because the MIDI will still be there, right?) So don't call setParameterAutomated when you process your MIDI events, just call regular setParameter. Only the GUI should call setParameterAutomated.

Imagine I record a filter sweep (assume that I use a certain MIDI CC for controlling the fader). The host will probably record the MIDI events, as well as the automation from the corresponding fader. Should one, in such a case, always filter out the MIDI CC for recording (within the host)?

To be honest, I am still not quite sure how to handle this situation within the plugin.

Yep, don't. Do handle both MIDI and automations. But your MIDI events shouldn't be converted to automation. While ultimately they do the same thing, they're two different ways of requesting it.

The really smart way to handle this would be to decrement the deltaFrames value for every queue element at every sample. When the count reaches zero, the event fires. Then the events could easily overlap into the next buffer.

This might sound crazy, but there are some crazy hosts out there. I'm not sure offhand if it ever happens, but I wouldn't be surprised as there are hosts that do other wacko (you might even say "fruity") things like changing the sampleFrames size in successive calls to processReplacing.

What I am doing at the moment is that I create audio buffers for the parameters before the actual synth engine is called. When I am processing the host's event queue, I create events in private event queues. Those are processed at the beginning of processReplacing, and there I create audio buffers which represent the parameter changes. Some of the parameters (such as filter cutoff, vca levels, etc. are smoothed by ramping linearly to the new value. This is still a temporary solution, as the ramping time depends on the deltaFrame and always starts at deltaFrame=0. I just hope, that those effects will not really be audible, as the parameter changes should appear on a much longer timescale anyway, and I only try to avoid sudden jumps, which could lead to clicks.



Cheers,
Martin

Ah, cool. Like I said, automation really should just be audio streams anyway. Nice that you treat it that way internally.

BTW, if you smooth out the "zipper noise" you'll be doing a better job than an actual JX-8P, which as you know is chunky as hell in its parameter updates.

And speaking of audible artifacts of block size, you're describing building one above. You really shouldn't ever treat the start or end of a block as significant. If you're smoothing values, do it over some number of samples, regardless of where the sample block starts or ends. I'd also recommend obeying the deltaFrames values (which you'll only really get for MIDI events anyway). If nothing else, they're to make sure the note-on(s) happen on the correct sample.

[AdmiralQuality]

P.S. I should add that I have not yet looked sufficiently into the VST3 standard, whether this is not already happening...

So far I consider it not worth the effort and introduction of new bugs to adopt. VST 2.4 is still the de facto standard.

[Chris Walton]

Sure, but automation is performed into the GUI thread, so there isn't sample-accurate timing in that data. And usually it's smoothed into some kind of envelope by the host rather than being a sample-for-sample, or frame-for-frame (either video or audio, take your pick!) stream of discreet values, evenly spaced in time.

I'm not sure how it is now, and I'm not completely sure on the details (ttc? reflex? could you fill in?), but from what I remember from FL 7:

The deltaFrames value is always 0, and instead FL chops it all up into the various different sampleFrames-chunks. Smooth automation curve updates are sent once a certain threshold of change has been registered, to prevent sending a continuous stream of process calls with sampleFrames=1.

I actually find the FL way to be quite elegant, considering the interface that VST 2.x provides. Internally, I've done it the same way - the actual call to the processing logic is split up and called at deltaFrames=0 boundaries (so, check how many frames until the next event, take the smaller value of that and remaining sampleFrames, and call the processing logic for that many samples).