[gmpi] Re: Req 76,78

  • From: "Didier Dambrin" <didid@xxxxxxxxx>
  • To: <gmpi@xxxxxxxxxxxxx>
  • Date: Sat, 5 Feb 2005 03:21:36 +0100

See it this way, it's like getting timestamped events, except that it's the host that slices the processing for you, and sends the events in-between. And no, personally I don't believe in that host-controlled ramping bs.

This view totally kills any optimisation opportunity for many kind of plugins. In such case we have not other option than to predelay the


come on, how often does FL ask the plugin to render less than 8 samples? It happens.. rarely.



output and thus create artificial latency we could very well live without with a time stamped event list and reasonable buffer size. There are a lot of audio processing algorithm that just can't live with such overhead. Picture this: my main field of work is pro samplers (we do MachFive for MOTU). It is very typical for us to have many hundreds of playing voices at certain points (because we use multi layered sample programs, and some kind of orchestral music need a lot of concurent voices to sound right). In your example I have to manage those many hundreds of voices every 7, 12 or whatever samples. Each voice typically uses 2 or 3 ADSRs, 1 or 2 LFOs, filters, routings, FXs, etc. One can


I can tell you that I never noticed any loss in performance in FL plugins because of this. And we have VST versions of our plugins that perform just the same way in other hosts.

FL's sampler channels will mix 120 stereo voices (poor linear interpolation, though, but it has nothing to do with our problem) for 7% CPU of my AMD64 2400. And they have quite a lot of envelope checks & all.

I hope you realize that some here (not me, though) are using crazy <1ms latencies, and for your plugin that means processing sizes of less than 100 samples.



assume that there is at least 30 function calls per voice and per audio buffer round. Now you can make the calculus. Each time the host asks for a bunch of audio data I have to wake all these functionnalities PER VOICE. And I'm not even talking about low latency IR Based reverbs (not everybody can use the Lake Algo...). Then there is the fun game of SSE and Altivec optims which only work on datas that are alligned (altivec) and sizes that are multiples of at least 16 bytes, depending on the algo and the archi.
So I say, your reasoning may seem ok if you only think about effects, but it's completely wrong when you look at the reality of software instruments.
It strikes me as if you where asking a game to render every frame, 7 pixels at a time: the bigger the batch of rendering, the bigger the opportunity for optimisations there is.



as simple as "just send a command". I'm all in favor of GMPI being a 


yes, it's as simple as 'send a command with a timestamp'

one function call host -> plugin per automation event? are you kidding?


no

most of the time a plugin has.. no automation anyway


----------------------------------------------------------------------
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: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts:

  1. Home
  2. gmpi
  3. Archive
  4. 02-2005