[gmpi] Re: Decision Time: 7.1.2
- From: "Angus F. Hewlett" <amulet@xxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sat, 14 Jun 2003 05:33:21 -0400 (EDT)
On Sat, 14 Jun 2003, Tim Hockin wrote:
> > marketing-savvy for a plugin to have F64 support, but it would be
> > shortsighted of that developer to not include an F32 version in the
>
> What stinks is that we have no proof either way. We have similar (but not
> really similar enough) experiences with different plugin formats. But the
> diffs there are so vast as to make the analogy not work.
Exactly. There are sound(ish) marketing reasons for not supporting one
current plugin format or another, and the development overhead in
supporting each is quite considerable. With GMPI being an open format,
there is no reason or means for developers to set up those kind of
barriers.
> > Sorry, can someone explain again the argument regarding UV22 and other
> > dithering plugins? Are they somehow able to keep using floats as their
> > output?
> As long as they don't need more than 24 bits of precision, they can be
> stored perfectly in a float(32). The mantissa is 24 bits. So they COULD
> dither to 16/24 bits, then convert that back to a float by dividing by
> SHRT_MAX (or whatever). When the host or whatever goes to output it, it
> would multiply by SHRT_MAX (or whatever) and get the exact result back. Not
> perfectly optimal, but it eliminates the need for different types on input
> and output (as long as we don't need > 24 bits precision).
Thanks, makes sense. Can't see why we'd need dithering at > 24 bits
precision... for conversion to 32bit int, multiply and truncate will do
just fine.
> > Also, we should expect type-conversion plugins to be very readily
> > available, so that's not an issue - the only real cost for hosts is in
> > supporting different types of inter-plug "wire", and in knowing when to
> > load a format-converter.
> If we allow plugs to have different in and out types, then yes, all the
> conversion stuff is just more GMPI plugins. If we simplify life and make a
> single plug-global type, we can provide an ancillary converter API, which
> can implement your favorite dither of conversion.
> That is IF we support more than one datatype simultaneously.
>
I think IF we support more than one datatype simultaneously, we must
support plugs with different ins and outs. I'm coming round to the idea of
having a single datatype on any given "platform", and within any given
GMPI graph; if that means that, on rare occasion, some machine-platforms
end up having more than one GMPI-platform, so be it. It does make the F32
to F64 transition more painful (and equally if some PDA or console GMPI
platform is defined as using int24 but later versions of the hardware
sprout a decent FPU), but perhaps that's a price worth paying for
simplicity.
Regards,
Angus.
----------------------------------------------------------------------
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:
