[LV2] LV2 + midnam

[David Robillard]

On Tue, 2016-11-01 at 19:48 +0100, Robin Gareus wrote:
> On 10/29/2016 02:56 AM, Robin Gareus wrote:
> [..]
> > The simplest is probably to pass around .midnam files.
> > Since mappings in plugins can change dynamically a LV2 extension:
> >  - host asks plugin for the midnam
> >  - plugin can ask host to re-read it.
> > 
> > The nice part is that most DAWs and sequencers already support midnam.
> > 
> 
> Here's a first draft (working prototype in ardour-git 5.4-249-ge08c803)
> 
> #define LV2_MIDNAM_URI "http://ardour.org/lv2/midnam"
> #define LV2_MIDNAM_PREFIX LV2_MIDNAM_URI "#"
> #define LV2_MIDNAM__interface LV2_MIDNAM_PREFIX "interface"
> #define LV2_MIDNAM__update LV2_MIDNAM_PREFIX "update"
> 
> typedef void* LV2_Midnam_Handle;
> 
> /** a LV2 Feature provided by the Host to the plugin */
> typedef struct {
>   /** Opaque host data */
>   LV2_Midnam_Handle handle;
>   /** Request from run() that the host should re-read the midnam */
>   void (*update)(LV2_Midnam_Handle handle);
> } LV2_Midnam;
> 
> typedef struct {
>   /** Query midnam document. The plugin
>    * is expected to return a null-terminated XML
>    * text which is a valid midnam description
>    * (or NULL in case of error).
>    *
>    * The midnam <Model> must be unique and
>    * specific for the given plugin-instance.
>    */
>   char* (*midnam)(LV2_Handle instance);
> 
>   /** The unique model id used in the midnam,
>    * (or NULL).
>    */
>   char* (*model)(LV2_Handle instance);
> 
>   /** free allocated strings. The host
>    * calls this for every value returned by
>    * \ref midnam and \ref model.
>    */
>   void (*free)(char*);
> } LV2_Midnam_Interface;

Probably goes without saying that I'm not a huge fan, but accept that
midnam is the pragmatic route for many hosts.

Regardless, assuming midnam format, I'm wondering if an API to return a
string of midnam XML is really the way to go, and if just using files is
in the grand scheme of things better, because:

* Static plugins will want to just ship a .midnam file and refer to it
in their ttl and not deal with any of this

* Presumably saving and restoring in some cases will want to save one to
a file anyway

* Most if not all existing code for dealing with midnam loads it from a
file

Saving to a temporary file and notifying the host about that seems a bit
ugly, but it's also less stuff, and less stuff is nice.

That said, your alternate suggestion of a more fine-grained API to
describe controllers seemed kind of nice.  This leaves me to wonder how
simple of an API we could devise that describes the same things midnam
does but isn't tied to XML or MIDI at all.  Context (CC, etc) and a
controller number does most things, though not LV2ey parameters.

Then, of course, there's idealistic me who'd like to do it via messages,
but that might be a bit much :)  All of this sort of thing (midnam,
options interface, dynmanifest) makes me tempted to consider a "property
announce" interface where we just have one API for any such thing, and
the only thing you'd need to define to add functionality like midnam is
appropriate properties, and those would be useful in whatever context
(static in ttl files, state, runtime announce, messages, etc)

Focusing on some other things right now so I can't dive in, just some
idle thoughts.

-- 
dr