jalv 1.4.2 has been released. Jalv is a simple but fully featured LV2 host for Jack which exposes plugin ports to Jack, essentially making any LV2 plugin function as a Jack application. For more information, see http://drobilla.net/software/jalv.

I found some time today to make
Ingen's support for running as an
LV2 more solid. I have posted about this before, but it now works at RT
appropriate buffer sizes, and several other bugs have been fixed. Here's
the obligatory contrived screenshot:

People are sometimes confused about how Ingen works as an LV2 (I need to
write proper documentation One of These Days): you don't load an "Ingen"
plugin so much (it wouldn't do anything), as you save an Ingen graph
as an LV2 plugin. The idea is that Ingen is a tool for visually building
plugins. Since LV2 does not support dynamically adding ports, it's
easiest to do your building as a Jack app, so the basic work flow is
something like:

Run Ingen as a Jack app: ingen -eg

Build a graph, adding ports, plugins, etc.

Save the graph to somewhere in your LV2_PATH, e.g. ~/.lv2 (which
happens to be the default directory of the save dialog for this
reason).

Voila, your graph should now show up in any LV2 host (its URI will
simply be its local filesystem path, unless you explicitly set a
stable one). You can check with lv2ls.

There is no export or compilation involved, Ingen's native format is LV2
compatible (graphs are always saved in the same format). If you saved a
graph elsewhere you can simply copy it to ~/.lv2 to use it as a
plugin, though for now you may have to create or fix the symlink to the
engine binary manually to do this.

Note that you can edit the graph while it's running as an LV2 plugin,
including adding new nodes and connections, you just can't add top-level
ports because the host doesn't know about them. There is still some work
to be done polishing this up to be ready for prime-time, but for the
brave, it's more or less good to go.

jalv 1.4.0 has been released. Jalv is a simple but fully featured LV2 host for Jack which exposes plugin ports to Jack, essentially making any LV2 plugin function as a Jack application. For more information, see http://drobilla.net/software/jalv.

Today I implemented better UI generation for LV2 plugin controls in
Jalv, particularly grouping
controls under headings which makes a big difference. Unfortunately few
plugins group their controls currently, but hopefully more host support
will provide the incentive to do so.

Much more efficient layout to pack more controls on the screen at
once

Support for named scale points ("ticks") on non-enumeration ports

Here is the UI generated for
Amsynth (after I added the
necessary metadata):

Still pretty utilitarian, but much more usable, which is the important
thing. Of course, this plugin is quite large, and has a pretty good
custom UI, but I happened to be polishing up its metadata anyway and the
controls group nicely so I used it as my test case.

Maybe some day this code will get smarter and evolve into a library that
can be used by other Gtk hosts. Better group layout is the obvious "next
level" advancement, a flat linear list of controls is pretty limited.
Unfortunately there's no stock Gtk container which can do text-like
reflow, which would be ideal. Perhaps a simpler scheme based on a
maximum reasonable width for a controller would do, where the table will
expand to have more columns if the window is wide enough for several.

Most of the metadata required to generate a good UI is also useful for
other purposes, for example groups make building a decent menu of many
controls feasible (e.g. to add automation lanes in
Ardour), and some types of host UIs like a modular
patcher inherently need to generate
their own "UI" of sorts.

Good metadata is not at odds with custom UIs, they each have their uses,
but it is important to remove the burden of custom UIs for simple
plugins with just a few controls that really don't need them. It's a
waste of that most precious of all resources - developer time - to have
to code UIs for a few sliders and toggles. Hopefully better host
generated UIs and support for more advanced controls like file
selectors
free up developers to spend more time making useful plugins and less
time wrestling with GUI toolkits.

Ardour has supported displaying MIDI patch names loaded from a
MIDINameDocument (or "midnam"
file) for a while, though only patches, and even that was pretty flaky.
Since this has become an itch for me and it's time for Ardour MIDI to
reach release quality, I took some time to give it a serious overhaul.
In this case, a picture or two is indeed worth a thousand words:

The note names are mainly useful for doing percussion. Several of the
bundled midnam files have note names defined, and I have added one for
General MIDI drums, which more or less corresponds to a lot of
instruments, including Hydrogen.

Controller names, to my surprise, were not present in any of the
existing midnam files at all. I wanted to sequence a hardware synth (the
Moog Minitaur) without constantly referring to the manual and trying to
remember which CC is which, so I wrote a new midnam file for the device
and implemented support in Ardour. I am very disappointed to learn that
there is no ability to group controllers, which really is the best way
to do things, so I may embrace and extend (in a completely backwards
compatible way) the format in the future to provide a better interface.

The quality of midnam files scattered around the 'net is atrocious. The
MMA actually hosts a DTD for it, but most files use the wrong DOCTYPE
(usually with a broken link), among other problems. I fixed and cleaned
up all the bundled ones in Ardour, validated them against the DTD, and
left a README in that directory about how to do so. Hopefully this,
along with incentive added by these features, encourages the community
to grow a nice set of quality midnam files.

So, MIDI name support in Ardour is now in pretty good shape. Now we just
need to add the corresponding LV2 support...