torbenh@email-addr-hidden wrote:
>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 :)
>
>
>
>
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
Received on Sat Apr 9 12:15:11 2005
This archive was generated by hypermail 2.1.8 : Sat Apr 09 2005 - 12:15:11 EEST