Posted on July 25, 2006 - by jono
LADSPA support coming to Jokosher
At LUGRadio Live we agreed an initial feature-set for Jokosher 0.2, and a release schedule. For more details on this, read this this thread.
One of the key features I am keen to see in 0.2 is full LADSPA support. For those of you who have been living under a rock, LADSPA is a plug-in standard for audio effects. There are stacks of plug-ins out there, and we want them to work inside Jokosher. So, how does this work?
Well, there is a GStreamer bridge that worked with 0.8 and was ported to 0.10 and has problems. I have reported this as a bug and hopefully some of the GStreamer guys will fix this up soon. In the meantime, I figured I would write some code to get the plug-in UI up and running.
LADSPA does not actually provide a user interface for plug-ins. I was under the impression that some kind of XML UI description schema (similar to Glade) was available to describe the UI, but it seems not. Instead, you need to probe the LADSPA ports (the virtual knobs on the plug-in) and generate the interface yourself. I figured I would see if the GStreamer LADSPA bridge worked with regard to exposing these ports via GObject properties.
So, I wrote a test script today that queries the GStreamer plug-in registry for LADSPA plug-ins, and provides a list of them. When you select a plug-in, the script generates a settings window with a bunch of sliders and their appropriate minimum and maximum values. As such, the LADSPA querying and UI side of things is written and I can drop it into Jokosher. I plan on merging it in over the next few days. I hope to get LADSPA support finished for entire instruments over the following week, and when the bridge is fixed, we will have working effects support in Jokosher!! 
17 Comments
We'd love to hear yours!
Leave a Reply
Here's your chance to speak.
-
Flickr Photos
Visit My Website
July 25, 2006
Permalink
Oh please, for the love of all that is holy do not make an autogenerated UI…please
For futher evidence see http://www.metadecks.org/software/sweep/screenshots/effects.html and the abominations that are the Sweep and Audacity effects menus.
Visit My Website
July 25, 2006
Permalink
iain: not a lot of choice. That’s the way LADSPA makes you do it. If you have other suggestions, we’d love to hear them!
Visit My Website
July 25, 2006
Permalink
Although it will need to be generated, I have spent most of today working on the effects UI, and it will be much better than other editors. But, as sil says, thats thew only way to go with LADSPA.
Visit My Website
July 26, 2006
Permalink
You pick the plugins you ae going to use, then you hand design the UI for them. It is a lot more work, but it is better than having a mess of “Plugins 1->16″ “Plugins 17 -> 24″ lmenus like other programs have, and really, is the only way that Jokosher can claim to be a program focussed on usability.
Visit My Website
July 26, 2006
Permalink
Presumably the best compromise would be to do both – produce a generic interface if there is no custom one available, but show the custom one if there is one.
Visit My Website
July 26, 2006
Permalink
iain, mrben – the plan is to not just produce a list of numbered plugins like that. For the majority of the plug-ins we will autogenerate the interface, but for some key plug-ins such as compression and EQ, I plan on working with the art team to produce an attractive and simple interface.
It is also important to remember that Jokosher will sport lots of plug-in presets to make life easier.
Visit My Website
July 26, 2006
Permalink
This is a major failing of the whole ladspa concept, that they didn’t take any real consideration of UI. And until the monstrosity of requiring autogenerated UIs is solved,I don’t think Linux will be an overly attractive platform for audio processing…and this is coming from someone who both writes a sample editor and edits audio on linux…
sorry for the soapboxing…good luck on the rest of jokosher
Visit My Website
July 26, 2006
Permalink
iain – it isnt perfect, and I agree it is not an ideal situation. Autogenerated user intefaces feel badly documentated and clunky. But, I do feel that there ways to solve some of these usability problems without throwing away all your LADSPA plug-ins and creating a new spec.
My next post will explain some of my thinking about how to solve some of these problems. I think it is a combination of sensible meta-data, good usability and discoverable interfaces.
There is work going into LADSPA version 2 called LV2 – I recommend you transmit your thoughts to Steve Harris. Use the Linux Audio Developers mailing list to do so.
Visit My Website
July 26, 2006
Permalink
iain: I completely agree, and as Jono says we intend to hand-design UI for the most common plugins. However, we shouldn’t prevent someone from installing a plugin of their choice for which we have not designed a specific UI.
Visit My Website
July 28, 2006
Permalink
hmm. the decision not to include an interface componant to the LADSPA spec was born out of pragmatism not a lack of consideration. the technical problems associated with this are significant and given that the devs were unfunded and underpopulated it was a wise move. a working plugin system was a huge shot in the arm for linux audio and if they had tried to tackle these toolkit woes head on, they could well be still at it today. of course, that doesn’t stop it being a massive pain in the arse.
iain: i don’t remember seeing any bug reports or feature requests WRT sweep’s little abomination. does marlin support LADSPA?
Visit My Website
July 28, 2006
Permalink
keke, oops + =P
Visit My Website
July 29, 2006
Permalink
pete – I agree that pragmatism was naturally a large proponant in decided to omit a specific GUI, and merely exposing port capabilities mitigates this responsibility to the application developer. I understand it, but its still not ideal. Take for example an EQ – here, a vertical orientation for the controls is not ideal because (a) screens are wider than longer and (b) you need to compare slider height to form EQ graphs. That is nigh-on impossible with horizontal EQ controls. Sure, I understand the current solution, but LV2 needs to solve these problems I would say.
Visit My Website
July 29, 2006
Permalink
and that’s not all. each app has it’s own method of dealing with interfaces so you get a different experience each time. then there’s the presets.. :/ however, there are three reasons to be cheerful imo, 1. LV2 is extensible 2. we have a working system for out of process interfaces in DSSI already 3. recently i’ve heard that QT either will support or does support using glib’s event loop. this paves the way for say, a plugn that directly uses QT/KDE to run inside a GTK/Gnome application and vice-versa.
“custom GUIs” is listed as a planned extension to LV2 here: http://lv2plug.in/
so it’s looking good at the moment.
Visit My Website
July 29, 2006
Permalink
pete – thanks for the great information by the way! It is really useful.
LV2 is looking pretty cool, and when the LADSPA support is in, I hope to look into LV2 support. I really have not looked into it in that much detail. The LADSPA support in Jokosher is largely done, and we will have our own presets code in there to make everything simple to use.
So, are you an audio developer? If so, what do you hack on?
Visit My Website
August 7, 2006
Permalink
just back from me hols.. well, i’m less of an audio developer than a musician with some C ken. (and probably less of a musician than i am a professional optimist, at least in that regard
occasionally i find the time to maintain sweep and i’m also working
on a pixmap interface for a DSSI plugin. google seemed to
think this post was topical.. and i tend to agree. 
WRT LV2, Dave Robillard is working on a convenience library so you might want to check that out when the time comes. LV2 isn’t substantial enough to hitch your wagon to yet though. incidentally, it rained a good bit while i was away so i started work on a plugin browser for sweep. i’ll be interested to see how you handled plugin selection and categorization.
Visit My Website
August 7, 2006
Permalink
heh.. i must stop pressing enter in autowrap text environments. format gets all wrongular.