Ingen as remote server or LV2 plugin

I have been working on the control protocol aspect of Ingen, towards a few goals:

  • Working GUI communicating with the server via a socket
  • Decent Python bindings for socket interface
  • Ingen as an LV2 plugin

The Python bindings got fleshed out to support a script for loading AMS patches into Ingen I have been working on (very preliminary, but in the repository and installed as ‘ingenams’). The socket interface is now sensibly synchronous, e.g. you send a command, and recv on the socket to get the response, which will include a status as well as whatever patch updates happened as a result of the command. I am happy with this route to language bindings, it’s much more pleasant than a mess of direct bindings (e.g. via swig) and being protocol controlled has many other advantages. The Python interface is implemented purely in Python, it should be simple to do the same in any language that can use sockets.

The Ingen GUI can communicate with the engine via the same protocol, so you can build patches over the network (e.g. if Ingen is running on a headless machine as part of an audio rig). It can also run in the same process and use direct function calls for maximum performance.

The Ingen protocol uses the LV2 Patch vocabulary to describe changes. For the socket interface, this is represented entirely in Turtle. When running as an LV2 plugin, Ingen uses conceptually the same protocol, except in a binary format using LV2 atoms. This is a nice example of the benefits of having things defined in a good abstract model which can be encoded in many ways. For example, it would be relatively simple to implement control via JSON for a browser-based Ingen UI, which seems like the best way to go for separate control panels, but that’s a topic for another day.

Since Ingen control can be expressed as atoms, it can run as an LV2 plugin with a full patcher UI and communicate only via LV2 ports. The UI is embeddable, and there is no memory sharing between engine and UI or hidden communication, everything is host managed. Here is a screenshot of Ingen running in Ardour 3. The MIDI in Ardour is played through an Ingen synth plugin, and the output has been recorded to the audio track. The patch can be manipulated live while running in Ardour, except for top level ports.

Ingen running in Ardour as an LV2 plugin

(Flattr this)

2 thoughts on “Ingen as remote server or LV2 plugin

  1. Interesting stuff ! I noticed the lv2 plugin version uses std::thread. I was always under the impression that spawning other threads was forbidden, and that was the point of having LV2 Worker. As usual, nice work !!

    • Threads are not forbidden, they’re just undesirable in many cases, especially for new and/or small plugins. Any large existing application like Ingen is likely to already use threads, and it’s free to do so as a plugin, provided it follows all the other rules.

      Ingen could use the worker for some things (maybe all but that’s a stretch), but since it needs normal threading code to run as an application anyway this would be a bunch of additional work for little to no benefit.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>