On Sat, 2011-07-30 at 09:49 -0500, Gabriel Beddingfield wrote: > Hi Paul, > > On 07/30/2011 07:53 AM, Paul Coccoli wrote: > > I was looking at the (unfinished) example sampler plugin here: > > > > https://gitorious.org/gabrbedd/lv2-sampler-example > > > > 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. > > First, this discussion belongs on the LV2 mailing list. :-) In fact, > we've been discussing it recently. See [1]
I have sort of been wondering about that. Obviously having an LV2 specific list is great when... well, you want to follow LV2 development, but it also contributes to this vibe of "what the heck is going on with LV2?" I would suggest maybe just discussing all this stuff here if it weren't for the archives. Having an archive of just the LV2 stuff is very valuable. Oh well. > Second, the current intention is to send an Event with a URL to load a > sample file (whether the event comes from a UI or another plugin or > whatever). In order to accomplish this, a standard event type has to be > created. That's what the "Atom extension"[2] -- it's like a standard > library of event types. > > HOWEVER, stepping back a little bit, in you could create your own > private event type and send it over an Event port. Right, this is essentially the same idea. It will work for now, the problem is that we'll get a million little event types, which is a problem for numerous reasons. One of the biggest ones is serialisation. It will be much better in the long run to have a very simple data model, like "dictionaries and lists" with a generally agreed upon set of atoms (int, float, string, etc.) because then hosts just need to implement serialisation/understanding/manipulation/persisting/etc of one thing, and the higher level semantics (e.g. "this is a load file message" do not affect the binary implementation. In effect, plugin authors (and more powerful host *users*) are free to work on their own message communication systems without requiring a bunch of C implementation work every time somebody needs a new message. Personally I think this is very exciting, particularly considering that this can easily give us "power user" level messages. Think Pd/Max built on LV2. The potential for scripting language bindings is also very nice, done this way bindings are simple and similarly don't depend on the bridge implementing every little binary thing some developer comes up with. -dr _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
