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.

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




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.




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

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...

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.

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.


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.

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.

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).