[gmpi] Re: Requirements sections 3.4 and 3.5
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sun, 30 Nov 2003 14:25:44 -0800
On Tue, Nov 25, 2003 at 09:33:00AM +0000, Steve Harris wrote:
> On Mon, Nov 24, 2003 at 09:27:21 -0800, Tim Hockin wrote:
> > What you're missing (though you like to focus on it) is the end user
> > experience. As an end user, I don't have 15 GHz available. I want to
> > listen to my stuff realtime. So I lower the quality on these monster
> > plugins. Then I render. Oops! I forgot to turn up the quality on ALL my
> > plugins again. More than 1 or 2 of those plugins, and it's VERY
> > frustrating.
> >
> > Standardizing it allows the host to know which plugins conform, and lets it
> > handle that automagically.
>
> There are big problems with automatic handling - If i'd written a plugin a
> few years back and you scaled back the quality control it would most likly
> drop back to using a table for its sin() calculations etc., well on a
> modern machine that might well be slower than just running the sin()
> approximation (this might well reverse again in the future). So you could
> end up with a situation where the host notices its runing out of cpu, scales
> back the quality and the cpu load goes up.
This is generally true. Upgrading to a faster CPU may actually slow down
older plugins which use the table, for example.
However, this has made me start to rethink the REAL requirement.
I think the REAL requirement is that a plugin that cares should be notified
as to whether it is running realtime or offline.
If a plugin is a CPU pig, it can implement a quality knob itself (many
plugins do this today). That quality knob can affect the plugin when it is
playing in realtime. When the plugin is running offline, it really can take
more time.
But this isn't really all true. Perhaps the user wants to do a quick
render, and NOT make plugins run at full quality?
Perhaps then, the requirement is more along the lines of:
GMPI must provide information about the mode in which the graph is
operating (realtime or offline) to plugins which request that
information.
Then the host can provide a draft/final toggle at rendering. Setting it to
"draft" will run plugins at realtime quality (they'll think they are
realtime). Setting it to "final" will tell plugins they are running offline
and can chew up CPU.
Or maybe it's better to have "realtime vs draft vs final" level. But why
stop there with three levels. Why not 10, or 100. Back to square 1.
I think the minimum support is to provide a "draft vs final" indicator.
Plugins that need to scale back quality can do it themselves, as they
currently do (some do low-med-hi, some do 1-100%, some do 1-10). When they
are set to draft mode, they run in their self-adjusted state. When they run
in final mode, they run at full tilt. Plugins that don't care do not have
to do anything at all.
Does it sound more reasonable?
----------------------------------------------------------------------
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:
