drobilla

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!)

So I forgot to take a before picture of this bike, meaning it will never make a decent little blog-photo-roll-ongoing-project-thingie (which could probably use a coined word, for the record). Damn.

… is one of those products that works just a little bit too well to not be weird.

So, I bought a bike. I’ve been on a mission to find a decent road frame to convert to fixed gear, but havn’t found anything yet (late in the spring to find bikes, and this city sucks). I did stumble across a shitty old ‘64 CCM cruiser at re-cycles though, so that’s going to be my painting project in the mean time.

Spent a few hours last night with some steel wool getting the rust off the exposed metal parts (and then a few hours cleaning black crap off my hands..), looking way better now. This thing needs new wheels and tires (whitewalls, natch), but they’d probably be worth way more than the bike itself (payed $75).. we’ll see. Fixed gear project (if I ever find a frame) is going to need some money, so probably not very smart to dump money into this thing.

More important, performance-oriented serious cyclist things need to be figured out first, like colour, cool lookin’ handlebar grips, and finding whitewalls. Black and army green is the winner so far.. this thing is one of those frames that begs to be painted in some 50’s pastel teal sort of colour, but I’m not exactly the kind of guy who rocks a teal bike.

I should probably be getting my computer situation sorted out and start dealing with SoC stuff, but oh well. I need a hobby that doesn’t involve staring at this *#@&% screen 16 hours a day anyway.

The time when everyone finds their freedom, and finally leaves Ottawa for the great beyond (i.e. Montreal or Toronto)

… everyone except me. Damnit.

Woo, it’s May Day.

Revolution?

Nope.

Damn. Same time next year?

It’s a date, Comrade.

In related news, gnats completely ruined my day today. They will be first against the wall.

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…

that is the question.
Whether ’tis nobler in the mind to suffer
The slings and arrows of outrageous workload,
Or to take arms against a sea of troubles,
And by opposing end them? To graduate: to sleep;
No more.

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…