[gmpi] Re: Requirements sections 3.4 and 3.5
- From: "Vincent Burel" <vincent.burel@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Mon, 1 Dec 2003 08:03:37 +0100
----- Original Message -----
From: "Tim Hockin" <thockin@xxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Sunday, November 30, 2003 11:25 PM
Subject: [gmpi] Re: Requirements sections 3.4 and 3.5
> 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.
yes.
> If a plugin is a CPU pig, it can implement a quality knob itself (many
> plugins do this today).
i like when you repeat that i said.
>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.
or less time, typically a measure plug-in like spectrum analyzer , usually
don't need to run in render or mixdown...
> But this isn't really all true. Perhaps the user wants to do a quick
> render, and NOT make plugins run at full quality?
there is the mp3 for that ! :-)
> GMPI must provide information about the mode in which the graph is
> operating (realtime or offline) to plugins which request that
> information.
good !
> 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?
yes for the beginning , but for the rest, i'm not very excited with this
idea of draft mode or whatever quality mode . As i already said (and as you
say also) the Quality Knob (wich can be a number of band, a factor overlap,
an order, a depth parameter etc...) is requiered only for plug-in who eat
CPU power , and it's better to let the plug-in take care about that and
named that with the good word to let the user decide what to do...
VB
----------------------------------------------------------------------
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:
