patch: normalize effect for noatunarts

[Stefan Gehn]

On Sonntag Januar 2 2005 15:47, Felix Berger wrote:
> On Thursday 30 December 2004 15:53, Stefan Gehn wrote:
> > So far it's easy, just check it out (the whole noatun subdir is branched)
> > and create a patch for noatunarts. So far all I changed there was the
> > namespace because namespace Noatun is taken already (it's what is/will be
> > used inside libnoatun).
>
> Ok, I attached the modified patch for the make-it-snow branch.

I'll try my best to commit this asap together with all the other changes here 
(already 60kb of diff *pweew*).

> I removed 
> the entry Arts::SynthModule from Normalize.mcopclass, thus it's no longer
> shown in the effects widget. I don't know if that's the proper way to go,
> but I think it's a good thing to hide the effect from the user since it's
> intended to be only used through the Normalize plugin.

I'm not even sure if EffectsView will stay in libnoatun (let's face it, that 
thing is ugly) or become a part of the plugin.

> I had a little trouble getting the plugins to load without a config file. I
> managed to get by by setting:
>
> X-KDE-PluginInfo-EnabledByDefault=true

Yes, sorry, I forgot about that while evaluating the whole plugin loading 
system. It first started with a hardcoded list and later changed to config 
reading, but at that point my config already had the necessary keys set so I 
didn't notice.
I will commit some working defaults soon, together with a ported Excellent 
interface in case somebody cannot live with KJöfol (hi Charles *g*).

> > If it's in noatunarts then your normalize effect will only be available
> > if the artsplayer plugin is loaded. I don't think I can manage
> > abstracting effects from the audio backend as well (stuff like artsd,
> > gstreamer, xine etc. are just way too different).
>
> It would suffice to find out which backend is used and then use the
> appropriate normalization effect which would have to be written for every
> backend separately. But this would mean for the plugin to have build
> dependencies to all possible backends, hm.

Not really. I think enabling/disabling effects and setting their parameters in 
a generic way can't be too hard for simple ones like this (I need that 
interface for pitch as well so you certainly will get an API sooner or 
later). It's just that the effect itself has to be redone for every backend 
because they might use completely different approaches.

Bye, Stefan aka mETz
-- 
ICQ#51123152 | Moege der Pinguin mit euch sein