Subject: Re: [linux-audio-dev] proposed initial DTD for LADSPA-gui-xml
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Tue Nov 28 2000 - 18:51:03 EET
On Tue, 28 Nov 2000, you wrote:
> >
> >in your previous mail you said you do not use moving sliders, but you use
> >a set of fixed pixmaps.
> >Assume that one want large faders which move with single pixel precision.
>
> Absurd. Hows that for an answer ? Its just a silly idea. You can't
> possibly detect single pixel motion unless its an oscillation (ie. up
> 1 pixel, down 1 pixel) with a fairly high-frequency. even then, many
> people might not really notice it.
>
> Thats why I use what I've empirically determined to be a
> reasonably-sized set of them. For h- and v-motion widgets, that size
> is unfortunately related to the overall dimensions of the widget more
> directly than with radial motion, but its still small, and its still
> definitely not per-pixel.
>
> You can't possibly represent fine adjustments of a 24 bit number with
> an image-based screen widget. If you want precise representations, you
> do what I've done, which is to add a numeric display of the number and
> allow it to be set there as well.
That's obvious that I can't represent 24bit numbers with a 100-200 pixel
(in height) fader (barely 8bit :-) ).
But why should the idea of providing single pixel precision in the faders
be absurd ?
I'mean: when I play mixer automation data back with visual feedback on the
faders, why should I use a let's say 4-8 pixel granularty and see a jerky
movement (especially during very slow fades) rather than a smooth one ?
(Paul please let me know if I'm misunderstanding you, or if I am missing
something).
Notice that I was talking about vertical faders not rotating knobs or so.
>
> if the application is done correctly, pixmaps exist as non-duplicated
> server-side resources. there is one copy in the X server that is used
> to paint every location where a request to draw using that pixmap is
> made. you can have 10000 of the same pixmap on the screen, and the
> only extra server resources you are using are the cycles spent doing
> the drawing, plus the generic resources used if, for example, they are
> each in their own window (i.e. per-window overhead).
Yes as long as we can share the pixmaps within the app , then memory
consumption shoud not be a big problem.
>
> xmms is generally regarded by the GTK crowd as a bastard child. havoc
> pennington in particular thinks they did a horrible job of
> "theme-izing" it, particularly because they completely circumvented
> most of GTK (suggesting to me that they didn't understand how to use
> it).
Ah, didn't know about this ... it seemed a rather strange "gtk" feel to me
>
> >Are my fears that the GUI will get sluggish when the screen is full of racks
> >packed with sliders, displays , knobs etc unfounded ?
>
> if the backend is implemented in the right way, yes i believe it is.
ok, and I think since we are not going to move the rack-windows continuously,
the window movement speed should be a minor issue.
thanks,
Benno.
This archive was generated by hypermail 2b28 : Tue Nov 28 2000 - 17:52:14 EET