[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Traverso-devel] Plugins

From: Remon Sijrier
Subject: Re: [Traverso-devel] Plugins
Date: Tue, 11 Jul 2006 17:28:26 +0200 (CEST)
User-agent: SquirrelMail/1.4.6


>> I'm still not sure how to proceed with the plugins stuff, specially in
>> regard to the JMB enabled GUI's.
>> Perhaps it's better to first create some 'internal' effects, like the
>> jmbeq/fade you made, code a prototype for the Curve/CurveNodes/GUI etc.
> I've been thinking about it, too, and I think it is important to use as
> much code from LADSPA plugins as possible.

Sure, I didn't have anything different in mind :-)
That is, using existing code, it doesn't make sense to reinvent the wheel
heh. I hate that ;-) (But sometimes you have too)

> Otherwise we would waste a lot
> of effort only to catch up to the quality of existing plugins. So what I
> have in  mind is: calling the internal effect 'parametric eq' loads an
> LADSPA plugin (we determine which one) in the background and opens our
> GUI. The user would not know what's going on behind the scene. But it
> would allow us to easily use a different plugin as backend once there is
> one of better quality. And we only had to implement LADSPA support, no
> custom 'internal effect' framework. We could either have dependencies to
> the used plugins, or distribute a copy of them with Traverso.

A slow growing idea of me was to pick a number of very good ladspa
plugins, and ship those with Traverso, without using the ladspa interface.

However, it's much better to just use the ladspa interface to be able to
load any ladspa plugin, including future versions of ladspa (lv2)
Of course, some of those filters could be compiled statically into
Traverso with the addition of a nice JMB enabled interface.

I need to do some research on the coding matter of course, and I'll try to
abstract plugins as much as possible from the internals of Traverso.

A more important point in regard to plugins however is this:

How do we visualize them?

For example, in Ardour there is a sidebar where you somehow can add
plugins. And in the mixer of course.

My original idea, also a bit based on the interface of Tracktion and the
history of the curve mode view, was to add the filters _in_ the Trackview
(this is not the case in Tracktion though).
However, they only will be visible if you switch to the "Cuve Mode", in
this mode you only will be able to edit/add/modify/etc the Filters in a
Track, no clip moving, deleting and so on. (Except perhaps the Gain of a
Track/AudioClip but I'm not sure)

Filters will be visible in a Track, like a square box with the filtername
in it, ordered from left to right, so you quickly see how the filters are
processed. (if you like an elliptic view more, or ...)
Changing the order would be done by simply dragging them....
Filters applied to a Track's input could for example be aligned left, and
filters applied to a track's output aligned right...

Parameters that can be automated will have a Curve, only the active
(selected) filter will show it's curve in the TrackView.
Modifying a filter can be done via < e > when pointed on the filterview.
Just popping up in my mind, we could show an information field with all
the parameter values when the mouse hovers the filterview, or < i > for

But what if you want to add a filter to an AudioClip?
This could mess the view a bit if there are allready filters for Tracks....
One idea:
Adding Track filterviews to the bottom of the TrackView, AudioClip filters
start at the upperleft corner of the AudioClipView.
Second idea:
Add a trackpanel, and filters in there (a bit like ardour does).
This makes jmb enabled handling of filters for TrackView rather
Third idea:
Extend the bottom of the TrackView with a small area which can contain the
Filterviews for Tracks...
Fourth idea:

And then at least a set of 'internal' filters will show a JMB enabled GUI
when < e >, like your jmbeq/fade :-)

Ah, I knew there was something else.
Input/output matching.
There are a number of ladspa plugins having 1 input, 2 outputs or 2
inputs, 1 output and so on.
It could be that I simply need to better understand why these filters have
2 inputs and just one output, and that I need to do some routing in ardour
to get it working on my stereo track...

But, what the ..., adding a compressor filter to my stereo track shouldn't
be that hard?

If you have some clue on this....

My idea is this: If I have a stereo Track and want to add a compressor
filter to it, then it should "just work".
No need to do some magical routing stuff because the filter only accepts 1
Just add 2 filters, one for each channel :-)

Not sure if this is nonsense, but for example a convolution reverb filter
has 1 in / 1 out.
Not a big deal to add 2 of those filters to a stereo Track, this will work
just fine.
The filters however will be controlled by _one_ filterview interface.

Hmm, I think this is kinda what I have in mind.

Comments, suggestions, everything is welcome :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]