[Traverso-devel] Thoughts on plugin strategy

[Nicola Döbelin]

Hi everybody,

After a discussion with Remon about plugins and how to implement them, I would 
once more like to post some general thoughts on the topic. The discussion was 
if gain and panorama should be implemented as plugins as suggested by Jonatan, 
and I think this is an excellent idea. However, I have some concerns as to the 
usability of this concept, but if we hold on to some guidelines I am confident 
that we can maintain a flexible plugin implementation without swamping the user 
in the first place.

AFAIK we are all linux cracks, more or less, so I guess we all know what the 
term "the unix way" refers to: One tool for one job. This concept is still 
popular even in the days of modern desktop environments, although there are now 
GUIs which combine several command line tools in one apparently large and 
powerful application. A prime example is k3b, which uses command line tools for 
almost everything. From a developer's point of view this is very convenient, 
because it makes use of existing and often very mature code. The user is 
supposed to remain untroubled by all the dependencies, but anyone who has tried 
to set up one of the DVD ripping frontends knows that installing all the 
dependencies (transcode, avifile, ffmpeg, mencoder, etc.) can be a major 
challenge. If cvs versions are required, installing by hand is close to 
impossible for the majority of users. From the user's point of view the 
"commercial way" of shipping one big application which includes everything it 
needs is much more convenient.

My idea for Traverso is that we should include a default set of effects which 
are 'just there'. Of course we have the possibility of using jackrack for 
plugins, jamin to process the master output, xmms to play compressed file 
formats, and so on. But in terms of user experience this is horrible. In my 
opinion the users would appreciate if things which are needed all the time 
would be just there. I'm thinking of a gain and panorama control, a parametric 
EQ, a dynamics section, and maybe even reverb. These are things one needs all 
the time, and having to set up a plugin just to be able to change the gain of a 
track is nothing but a pain in the neck.

OTOH using a plugin architecture for as many functions as possible would be 
good for us, the developers, because it increases modularity and flexibility. 
But how do we get the best from both worlds? Should we hard-code the effects 
into Traverso? No! That would be way too much effort, and FWIW a good sounding 
EQ or dynamics plugin is a piece of art by itself. But if we would take one of 
the existing plugins (TAP or SWH for example), write a custom GUI which is 
consistent with the concept of soft selections, ship it with Traverso and load 
it by default into every track, it would be implemented as a plugin, but it 
would feel like just being there.

Again, the point is that we should 'privilege' certain plugins by:

- writing a GUI for them
- shipping them with Traverso by default
- loading by default
- integrating them into the Traverso GUI

The last point is particularly important for the gain and pan plugins. Although 
being a plugin in future, they should still be accessible as they are now, that 
is directly on the track and audio clip. 

I hope you get what I mean. (Actually the correlation meter and FFT spectrum 
analyzer are already implemented as native plugins with custom GUIs.) Just look 
at it from the users perspective. What's better: Having to load an EQ plugin 
with a generic and often ugly interface (as in ardour), or having an EQ with a 
carefully designed GUI which is just there?

Best regards
Nic


-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer