Re: [linux-audio-dev] Poll about linux music audio app usability

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

Subject: Re: [linux-audio-dev] Poll about linux music audio app usability
From: David Olofson (david_AT_gardena.net)
Date: Tue Jun 11 2002 - 04:48:27 EEST


On Monday 10 June 2002 07.46, Paul Davis wrote:
> >I think this raises some questions.. My feeling is that most
> > people aiming to write music on this OS is expecting to have apps
> > with super easy and intuitive interfaces, where you only go
> > trough displays, knobs, sliders and paintabe areas.
> >Why we dont have apps such as Reason, Reaktor, Sonar, Sound Forge,
> >etc? I dont mean full apps, but at least projects aiming for that
> > kind of thing.
>
> Because they are really, really, really hard to write (well) and
> they take a long time either way. They are classic examples of the
> 80/20 rule (also known as the 90/10 rule): 80% of the functionality
> takes 20% of the time, but the remaining 20% takes 80% of the time
> *and* covers 80% of the most visible and cool features :)

That's basically why I think inventing Yet Another, Although Much
Cooler Looking GUI Toolkit would be worth the effort, if it could
help cutting GUI development time without dropping chrome and/or
features. (Whether or not it's possibly is another issue. Guess I'll
just have to try it...)

> Ardour
> could record 24 tracks of audio simultaneously more than 2 years
> ago - what I originally thought was a major milestone turned out to
> be a tiny pebble on the beach.

Realizing that sort of thing really makes one go "Oh...", with a very
happy smile on ones face, doesn't it? ;-)

Considering that, one must realize that the power of the Dark Side is
incredible. Just hacking away on countless projects on our own won't
cut it any more, Source being with us or not. I would say that the
Source is failing you if you're hacking all on your own, though...

> This is not like Apache, which though its ancestral line to httpd,
> actually *invented* HTTP service, and was in turn connected to the
> various FTP servers before it. We don't have *any* open source
> examples of these kinds of programs to study. We have to (re)invent
> it all as we go, and that takes time. Thats partly why MusE and
> Ardour are so important - even if they ultimately are not the best
> tools for Linux, they (and many other tools) start to provide large
> pools of code for other programmers to see "how its done (so far)".
> "it" is not the simplistic kind of playback offered by the many
> soundfile players, but the complex stuff done by non-linear,
> EDL-based engines used by the most desirable proprietary programs.

Yes... I just hope the complexity of these applications don't scare
most hackers away. There aren't all *that* many audio hackers after
all, and meanwhile, it seems like our needs are closely related to
incredibly complex applications - usually with real time
requirements, to make things even worse.

Then again, We Have Paul! :-)

> >We do have very powerful tools, but i have to admit that for most
> > of them we have to learn some script programming.
>
> Some people think this is a good thing because the tools are
> ultimately more capable and less limiting. Others disagree.

I'd like both... Fiddle knobs and draw curves until you get the basic
sound, and then, if required, unscrew the chrome panels to hack same
more complex logic and/or math in. :-)

Doesn't make things easier, does it?

> >Do we lack good APIs? Alsa MIDI api is the best I have seen for
> > it's kind. Also, sould linux apps really take this windows
> > approach of making huge bloated interfaces with lots of eye
> > candy, or should we try to improve on making our apps
> > intercommunicate between eachother, while still giving some
> > importance to ease of use?
>
> Part of the point of JACK was not being forced to make this choice.

Nevertheless, we need to agree on higher level protocols to have
significantly more advanced interaction than audio streaming.
Applications knowing each other's "private" protocols is much better
than monolithic design, but I think there should be more flexibility
available without hacking the applications.

Either way, I have a feeling we're better off starting with some
actual implementations. When we start to see a patterns, it might be
more obvious what these "protocols" should look like.

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`---------------------------> http://www.linuxdj.com/maia/ -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-------------------------------------> http://olofson.net -'


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

This archive was generated by hypermail 2b28 : Tue Jun 11 2002 - 04:43:59 EEST