9 Apr
2005
9 Apr
'05
6:53 a.m.
torbenh(a)gmx.de wrote:
On Fri, Apr 08, 2005 at 02:57:04PM -0300, Juan
Linietsky wrote:
I think this is actually one of the best answers i've received so far...
Now that I think about it, you are absolutely right...
Since the plugin UI only interacts with the plugin, there is no problem in
launching the UI from another thread, at all!! Also, the UI can stress
as much as it wants the CPU since it's a separate thread than the host UI..
I will consider this approach and see if I can write some specification...
It should be very easy.. and I already have a LOT of stuff I could port
to an architecture like this...
Cheers!!
Juan,
and btw, congrats on your amazing work on fst
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 :)