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