[gmpi] Re: GMPI reqs draft 1 (part 2) for review, paragraph 4.10

From: jeffmcc@xxxxxxxxxx
To: gmpi@xxxxxxxxxxxxx
Date: Mon, 03 Jan 2005 16:13:38 +1300
> There is no memory bandwidth used if there are no accesses
to that memory. A plugin literally should not access the
data if it has not been told that the data has changed.
 No wasted memory bandwidth.

> Can you say any specific reasons why this is a bad idea
(other than the above which I *think* is a non-issue).

Well, as you say, a knob that is not moving (most of them)
is not a problem, even a quick tweak is no big deal.

  The worst case scenario is where you ramp a parameter
gradually over several bars. You're effectivly streaming an
extra audio channel into the plugin.  One second of
automation playback on only one control is 44100 memory
read/writes per second.
  With several parameters automating at once, that's a
significant amount of memory read/write.  That's going to
impact you elsewhere (less tracks available, less plugins
runnning etc).

 Compare that to sending one ramp event ( a few bytes for
the entire ramp).  Even a complex curve (broken into short
ramp segments) dosen't impose much overhead using an
event-based system.


heh, it's a little ironic me arguing against my own
system....

Jeff



>
> On Mon, Jan 03, 2005 at 01:57:43PM +1300,
> > > jeffmcc@xxxxxxxxxx wrote: To play devil's advocate:
> > >
> > > - Assume control rate == sample rate, always.
> > > - Send an event + length when new control data is
> > >  present. Plugins ignore
> > >   their control buffers otherwise.
> >
> > *grin*, you just described SynthEdit.
>
> heh.
>
> >   Yes, that system works fine, but all those buffers are
> > very memory-bandwidth-intensive, a real bottlenect with
> > todays fast CPU cores.
>
> There is no memory bandwidth used if there are no accesses
> to that memory. A plugin literally should not access the
> data if it has not been told that the data has changed.
> No wasted memory bandwidth.
>
> >  Despite using this system myself, I think it's more
> > suitable for a synth's internal communication, where
> > control signals such as ADSR envelopes need very high
> > precision all the time.
>
> Your experience here holds significant weight (for me).
> Can you say any specific reasons why this is a bad idea
> (other than the above which I *think* is a non-issue).
>
> >  A plugin's external controls are more sporadic.  I'm
> > inclined to think audio rate controls are overkill for
> GMPI.
>
> Maybe overkill now, but they are immediately clean, simple
> , and somewhat elegant, once you make them reasonably
> efficient.   At least, to me.  This is all spec fodder,
> but interesting nonetheless.
>
> OBGMPI:  I am working on a final edit - spell check,
> grammar check, etc. Will post a diff as soon as I can.
>
> Tim
>
> ----------------------------------------------------------
> ------------ 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
>

----------------------------------------------------------------------
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
[gmpi] Re: GMPI reqs draft 1 (part 2) for review, paragraph 4.10

Other related posts:
