On Sat, 2011-07-30 at 08:53 -0400, Paul Coccoli wrote: > I was looking at the (unfinished) example sampler plugin here: > > https://gitorious.org/gabrbedd/lv2-sampler-example
I have moved this to the LV2 SVN repository so it can become one of the "official examples" (with more functionality than the trivial amp). This was the original intent (thanks, Gabriel!). You might want to work from there: svn co http://lv2plug.in/repo/trunk/ lv2-svn The plugin is in plugins/eg-sampler.lv2/ > I ran through the mental exercise of trying to figure out how to > finish it, and I have a question about the UI extension. How does a > UI tell its plugin to load a sample file? The example has a TODO in > its run function that indicates it will react to an LV2_Event that > contains a pathname for a file. I don't understand how a UI will > create this event. That is the big question right now. I have a pretty clear idea of how this should work, but there's a bit of a compatibility hang-up with the event extension... > On lv2plug.in, I see there's an experimental string-port extension > that defines a transfer mechanism for strings. Is this the > recommended method? Do any hosts support this extension? Not really. > There's also an atom extension, but I don't think I grok it yet. Can > I create a port of type atom:MessagePort? How does a UI make use of > that? This is the body of work intended to solve this problem. Basically it's exactly the same as events, an "atom" is just an event without a timestamp. I was planning to use an "Object" (terminology here in general could probably use revision. "Dict"? "Resource"? "Map"?) http://lv2plug.in/ns/ext/atom/#Object http://lv2plug.in/ns/doc/html/structLV2__Object.html (forgive the still a bit too obtuse documentation, work in progress) which is essentially a dictionary (with URI-int keys) This is sort of a biggish task that depends on things that aren't quite there, but if you would like to tackle it, awesome. There are helper functions in atom-helpers.h intended to make building and using "objects" simple: http://lv2plug.in/ns/ext/atom/atom-helpers.h lv2_atom_append_property to build, and lv2_object_query or the iterator stuff to read it. I was planning to tackle this myself a few weeks ago, but life got in the way :/ Regardless, feedback on this general plan would be useful. The idea is essentially this: * "atoms" (which should be called "variants") provide a simple type-tagged container so we can pass around integers, floats, samples, dictionaries, images, whatever (it is extensible, naturally) * We need a "message" type for higher level plugin control like "load this file" * For a slew of reasons, after considering/attempting several other options, I've decided that using a dictionary for this is best (sort of a JSONish concept that works nicely). The keys of this dictionary are URIs (mapped to integers for performance), the values are anything (atoms). This conveniently meshes with other LV2 technology, e.g. you can trivially serialise this to Turtle, which is an important quality since we need to describe this stuff. Assume an appropriate message does not yet exist (to highlight the extensibility and ease of doing whatever you need to do). So, independent developer, you need a load file message. Define one: "A message with rdf:type = http://example.org/LoadMessage has the mandatory key http://example.org/filename with a string value, and signifies that the plugin should load the given filename" The logistics of moving such messages around and whatnot are identical to events (though we are going to want to define a non-realtime context way to handle messages one at a time eventually). There is a slightly more generic way of approaching this, but that is in the domain of what message types we define, so I'll avoid that. Reactions on the general feel of this solution most welcome. I can describe the rationalisation in more detail if desired, it's long been an open question but I feel this solution is very promising. Cheers, -dr P.S. All that aside, writing a UI that doesn't actually work yet for the sampler plugin would certainly be useful and make it much simpler for me or whoever else to plug in the message stuff _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
