Subject: Re: [linux-audio-dev] Poll about linux music audio app usability
From: Vincent Touquet (vincent.touquet_AT_pandora.be)
Date: Fri Jun 21 2002 - 20:29:31 EEST
On Wed, Jun 19, 2002 at 11:20:20PM +0200, David Olofson wrote:
(cut)
>of programming. It looks like it would be a fast and easy hack, as
>everything's so visually "obvious" and intuitive, but that's just an
>illusion...
I think I agree, though my GUI programming
experience is quite nonexistant :) (or: :()
>> I think an effort should be undertaken to
>> get a group of people to write these damn things :)
>Yes, but how about motivation, and getting the right people to do
>their best?
I'm motivated :)
Now only to find time and someone
who can tell the bad code from the good.
>> I fear model-view-controller separation
>> doesn't apply here, as we are entirely
>> in the view realm.
>I don't agree there. The major difference is probably that there's
>much more "logic" inside the GUI part - not that there all of a
>sudden is a good reason to mix things that don't belong together.
:-)
Actually, I wrote this to stir some reaction.
I don't agree with it myself.
I believe there is stuff that can be abstracted
about this GUI thing.
>In fact, the separation between engine and UI is an absolute
>*requirement* for real time audio/MIDI applications, as you simply
>cannot make them work reliably if there are too many places where the
>UI may interfere with the timing of the engine.
True, writing anything inside
the GUI event loop is wrong
(at least when you want low latency).
(cut)
>The design I have in mind could be implemented inside any toolkit
>that provides access to the underlying "drawing toolkit" - or
>directly on top of the rendering target or API (SDL, X, fbdev,
>svgalib, GDI, DirectDraw, Direct3D/Graphics, OpenGL...), for that
>matter.
Lets put this on the table then :)
Could you draw a class diagram
or something to show us your model ?
>The only truly required feature is a way of rendering rectangular
>images into windows. All higher level stuff is just to allow certain
>targets to use hardware acceleration for specific features - ie
>performance hacks. (That is, stuff that optimization freaks can play
>around with after the toolkit is implemented and working. :-)
Well, we could just skip this
at first as premature optimization
is the root of all evil :)
>Either way, the major issue here is not *how* we should go about
>getting proper GUIs for more and larger Linux music application, but
>how we should get anyone to do any serious GUI hacking *at all*.
>There are a few exceptions, but the fact remains: The LAD community
>consists mostly of *audio* hackers. (Makes sense, sorta'... ;-)
:) you have a point.
We have here a large based of knowledgeable
coders though and a potential userbase.
So involving LAD in this seems sensible enough.
And hey, I'm interested.
I hang around here, for the same
reason as I hang around on other lists,
to learn. I like to read the code.
And I like to make code, even though
I need some project that will tickle my mind.
Such as this :)
regards
Vincent
This archive was generated by hypermail 2b28 : Fri Jun 21 2002 - 20:37:08 EEST