Arnt Richard Johansen's home page

What I was trying to do, was to do keyjazz on vkeybd, feed the MIDI events into QMidiArp (an arpeggiator), and use the arpeggiated sequence as input to Alsa Modular Synthesizer (Ingen seems to be more powerful and easier to use, but it has some... issues, that prevent me from running it successfully).

QMidiArp seems to be the software arpeggiator on Linux, but unfortunately, it wants to talk to ALSA MIDI interfaces. That is, it will only transmit events to /snd/seq or whatever, where an actual hardware synthesizer should be connected. Patchage shows no output streams that can be subscribed on QMidiArp, only the input (which can easily be connected to vkeyb).

It was part 10 of the Linux MIDI howto that spurred me on to a solution. There is a program called aconnectgui (available in the Debian/Ubuntu package of the same name) that, unlike Patchage, will show you the outputs that correspond to hardware devices. Just start it up (after you have started all the programs that will be in the pipeline), connect the output of vkeybd to the input of QMidiArp, connect the first output of QMidiArp (the one corresponding to ALSA port 0) to the input of ams, and there you go!

[Sunday, Mar 23, 2008 @ 14:11] | [tech] | # | G

It's been about a year and a half since Mark Shoulson and I started trying to make a program that could compile blazons into graphics. This is not a new concept — Robert Billard wrote a quite powerful blazonry program for Windows called BLAZONS! (which no longer seems to be supported, alas). As early as 1994, Daniel V. Klein suggested blazonry as a forerunner of graphic definition languages in his USENIX talk From Blazons to Postscript.

Finally, the blazonry compiler, which we have called pyBlazon, has gotten to a state where it is not directly embarrassing to show to people. Last Sunday, Mark posted an announcement to the sca_heralds LiveJournal community, with a link to the project's makeshift homepage and online demonstrator.

Currently we are hashing out which free licence we are going to release it under, and Mark is preparing to host the project on Google Code.

Some points of note:

• Blazonry as a formal jargon may at first glance seem completely rigid and well-defined, but in fact it is large and open-ended. None of us are artists, so a rule of thumb is: if it can be made with just a few SVG primitives, we have it; if you have to draw it in a vector drawing program, we don't. So don't expect the compiler to know what bears, reindeer or horses are. Also, there is no ISO or W3C of heraldry that tells you which charges you can or cannot use, and people invent their own freely. To make a drawing of a “winged sea centaur” (as in the arms of Stephen Coombs) without ever having seen one, you basically have to be a human or have super duper body-part exchange algorithms.
• Also because of impatience, we are using the somewhat underpowered PLY library for parsing (a yacc/lex clone for Python) rather than doing the right thing from the beginning and using something like ANTLR. This means that some perfectly-valid blazons will not work, and have to be reworded. More details under Known Issues on the project page.
• Some arms still look horrible, either because they are basically a special case, or because they are plain old bugs. An example of the former is ermine fretty gules; an example of the latter is azure within a bordure invected argent.
• The SVG is very hairy. Basically, we are wrapping stuff into many layers of transforms rather than rewriting the SVG in memory, simply because that's easier and makes for rapid prototyping. The upshot of this is that not every program that claims to be able to display SVG can render the output of the blazonry compiler properly. Currently, only rsvg is guaranteed to work in all cases. Batik and Opera also does a favourable job. Mozilla Firefox? Forget it.

[Friday, Mar 07, 2008 @ 20:03] | [language] | # | G