summary of the aKademy meetings

[Dik Takken]

On Mon, 6 Sep 2004, Scott Wheeler wrote:

> On Monday 06 September 2004 14:22, Dik Takken wrote:
>
>> I posted this idea to KDE-Core-Devel some time ago:
>>
>> http://lists.kde.org/?l=kde-core-devel&m=109281129913280&w=2
>>
>> What do you think of this?
>
> Yes, I believe this is what led Matthias to the idea of supporting them.
> After I bugged him about the design a bit until I got it (I hope) I realized
> that it's a pretty powerful idea for coming up with a more usable mixer
> interface.
>
> However I don't believe that arbitrary "complex" processing belongs in the
> simple API; at least at the present moment it was generally agreed that not
> much more than volume belongs there.

There's no need to add an API for it. The processing chain behind the 
volume control (if any) is completely out of the reach of the application. 
Configuration of the channel plugin should be done externally, by the 
user.

> I kind of liken this to the advanced capabilities of aRts; they've always been
> there, and in fact there's quite a bit that you could bolt on to aRts-enabled
> application now, but nobody does.

Are you takling about developers or users? I agree that we don't need API 
access to processing plugins. We only need the API to choose a channel and 
we need these channels to be pluggable. If we will see plugins that do 
sound processing in the future or not is not today's concern. We only need 
to make sure that the API allows for it to be a possibility for the 
future.

I have taken a look at the user tools to build Arts processing chains 
from time to time and it sure looks like Arts has some impressive 
capabilities. Unfortunately I never got anything to work. It was 
either unstable or it didn't work at all. If it would work, I would 
immediately use it to apply an equaliser to Juk's output because it's the 
only thing I'm still missing in Juk.

> I'm not sure that offering such features
> in the user interface would do much more.

My suggestion is to *not* add anything at all to the user interface of 
individual applications. Handling of sound/video processing should be 
outside of the application, and be 100% transparent to the application. 
Exceptions are apps like AmaroK, which need custom, nicely integrated 
controls for all it's features. We don't want to create an API for 
anything like that.

> I'm not really dead-set one way or the other on this one, but I think for the
> moment there are probably bigger issues to work out; you might bring this up
> again in a few months once a few more things have dropped into place.



> -Scott
> _______________________________________________
> kde-multimedia mailing list
> kde-multimedia at kde.org
> https://mail.kde.org/mailman/listinfo/kde-multimedia
>


   -----------------------------------------------------------------