[LV2] python-lv2

[David Robillard]

On Fri, 2013-02-08 at 00:52 -0200, Luis Henrique Fagundes wrote:
> On Thu, Feb 7, 2013 at 10:54 PM, David Robillard <d at drobilla.net>
> wrote:
>         On Thu, 2013-02-07 at 19:13 -0200, Luis Henrique Fagundes
>         wrote:
>         > Hi Everybody,
>         >
>         
>         
>         Cool.  A decent way of shipping descriptions over JSON would
>         certainly
>         be nice.
> 
> Yes, I've struggled a lot since that question in Stackoverflow and
> this is the first time I feel happy about some code :-).
> 
>         
>         
>         
>         To be easy to use you will have to bake in some specifics I'm
>         sure, but
>         you really want to avoid having to explicitly model everything
>         in the
>         API, it's not extensible and means your interface will be
>         restrictive.
>         For example, I don't think an AudioInputPort etc. class for
>         every
>         possible port type is a good idea, just have a Port class
>         which has
>         (several) types, i.e. directly reflect reality.  You don't
>         really win
>         anything that way, when in doubt make it general.  Same goes
>         for
>         vocabulary classes like Foaf, rdflib.Namespace already
>         supports this
>         directly without having to list every "allowable" URI in the
>         API.
> 
> Hmmm, thinking now about a general LV2 utility, this model seems
> restrictive. But in my context, it fits perfectly: I don't need it to
> be extensible (in fact I think the extensibility is what makes RDF/LV2
> to be difficult to deal with). I need the data to be very well
> structured to match my application needs, and if it's flexible it
> might not be that useful. For example, in RDF you might have one or
> several objects with same predicate and subject, so it's very
> difficult to generally decide if that should be structured as a list
> or not. I started with that and ended up with unreliable JSON data,
> full of information that was garbage for my application. What I
> appreciate now is that I can model exactly what I want to extract,
> with a simple perception of everything in one single place.

True, but note that many things in LV2 require this, e.g.
lv2:requiredFeature often has many values.  Generally you just provide
an easy function to return one and ignore the rest.  For a general
representation, you do need a list.  All the JSON serialisations do.
Unfortunately they are really ugly for that and a few others reasons...

If you need a condensed JSON representation, that's understandable.
Personally, though, I would leave the special representation in the JSON
and not build it in to the 'get LV2 data' Python API.

> So, maybe the concept I should propose here is not a general purpose
> LV2 to JSON, but the RDFModel as a toolkit with LV2 examples for
> developers to customize for their application. My goal here is to make
> it easier for developers to get into LV2, and writing models for that
> is a much easier task than looking for triples.

Fair enough.  If all you really care about is LADSPA equivalent
functionality it probably doesn't matter much.

Otherwise you'll need some kind of property getting mechanism anyway.
Note that I'm definitely not advocating "just make them use an RDF API",
but getting properties instead of making a function per property is
generally much better, e.g.

plugin.get_name()
plugin.get_license()
plugin.get_that_thing_luis_didnt_think_of()

Isn't really any less clear than

plugin.get(doap.name)
plugin.get(doap.license)
plugin.get(foo.whatever)

and even the totally uninitiated should be able to see what to do by
looking at an example and the data file.  I suspect it would also make
your 'convert to JSON' code much simpler and more flexible.  You can
think of very vaguely like duck typing ala Python, it's not confusing,
things can simply have whatever properties.  In Python the key is a
symbol, in RDF it's a URI.

Discover plugins and ports and UIs specially and make nice classes for
them, absolutely, but you probably want to stop at having to define API
for every single little thing.

Just my input on how to best make an API, if you're just after
accomplishing a specific task, do whatever suits your needs.  That is
probably not so useful as a general LV2 Python API, but some JSON
representation and a tool to convert to it would be great for web stuff
anyway.  I know several people are generally interested in webby LV2
things...

>         Also, could you please rename this?  The name "lv2" is
>         reserved by the
>         actual LV2 specification/package, and is not an appropriate
>         name for
>         third party packages.
> 
> Sure. I didn't think that much about the name, just wanted to release
> it in some way to get feedback.

Sure.  We have just had similar problems in the past so it's good you
mentioned it.  An official "lv2" Python module would be a good place to
put basic stuff like discovery for starters (but would have to be
generic).  I'm open to adding one but have no active plans to do so any
time soon.

I expect you'd see a more interest by publishing the JSON related stuff

Thanks,

-dr


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20130207/97d8923b/attachment-0002.pgp>