[gmpi] Some advice?

[also sent this to the VST plugins list]

Hi,

this is a more or less general question for advice, but I suspect many of you to have dealt with this before, so...

I'm currently trying to set up some abstraction layer for my "inner processing top-level blocks" so that they can easily be adapted to different plugin formats, without having to do much manual code plumbing for each type of API I want to support. I'll use adapter classes for doing the plumbing automatically (well, as much as possible anyway).

So, I ended up with the issues surrounding parameter change synchronization with audio processing.
In VST, a parameter change is just sent through whenever it occurs (also from other threads than the processing thread), and there is no way to sync it with the audio (unless you're mapping incoming MIDI events to parameter changes). In my internal model, I would like to explicitly deal with parameter change synchronization, and I would like to consider parameter changes and incoming MIDI messages both as "incoming events with a timestamp".
So, I have a Process function that looks like this:

virtual void Process(
    const AudioBufferList& inAudioBuffers,
    AudioBufferList& outAudioBuffers,
    const EventBufferList& inEventBuffers,
    EventBufferList& outEventBuffers,
    unsigned long inNumOfSampleFrames) = 0;

The idea is to have all audio and events being processed by this one function, where the events are timestamped relative to the start of the audio buffers and can be taken into account while processing the audio.

Does anyone use such a model? Are there things that might not work reliably this way?

One thought I had about this is the following:
How should the VST setParameter calls best be mapped to this model?
As these come in asynchronously, I guess I'll have to store them in an event buffer as they come in (probably just setting their timestamp to 0 as this info is not available anyway in VST, but keeping the order as they come in). And then at the start of a Process call add the events to the events buffer being processed. Real-time parameter changes coming from the GUI will then only become available the next process call, which may be big on low-profile sound cards that need big audio buffers, but should be fine with reasonably good cards. Same for events coming out of the processor: choppiness on an audio block size grid, if the timestamps of the events can't be used by the receiver (like MIDI devices that receive non-timestamped events and a GUI that is usually totally not synced to the audio stream).

Also, and maybe a bit off-topic for this list, but I know many of you are knowledgeable about that too: how easy do other plugin API's (like AU,RTAS,...) fit in this scheme? Any unrecoverable problems?

Other thoughts/advice?
If you prefer to talk about this off-list, that's fine too of course.

Koen



----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: