Re: [linux-audio-dev] Creating the conditions for VST-like plugins on Linux.

On Fri, Apr 08, 2005 at 02:57:04PM -0300, Juan Linietsky wrote:

> Hi ! I'm writing this mail because at this point I'm seeing that the
> Linux Audio Development community is still going aimlessly on how to
> develop powerful audio applications. As we know, one of the key factors
> missing nowadays is audio plugins and synth plugins. Some audio plugin
> needs can be covered by LADSPA, but in other cases you need a lot more
> complex interfaces than just a few sliders.. (like is compressor with
> curves, graphical equalizers with band feedback, parametrics, multiband
> compressors, voice autotunning, surround spatial repositioning.. and
> everything available of course, that would become more intuitive and
> useful with more feedback)

hah. this is the first fruits i am seeing from my fst work.
by analyzing the vst plugin interface we can see what the deficiencies
of the linux standards are.

but juan: i dont think your solution is "the right way"

look at xfst: vst plugins are just some plugins which use another
toolkit. the wine toolkit.

the code which is currently commented out, is getting the XID of the
wine window, and swallows that into a gtk interface.

(thats why the whole gtk stuff is in there.)
the current problem with that code is that swallowing does somehow not
work with most windowmanagers (it works with fluxbox and windowmaker
though)

and i failed to analyze why it does not work with kwm.

but the principle is outlined very clearly:

just create a thread and run the qt/gtk mainloop for a plugin in that thread.
one application can open several sockets and connections to an XServer.

there is no "one socket per process" limit.

i hope you get what i mean.
and i am very happy that you share my thoughts on fst.

after all vst plugins are all somehow crippled and not so funny after
all. but i still consider vst the most powerful audio plugin standard in
existence currently.
we need to learn from vst and model a real free standard.

my coding time is VERY limited currently, so i probably cant step
forward and do a first implementation.

It should have been done on last years LAC :)

>
> Also there is the need for instrument plugins, single or multi timbral
> (so you dont have to load all the instances at once). DSSI provides this
> (except the multitimbral) but you have to write the interface separated
> than the core, which not only is more difficult to program, but also
> very limiting because in many cases you cant show with much detail what
> is going inside the synth, like editing a sample, draw freeform
> envelopes, edit the oscilator generator, etc. And better not talk about
> effects, which need spectrums, vus, and other kind of complex feedback.
>
> So, I'm sure that many of you have asked yourselves, why cant we have a
> VST-like plugin architecture for Linux?
>
> The following are excuses:
>
> -Because we need core and interface separation, this way we warranty a
> clean design and network transparency
> -Because it would force both interface and core to be memory locked, as
> a result of being a jack clients, forcing more physical memory to be used
> -Because separating interface and core makes for a clear design.

i dont care for network transparency also.
and networktransparency is created by X.

> And I say, ALL THIS IS LIES. Every single of such reasons are of no
> concern to musicans. If I just want to make music, I would not care
> about any of such reasons. I'd just fire up an application and make
> music. All that seems to me more like academia-speech than real reasons.
> You can believe them or not, but it's PROVEN that none of these are
> needed to make music.
>
> However, there is a one and single reason of why we dont have VST-Like
> plugins in Linux:
>
> -It is impossible to make a plugin in a widget toolkit that will be
> hosted by another widget toolkit. (say, gtk on qt, or fltk on fox).

no its not. as shown above.
>
> Why is this? The answer is simple.. X11. An X client connects to the
> Xserver (via unix socket/tcp/wathever) then stays blocked in that
> connection until it receives events (keypress/mouse/etc), which are sent
> to the event loop. It is then the toolkit (gtk/qt/etc) the one
> responsible for handling the events. This way, even if you load many
> toolkits at the same time, and even each opens a connection... one of
> them has to stay blocked in the event loop.
>
> This is the REAL reason why we cant make a VST-Like plugin API in Linux,
> or EVEN port opensource VST plugins and use them here.
> Up to now, nobody has really bothered in solving this problem, instead
> most just attempt finding a workaround.
>
> So what I am proposing is to SOLVE this problem.. how?
>
> -Designing a library that will act as intermediate between the toolkits
> and the X Connection, handling the event loops for all of them, so they
> can run together.
> -Placing this library in freedesktop.org
> -Encouraging toolkit makers to support this library, and porting them to it

well i described my solution above. and i think this solution is far
easier to build and not as intrusive.

>
> As you see, this is not a simple task, and much less something I can do
> alone, so I will need help!! I am very sure that at some point we will
> get support from other groups which will also benefit from this.
>
> So before anything, I'd like to know who is interested in this, and who
> would like to help, offer experience, etc.

i probably cant help very much. but i will of course offer my experience
and will write some patches of course.

>
> Well, hope I get any feedback

here is the feedback. forget the flames.
>
> Cheers!
>
> Juan
>
>
>
>
>

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language