VST (Virtual Studio Technology)

VST is an interaction protocol for music generation software. Here's a neat, very simple VST host called VSTHost. The current version 1.5.4 is closed source, with the latest open source version at 1.16k. (He got tired of people ripping off his features without crediting him - can't blame him for that.)

I ran across this at all because the Windows-native version of ZynAddSubFX is VST-capable and bundles VSTHost. ZynAddSubFX is a Unix music mixer, open-source. I ran across it from a short article summarizing Linux music software, which I turn had found on a search for "open source composer software" after seeing references to Mario Paint Composer for building 8-bit game music, along with a masterwork of the medley art here. (That must have taken forever to do.)

So that was my recent music software trajectory.

Enterprise Integration Patterns

This is very cool.

yEd diagrammer

Wow. This is what a fantastic tool looks like. yEd basically looks like magic. But if you really want magic, look at the gallery.

Making sure crypto remains insecure

Heh.

Basic tips for writing Unix tools

Here. Except really I'd like a superset of Unix-y functionality. Wouldn't it be nice to have the same kind of tinkertoy approach but with SQLite or something? (Kind of where my SQP is going. Slowly.)

The semantics of event schedules

I seem to be stuck in survey mode tonight - and ran across this groovy little lightweight event scheduler from the Czech Republic, EasyTime. And really, event scheduling is pretty ramified if you start really thinking about it. When I was working out the basic feature list for the wftk, I sort of intuited that an event scheduler would have to be part of it - but seriously, you could do worse than looking at the feature list of EasyTime.

Rich command shells

A very nice overview of what's out there at the moment (with history). I keep thinking I want to do this with SQP, but I'm still just not sure how it should look. (Probably the notebook thing.)

(Note to self: merge CLI and command line tags - they're the same thing...) (Or are they?!?)

Also, holy schemoley - xiki: xiki.org/screencasts/

Article up, and also: exegesis and code analysis/understanding

My first article kinda-sorta based on an exegetical approach (of my own prototype code) is up on the Vivtek site, and the six-day code rush to write code to build the article from a note database has really whetted my appetite for more of the same. There are all kinds of exegetical efforts I want to make, getting into code reading in a big way.

So I trolled around Google for salient things. Here's a list of interesting things.

• TipsForReadingCode at c2.com was quite helpful as a set of ... well, tips for reading code.
• Code comprehension tools at grok2.com; the vast majority of this class of tool is closed-source and rather expensive. I think this is largely because large codebases are not typical for open source projects, but rather enterprise code, and enterprises have the money to pay for expensive tools. That's my reading, anyway. But:
• cscope is a venerable tool for static analysis of C code, anyway, and has been perverted to handle other large-scale grep-like analyses of large numbers of files. The tool itself may or may not be something I'm interested in, but its approach is probably pretty valid.
• cflow is another flow dependency analysis tool, also open source.
• Perl is, as always, a special case.
• Well, what about static code analysis in general? Here's another list of tools.
• There's a clang-based analyzer.
• This moribund project on code "aspects" looks fascinating.
• Finally, a book on pattern-based OO refactoring, which also looks pretty fascinating.

So, as always, lots of people are doing things tangentially related to what I want to do, but nothing is 100% there - because what I want to do is an extract-then-literate-programming kind of thing. We'll see how much sense this approach makes. Wish me luck.

Stamplay: back-end development by drag-and-drop

Here we go, folks. The future. High-level descriptive language (visually expressed) for website construction by component. Exactly what I was thinking about three years ago, only done slicker than I would have managed.

Code Browser

A folding code editor. I think I'm going to evaluate it.

Naive Bayes and text classification

An introduction.

Scratching the surface of German NLP, from ParZu down

Back in June, looking for parsers for the German language, I ran across ParZu, which is from the University of Zurich. Test sentences thrown against its online demo were translated handily, and all in all it's a convincing parser, so I'm going to be working with it for a while to get a handle on things. It is written in Prolog.

For the past three days, I've gone down the rabbit hole of NLP tools for German, starting from ParZu. There is (of course) a vast amount of previous work, and it's really difficult to get a comprehensive grasp, but this post should at least link to some of it, with initial thoughts, and I can go from there later. I had considered writing an article, but honestly none of this is sufficiently coherent for an article. There's kind of a threshold of effort I expect from articles on the Vivtek site, and that's not there. Yet.

OK. So ParZu can work with any tool that delivers text in a tab-delimited format (token-tab-tag) using the STTS tagset (Stuttgart-Tübingen TagSet, if you were wondering). My Lex::DE can already be converted to generate some of these, so my best bet at the moment would simply be to continue work on Lex::DE and feed it directly into ParZu.  Even better, of course, would be to do this online by talking directly to Prolog, probably ideally through HTTP to avoid 32/64-bit process boundaries. More on this notion later. The cheap way to do this is just to kick out tagged text and go on.

The output from ParZu uses the CoNLL format, which seems pretty straightforward.

Which is all very nice and self-contained, but how do the Zurchers do their tagging? I'm glad you asked! The main tagger is clevertagger, which works on the output of Zmorge. Zmorge is the Zurich variant of SMOR, which is the Stuttgart morphological analyzer, although active development seems to have moved to Munich.

clevertagger has a statistical component that uses CRF (Conditional Random Field) training to judge, based on the Zmorge lemmatization output, which POS is most likely for the word based on your corpus. You can use either Wapiti or CRF++. The point of doing this is to eliminate POS amibiguity (or to quantize it? but no, I think it's a disambiguation step), which is what I hope to use Marpa to do directly - instead of providing unambiguous parts of speech, with Marpa I'll be able to provide alternatives for a given word, and disambiguate after parsing. Well, that's the idea, anyway - but that's going to take some effort.

(Note, by the way, that since ParZu is coded in Prolog, I can probably cannibalize it relatively smoothly to convert to a Marpa grammar, so none of this effort will be lost even if I do switch to Marpa later.)

Anyway, the CRF thing leaves me relatively unexcited. It would be nice to take an aside and figure out just what the heck it's doing, but that's pretty low priority.

Zmorge is based (somehow) on a crawl of the Wiktionary lexicon for German, and uses a variant of SMOR, SMORlemma, for the meat of the processing. I'm unclear on exactly how this step is done, but I do know that SMOR has a lexicon that is read into the FST on a more-or-less one-to-one basis, so I presume that Zmorge is putting the Wiktionary data into that lexicon, and then using updated rules for the rest of the morphological analysis. It would take a little exegesis to confirm that supposition. Maybe later.

SMOR and SMORlemma are both written in an FST-specific language SFST, which is just one example of a general FST language. It's roughly a tool for writing very, very extensive regular expressions (well, that's nearly tautological, in a sense). There are other FST-specific languages originating in different lineages, including OpenFST (developed by Google Research and NYU), AFST (an SFST fork developed in Helsinki - notice that a lot of the original FST work in NLP was done in Helsinki), and the umbrella library that sort of combines all of the above and some other stuff as well, HFST (Helsinki Finite State Technology). Overall, there's been a lot of work in finite-state transducers for the processing of natural language.

There are some tasty-looking links proceeding from the OpenFST project, by the way.

From my point of view, what I'd like to do might consist of a couple of different threads. First, it would be nice to look at each of these toolsets and produce Perl modules to work with them. Maybe. That, or possibly some kind of exegetical approach that could approximate some kind of general semantics of FSTs and allow implementation of the ideas in any appropriate library or something. I'm not even sure.

But second, it would be ideal to take some of the morphological information already contained in the various open-source morphologies here (note: OMor at Helsinki, which aims to do something along these lines, and of course our old friend Freeling) and build that knowledge into Lex::DE where it can do me some good. How that would specifically work is still up in the air, but to get good parses from ParZu (and later from Marpa), it's clear that solid morphological analysis is going to be crucial.

Third, I still want to look at compilation of FSTs and friends into fast C select structures as a speed optimization. I'm not sure what work has already been done here, but the various FST tools above all seem to compile to some binary structure that calls into complex code. I'm not sure how necessary that is - until I examine those libraries, anyway. Also, I'd really like to get something out of lemmatization that isn't a string. Those structures bug the hell out of me, because I still need to parse them again next time I do something. I want something in memory that I can use directly. (Although truth be told I have no idea whether that's premature optimization or not - until I try it out.)

Fourth, there are other POS systems as well. One that naturally caught my eye is hunpos.

So that's the state of the German parsing effort as of today. Lots of things to try, not much actually tried yet.

Update 2014-09-30: A closer look at the underlying technology of ParZu, the Pro3gres parser originally written for English, as described in a technical report by the author, has me somewhat dismayed. I'm simply not convinced that a probabilistic approach is ideal - sure, I might be wrong about this, but first I want to try the Marpa route. Yesterday I sat down to try parsing something with ParZu, and found myself writing an initial Marpa parser for German, working from my own tokenizer (which, granted, has absolutely horrible lemmatization and POS assignment). I think I'm going to continue down that path for now.

That said, SFST is a fascinating system and the German morphologies written in it are really going to come in handy - so I might end up using that before even considering the parser level.

Interesting simple workflow tool

I don't have much time to look closer, but tasklet looks pretty slick.

Simulated annealing in R

With a Web interface, no less!

dyad.c

dyad is a lightweight asynchronous server framework in C. Which is pretty neat!

Videogrep: automatic supercuts using Python

This is a cool little thing! [github] It searches subtitle files and then uses the moviepy library to splice together video based on the subtitle timing. Neat!

Plagiarism detection competition

This is cool: PAN is a yearly contest for plagiarism detection. Definitely an interesting task to look at for NLP.

QPDF for PDF transformations

Neat PDF transformation utility.

Machine learning technique flowchart

Another flowchart for choosing between machine learning techniques.

Man, posting has been thin on the ground lately - our summer in the States was fantastic, though.

Bot becomes trusted member of social network

So some guys in Italy were doing research in social networks and found surprising behavior when their bot's regular visits to people were noticed. Turns out people could see that and responded by trusting the bot, so they started making random recommendations, which people who trusted the bot responded to quite well.

Social aping online can be incredibly simple (on the Internet, nobody knows you're Eliza) and as always I want to extrapolate to a bot that can operate a simple small business.