drobilla

Opinionated dichotomies in science

David Robillard — Thu, 18 Sep 2008 16:12:47 +0000

Computing is the only real science. The rest can be simulated.

Iteration in Scheme

David Robillard — Thu, 13 Mar 2008 19:02:34 +0000

Thoughts brought on by using SWIG to make Scheme bindings for C/C++ code:

In Scheme, being a LISP, pretty much everything is usually a list. This is great and makes for elegant code, but as a data structures guy I cringe to see the ridiculous amount of O(n) searching done in LISP code. Why is the underlying structure (a list) a dependency of the code using it? Lack of abstraction: car and cdr only work on cons cells, and lists are made of cons cells - period. This sucks for plenty of reasons (the one that encouraged this rant is making Scheme bindings for C++ code).

Say you want to expose a C or C++ list in Scheme. To be really useful in Scheme, it will have to work with car and cdr. Luckily any list has the concept of ‘get the value at this position’ (car) and ‘get the next position’ (cdr). For C++ the position is an iterator, car is *, and cdr is ++. Unfortunately making ‘nice’ (ie typical and un-weird) Scheme bindings for these means you literally have to duplicate the entire C++ list and build a Scheme list out of it, because there’s no functional abstraction going on here, and the type system is nonexistant.

I guess this boils down to a rant about needing iterators in Scheme. I cringe at sounding so much like an OO “patterns” kind of guy, but there it is :)

Lets say our Scheme dialect has some a type system with polymorhism. Scheme code is generally something like:


(define (do-something list)
  (something (car list))
  (if (not (null? (cdr list)))
    (do-something (cdr list)))

(define a-list '(1 2 3 4 5))

(do-something a-list)

Rename car “get” and cdr “next” to avoid confusion, and use an iterator:


(define (do-something iter)
  (something (get iter))
  (if (valid? (next iter))
    (do-something (next iter)))

(define a-collection (whatever))

(do-something (start a-collection))

The idiom for do-something (the fundamental LISP idiom if there ever was one) is the same. The only difference is the call to do-something must pass an iterator, here with the start function. Slightly unfortunate maybe, but the benefits are huge:

Common list-like iteration for all data structures (e.g. trees)
Different styles of iteration (use reverse-end instead of start and have do-something work in reverse without modification)

I suppose since I’m assuming a stronger/better/faster Scheme dialect with a good type system, a collection could just automatically convert to the ’start’ iterator, and the calling code could even be the same if you just want classic LISP style code. I’m a huge fan of LISP style languages (mostly because the code is a simple list structure itself), but there really needs to be an abstraction between the underlying data structure and the code that uses it.

DOAP replacing AUTHORS/MAINTAINERS/etc

David Robillard — Fri, 18 Jan 2008 16:25:06 +0000

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:




  
    2006-02-17
    
    Apache Ant
    
    
    Java-based build tool
    Apache Ant is a Java-based build tool. In theory, it is kind of like Make, but without Make\'s wrinkles.
    
    
    
    Java
    
    
      
        Apache Ant 1.7.0
        2006-12-13
        1.7.0

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

@prefix rdf:  .
@prefix :  .
@prefix asfext:  .


    a :Project;
    :created "2006-02-17"@en;
    :license ;
    :name "Apache Ant"@en;
    :homepage ;
    asfext:pmc ;
    :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 ;
    :mailing-list ;
    :download-page ;
    :programming-language "Java"@en;
    :category ;
    :release [
        a :Version;
        :name "Apache Ant 1.7.0"@en;
        :created "2006-12-13"@en;
        :revision "1.7.0"@en
    ];
    :repository [
        a :SVNRepository;
        :location 
        :browse 
    ] .

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

My Top 10 Albums of 2007

David Robillard — Wed, 02 Jan 2008 05:37:37 +0000

Just kidding.

If you can seriously make a top 10 albums list for an entire year, you aren’t listening to nearly enough music.

Other People’s Software

David Robillard — Mon, 06 Aug 2007 18:31:14 +0000

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 space intentionally left almost blank

David Robillard — Mon, 23 Jul 2007 00:26:36 +0000

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.

Fasting is hard

David Robillard — Mon, 25 Jun 2007 03:51:43 +0000

Made it 3 days. So I’m weak.

Ardour: back on track. Maybe.

David Robillard — Sun, 24 Jun 2007 16:00:10 +0000

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?

The hard part

David Robillard — Wed, 30 May 2007 02:46:31 +0000

Just got back from the co-op, where I was for 3 hours and still didn’t get my bike completely assembled (close though). Also managed to wreck a lot of the paint in the process :( Spray painting a bike definitely makes for a fragile paint job.. oh well. I guess if anything gets bad I can just touch up spots. Perfectly smooth paint is overrated anyway.

I did score nicer pedals and a saddle though, looking pretty pimpin’ if I do say so myself; but I’ll have to wait ’till thursday to go on the maiden voyage…

Back to the Hack

David Robillard — Tue, 29 May 2007 17:58:49 +0000

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