Re: [linux-audio-dev] FW: LADPSA Freeverb - update?

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] FW: LADPSA Freeverb - update?
From: David Benson (daveb_AT_idealab.com)
Date: Wed May 24 2000 - 19:07:40 EEST


On Wed, 24 May 2000, Paul Barton-Davis wrote:

> > <skin plugin_name="gain">
> > <pixmap src="foo.xpm" x="0" y="0" width="200" height="30"/>
> > <scrollbar bauble="bauble.xpm" x1="10" y1="15" x2="190" y2="15"
> > min_value="0" max_value="1"
> > bauble_offset_x="5" bauble_offset_y="5"
> >>
> > <control port="0"/>
> > </scrollbar>
> > </skin>
> >
> >This example is obviously flawed in many ways, but
> >I think it beats trying to design our own widget toolkit.
>
> I'm speaking from some experience, having already done exactly what
> you're describing. see the stuff at the bottom of this message.
>
> I think you're missing something: you *are* designing a widget toolkit
> with the above stuff. In the example above, you've defined a
> scrollbar, and a pixmap. All you're saving on is actually writing the
> code to implement these, since presumably you could map them down to a
> GtkScrollbar or GtkPixmap or whatever a particular toolkit uses. But
> in reality, you're defining an API for a toolkit, and unless that API
> exactly matches the target one, there is real work involved. Worse,
> there is no way to use the fine points of the native toolkit API
> within the plugin if it needs to be clever.

The intent of the above example is that it
maps into pixels directly, so although it defines
a toolkit, it is not gtk+ with gtkhscrollbar/gtkpixmap..
(However it can be built in the gtk+ framework;
the skin/gtkpixscrollbar in gdam implements the scrollbar)

I intended it to be interpreted as:
no frames, no padding, all the pixels rendereed
come from the two pixmaps, foo.xpm and bauble.xpm.

But yes, interpreting these gui plugins is going
to require some work -- remember that vstGUI never
was intended to be ported to other hosts so this
presumably wasn't a concern...

I mean, here are the choices:

        - force plugins to do all the rendering the work
          (but how can they? they cannot
          be in the same process/thread to do this really,
          unless we force a toolkit on them)

        - force plugins and hosts to use a standard interface
          library (reinvents the wheel, but definitely helps
          certain issues)

        - force hosts to do the rendering (imposes a great complexity
          cost on hosts) (we must find a way to specify from
          the plugin what it should look like)

I agree that the latter two are equivalent,
but I think library design carries with it a lot
of practical responsibility and hard-to-agree on choices (eg language).
(Making the library *extensible* is even harder...)

- dave


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed May 24 2000 - 19:56:17 EEST