drobilla

There’s been a bit of talk in the GNOME camp lately about using DOAP instead of the unstructured text files that are the current norm for source packages. On the one hand, people want the benefits of having machine readable data in projects, OTOH, RDF/XML is a nightmare (”I’ll never maintain such bloat!” - “That is one hell of an ugly file.”).

This is how RDF/XML hurts RDF. The original loathed file:

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl"?>
<rdf:RDF xml:lang="en"
         xmlns="http://usefulinc.com/ns/doap#"
         xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:asfext="http://projects.apache.org/ns/asfext#">
  <Project rdf:about="http://ant.apache.org/">
    <created>2006-02-17</created>
    <license rdf:resource="http://usefulinc.com/doap/licenses/asl20" />
    <name>Apache Ant</name>
    <homepage rdf:resource="http://ant.apache.org" />
    <asfext:pmc rdf:resource="http://ant.apache.org" />
    <shortdesc>Java-based build tool</shortdesc>
    <description>Apache Ant is a Java-based build tool. In theory, it is kind of like Make, but without Make\'s wrinkles.</description>
    <bug-database rdf:resource="http://issues.apache.org/bugzilla/buglist.cgi?product=Ant" />
    <mailing-list rdf:resource="http://ant.apache.org/mail.html" />
    <download-page rdf:resource="http://ant.apache.org/bindownload.cgi" />
    <programming-language>Java</programming-language>
    <category rdf:resource="http://projects.apache.org/category/build-management" />
    <release>
      <Version>
        <name>Apache Ant 1.7.0</name>
        <created>2006-12-13</created>
        <revision>1.7.0</revision>
      </Version>
    </release>
    <repository>
      <SVNRepository>
        <location rdf:resource="http://svn.apache.org/repos/asf/ant"/>
        <browse rdf:resource="http://svn.apache.org/viewcvs.cgi/ant"/>
      </SVNRepository>
    </repository>
  </Project>
</rdf:RDF>

and the equivalent in Turtle (a subset of N3) (automatically generated with rapper -o turtle doap_Ant.rdf):

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix : <http://usefulinc.com/ns/doap#> .
@prefix asfext: <http://projects.apache.org/ns/asfext#> .


    a :Project;
    :created "2006-02-17"@en;
    :license ;
    :name "Apache Ant"@en;
    :homepage <http://ant.apache.org>;
    asfext:pmc <http://ant.apache.org>;
    :shortdesc "Java-based build tool"@en;
    :description "Apache Ant is a Java-based build tool. In theory, it is kind of like Make, but without Make's wrinkles."@en;
    :bug-database <http://issues.apache.org/bugzilla/buglist.cgi?product=Ant>;
    :mailing-list <http://ant.apache.org/mail.html>;
    :download-page <http://ant.apache.org/bindownload.cgi>;
    :programming-language "Java"@en;
    :category <http://projects.apache.org/category/build-management>;
    :release [
        a :Version;
        :name "Apache Ant 1.7.0"@en;
        :created "2006-12-13"@en;
        :revision "1.7.0"@en
    ];
    :repository [
        a :SVNRepository;
        :location <http://svn.apache.org/repos/asf/ant>
        :browse <http://svn.apache.org/viewcvs.cgi/ant>
    ] .

I wouldn’t want to hand maintain for RDF/XML version either, but the Turtle version? Sure. It’s the exact same information, far more human readable, and about as terse as it could be while representing the same information.

The best thing about a syntax independent model like RDF is.. well, it’s syntax independent. Choose one that doesn’t suck :)

So, that whole Ardour thing is coming along. Couple more fundamental things (like multi-note dragging and actually saving edits out to disk) and it should be an at least somewhat usable MIDI sequencer. Woo.

In slightly related news, Ingen is almost in a usable state after almost a year of being useless. The remaining deep issues were in it’s dependencies, which I just finished sorting out. Arbitrary precision Turtle floating point literal (xsd:decimal) serialization is in Raptor SVN, and will hopefully see the light of day in release form. The other issue was sketchy OSC data transmission from engine to client because things weren’t being put in bundles. I added the API hooks I need for this to liblo, but the maintainer is MIA and I can’t depend on a version of liblo that doesn’t publicly exist, so I’m dealing with two branches of my own code for now, which is pretty annoying.

Getting around that time to push out another LV2 beta (probably the final one) too, but SWH is MIA as well. London done get blowed up or something?

This post exists solely to stick something new on the page so it doesn’t look like I did an experiment in fasting and died, never to bless the Interweb with my presence again.

Current activities:

LV2 OSC message ports extension (working to some extent)
LV2 contexts extension (just conceptual/purely RDF for now)

These two playing nicely together in Ingen will be roughly the best thing ever. Take that, pd.

That is all.

Well, I’ve been working on Ardour but not directly on my SoC project.. finally got around to fixing that whole mixer-strip-element thing that’s been on the table since last year. Things are more open to extensibility now (and a unified bus implementation should appear soon, so we’ll have MIDI busses or even MIDI/audio (instrument) busses). Maybe we’ll see things like this actually happen some time soonish…

It would be nice to figure out a really good MIDI meter (something more clever than just an audio peak meter abused), and a MIDI fader that can work in various ways, or even instrument plugin support, but it’s probably time to get on the actual piano roll editing part of the project and leave that stuff until afterwards.

Kinda ruins my flow though, you know?

Well.. finally fully moved; I guess it’s time to stop screwing around and get back into hacking. Specifically Ardour, since I’m being payed to do so and all.

Looks like we don’t have a fancy new cairo canvas to play with. Maybe it will be worth my time to do that first, but I’m going to do some fiddling with displaying MIDI data with gnomecanvas first to get a grasp on things. Wouldn’t hurt to have some visually obvious clue that I am, in fact, actually doing something. This summer’s project should be more rewarding than last in that sense; most of what I need to do is visual stuff which tends to be more fun since you have something nice and tangible at the end of the day.

Of course, displaying data is one thing. One relatively easy thing. Actually editing it on the other hand………. that’s where the “fun” (ie hard) part comes in.

I think a top-down (GUI->implementation) strategy is best here. The Grand Battle Plan(TM) goes something like this:

• Get MIDI data displayed in regions, notes visible as one canvas item (rect) per note
• Attach event signals from note canvas items (move, click, etc) to a set of stub methods that encompass all the editing operations
• Now there’s a nice centralized area where all the editing operations need to be implemented
• Figure out how the hell to implement them (ie ???????????)
• Implement them (ie Profit!)

I’ve decided to use my blog to archive random ideas until I figure something better out (on that note, anyone know of any good RDF based mind-map software, or something generic that can easily be used as one?)

Until then:

<drobilla> crazy thought of the day: write an LV2 extension for text stream input/output ports, and you can write a trivial unix cmd line utility wrapper plugin
<drobilla> anyone want to convert midi to text then run it through sed and grep and convert back to midi in a modular? :)
<gordonjcp> ahahaha
<gordonjcp> you sick sick man
<drobilla> unix modular, best thing ever

Ingix? Really wouldn’t be that hard. Could even make it parallelize forkey pipelines, if the LV2 contexts extension is powerful enough. More on that later…

… done and done. It is so much nicer to right click a canvas and hop through a few class (”category”) menus to find the plugin you want than search a big flat list in a dialog. Short of a couple of semantic wars over classes (I already had to change the schema a bit to make the menu less crap), that’s done. As usual, need to go over the API and make sure there’s no potential future binary incompatibility issues, but I think it’s pretty good. SLV2 is quite a bit more of an abstraction layer than I initially planned, but the API is more solid and flexible, as far as being able to change things underneath without breaking things.

Look at me, finally learning that compatibility is important.

So what’s left now is the hard part: exposing full(ish) RDF querying. I don’t want to expose Redland (gone this far without) at least for normal uses, so I guess I will have to make a query results ‘class’ etc.

First is the bigger issue though: at the moment there’s no typed literals in SLV2 at all. This is not good…

Well, I did the Redland modularization thing to tear those dependencies out. Luckily for me, Dave Becket wrote the storage module stuff in anticipation of modularization, so it was actually really easy (what’s with people named Dave and being absolutely brilliant eh?) So, pending whatever autohell stuff needs doing to make it possible/easy to package into separate bits, that problem’s solved.

Armed with my new anti-whining-user ammo of future dependency dissapearance, I pretty much rewrote all of SLV2 to use one big model of all LV2 related RDF on the system. I figured with an in memory model, querying the whole thing should be quite fast (it’s not that big), and there’s some fun to be had with a big single web of data containing everything plugin/extension/whatever related. Happily, going through and parsing all the files is nearly instantaneous (Raptor has to be the fastest RDF parser in the west by a long shot)…

… and non-trivial (but necessary) queries take so long and chew 100% CPU that they’re unusable.

Shit.

Long story short, debugging and/or rewriting half of Rasqal isn’t exactly high on my Things I Feel Like Doing Right Now list, so I rewrote SLV2 again. Now each plugin has it’s own in-memory model, which works quite well. Lost that big web of data, which I thought was a pretty cool idea, but hopefully whatever’s wrong with Redland can get sorted out by the time anyone has a real use for that anyway. The plugin model can still load plugin extension bundles etc. into the same model, and that’s the important part anyway (which makes LV2 plugins extendable without having to modify the plugin’s bundle itself). Not really sure how the main ontology and LV2 extensions like categories and other system stuff fit in to this just yet, but that’s a train of thought for another day.

The performance problems Zynjacku was having are much better now. The loading guage no longer pauses on plugins with large numbers of ports, it zips along at a constant speed and is quite a bit faster overall.

It could be faster still if I added an API to get plugins with a custom query, but that will probably have to wait until the Redland query lock-up thing is solved. Anyway, it’s much, much better now, and the API has been redone in a better more abstractioney way that should allow any kind of redesign behind the scenes (as far as cacheing models and whatnot) without breaking the API. Also the API is now reentrant (well, if Redland is anyway?) which I figure is probably going to be an issue at some point once some plugin and it’s host both use SLV2.

Now to just get the thing fully working again…

Blissfully ignoring the fact that I have an exam next wednesday that’s probably going to be pretty hard and involves mathematics and whatnot…. free time!

So, now is the time to get some damn releases out and off my back, starting with stuff that other people depend on (though my toys are frankly much more fun to work on. You all owe me a beer). Particularly before the Summer of Code starts, which (27 hour a day jokes aside) is going to chew time like crazy. Hopefully I manage to get outside and see the sun once or twice this summer, but that’s another topic.

Step 1 is SLV2. LV2 really needs to get out there, yesterday. The main problem right now is exposing categories and performance issues with querying lots of plugins with large numbers of ports.

Categories is a bit tough to do right. The easy way out is to just assume the categories are as in in ontology, but that’s crap and very un-LV2ey. The way bundles work you can just drop in extensions with more categories and they should be able to magically show up in all the user’s apps without the apps having to change at all. The hard part is dealing with weird category heirarchies and how to expose it all in an API. The weird heirarchies is solved easily enough by making a few assumptions. Exposing via an API I don’t know. I suppose having separate methods to get the category heirarchy (as URIs and names, probably), then just allow getting the (many? a?) category for a plugin and the host can do whatever it wants from there. That’s easy enough, seems like it will work. How to return the heirarchy is a question, I suppose the structure in memory can be a tree that directly maps to the heirarchy somehow. This kind of thing is much more annoying in C (especially for a little OO weenie yungun’ like myself), but it can work. One thing that I should probably keep in mind is that clamping things to a strict category heirarchy is not a good idea (kids these days and their “tags”), even though virtually all apps will use categories as a (intrinsically heirarchial) menu. Both need to work.

Performance is a bit more ominous. I think maybe depending on full Redland might end up being necessary. I have avoided that in all my software so far because of dependencies (mostly mySQL) which people would complain about. Having mySQL as a dependency to use LV2 plugins is definitely not acceptable, but not using Redland (i.e. just using Raptor and Rasqal) is really, really, really limiting, and slow, and annoying, and just not good. They simply weren’t designed for the kind of higher level stuff I’m doing, that’s what Redland is for.

So, fiddling with Redland to split the stores etc. into dynamically loaded modules so they can be packages up separately is The Solution here. Unfortunately adding yet another project to the stack is exactly the opposite of what I need right now… it would be nice to be able to spend a bit more time on Redland though. My little vendetta getting RDF/Turtle on the desktop depends on having an RDF toolkit that’s lightweight/appropriate enough for installing on user machines, and Redland is clearly the one for the job. I know this is good, powerful technology, and the things it will allow us to do are concrete, tangible, awesomeness; despite what any (usually just plain ignorant) naysayers may think. Having a proper in-memory RDF store (Redland) is necessary for most of these things, and the API is much nicer regardless (plus there’s Python bindings which are, IMNSHO, the single greatest thing ever).

On a related note, I am so incredibly sick of school interfering with my time and ability to work on this stuff it’s not funny. You know your life is fucked up when you do more ‘work’ in your free time than most people do at work. My brilliant solution to this problem? Subject myself to even more of this utter waste of time and go for a Comp Sci Master’s! GOOD PLAN. I’ll be exactly where I am right now, except 2 years more bitter, stressed to death, and old (which at this particular point in life is a really, really relevant factor. Do I really want to waste what tiny shred of youth I have left slaving away at pointless work I despise? No, no I do not.)

I’m not a masochist; just weak. Weak and stupid.