mult.ifario.us

Back in the late 1980's and very early 1990's, I experimented with bedroom music production using a couple of keyboards (an Ensoniq ESQ-1 and later an Ensoniq EPS) and a Tascam four-tracker. (I'm surprised to find that Tascam still makes cassette-based recorders.) To set the technology scene for the very early 1990's, Windows was at 3.1, MacOS was at System 7, and NeXT started shipping the NeXTstation. (A NeXTstation was my computer of choice from 1990-1995.)

I recently started experimenting with music again, and so far, I'm impressed with the improvements from the last fifteen years of advances. (Certainly, the increase in the utility of a computer for making music is orders of magnitude larger than the increase in the utility of a computer for writing documents.)

The first thing that I did was rip a few of my old recordings to MP3s using Audacity via a tape deck connected to a Firewire interface. Next, I downloaded some software synthesis packages to experiment with: Reason, Reaktor, and Max/MSP.

Reaktor was the one that I bought. It offers the standard GUI that imitates the front panel of a rack-mountable synthesizer, and at least from the perspective of someone who shops at Bleep, it comes with a great set of instruments — synthesizers, sequencers, "grooveboxes", effects, and other widgets that defy categorization.

Under the covers, Reaktor provides a visual, flow-oriented programming environment called Core where GUI components (knobs, lamps, level meters, ADSR graphs, etc.), DSP components, MIDI components, various operations, envelopes, LFOs, oscillators, and filters can be wired together and composed into virtual instruments. Better yet, all of the instruments supplied with Reaktor have the "source" included, so tweaking is easy.

Max/MSP was the first runner up, with an instrument construction environment similar to Reaktor's but a much thinner collection of example instruments. It turns out that there's a similar system under development as open source called Pure Data or "Pd" that runs on multiple systems. There's a book-in-progress on electronic music that uses Pd, a collection of "externals" for Pd hosted at SourceForge, and even a tool ("Paradiddle") to bind Cocoa user interfaces onto Pd patches. (Miller Puckette is the guy behind Pd and originally part of the team behind Max/MSP, so the similarity is not accidental.)

As for the second runner-up, Reason has a neat user interface that imitates the front and back of a rack full of equipment, complete with a spaghetti of cables connecting components together, and it's very easy to pile-up enough equipment to convince yourself that $500 in software (not counting the computer hardware to run the software) buys you $100,000+ worth of technology at early 1990's capabilities. Nonetheless, it left me feeling like it was very workstation-ish and subtly constrained.

Now I just need some free time to spend on some compositions...

Ismael pinged me today with an email that he sent to the Apache Incubator list:

[...] Our company [Intalio] would be interested in participating to the Ode project through a donation of the PXE BPEL 2.0 engine and the dedication of development resources to the project. [...]

There is already the Agila BPM project under incubation, and there was recently the contribution of a BPEL4WS 1.1 implementation by Sybase. It's my opinion that adding PXE to the mix should actually help clear things up and shorten the time to market for the combined effort — PXE is a complete implementation of the WS-BPEL 2.0 standard with a great team behind it, and it will round out the set of ideas and concepts that the Twister/Agila and Sybase codebases embody. Bill Flood, who represents Sybase on the OASIS BPEL committee, put it in perspective succinctly:

It's all good news for the community at large!

Now that I can run Google Earth on my Mac (finally), I tried looking up some of the more out of the way places that I've been and was pleasantly surprised to find that trails in some of the National Parks (e.g., North Cascades National Park) are marked! It's hardly a replacement for a good topographical map, but it does help put things in proper perspective. For example, the mountain goats below are standing just about where the trail goes over the pass. (There were a bunch of marmots running around that day, too, but I didn't get good pictures of them.)

 

From some spam today:

Have you ever thought that the only thing stopping you from a great job and better pay was a few letters behind your name?

I finally checked out Zillow today after seeing the NYT article, and the accuracy and inaccuracy of the “Zestimate” surprised me. The details for our current house in Seattle were completely wrong (number of bedrooms, bathrooms, square footage, etc.), as was the last purchase price, but once the details were updated, the estimated value was within $1,000 of the price that we paid. Zillow wasn't out of stealth when we were house hunting, but we did make extensive use of Redfin to look at listings and past sales.

At least from where I sit, I'd use Zillow if I was selling a home and Redfin if I was buying one. Zillow would be useful for setting a price and assessing the values of improvements, although various Seattle-specific strategies (e.g., slight underpricing to encourage competition) would still apply to final pricing. In contrast to Zillow's approximations, Redfin draws straight from the MLS, and the sale prices and dates are dead-on. Redfin also includes the pictures from the MLS for current listings.

Commissions may decrease or switch to flat fees as home prices increase (and services like Redfin's “buy it online” may help force the issue), but I don't know if any amount of Web 2.0 juiciness is going to take away the value of the advocacy of a good realtor. (We had great experiences with Jenny Ames in Chicago and Melissa Veilleux-Kiser in Seattle.)

The kid took her first steps today, about eight of them, to walk from Hien to me. Even without us praising her (which we did immediately), she had a big smile on her face and a definite sense of accomplishment.

During the first few sleepless months, we smiled at and silently cursed anyone who claimed that children grow up quickly, but I'm starting to see what they mean.

This post describes an approach to populating a Java object model from an XML document. It's an approach that I came up with when working on a particular parsing problem.

Updates: A couple of people have mentioned XStream and XMLBeans, but those fail my tests below. XStream is a serialization tool (as its docs say), and XMLBeans was chubby in terms of the size of the libraries. For what it's worth, if I were willing to suffer a large dependency, XMLBeans version 2 looks pretty good in that it provides a token-oriented interface and location information (via XmlLineNumber).

A closet full of clothes, and not a thing to wear...?

My self-imposed requirements were as follows:

• Populate a pre-existing Java object model from SAX events.
• Support multiple XML dialects mapping directly to a single object model.
• Both the XML dialects and the object model are specified a priori.
• Impose zero additional dependencies beyond SAX; ideally, the implementation will be just a fancy ContentHandler.
• Expose SAX location information from the parse (e.g., line and column) to the target object model during construction.
• Expose namespace context from the parse so that expressions like QNames and XPaths in attribute values can be properly post-processed.
• Use programmatic configuration, not properties files or XML or annotations to the schema.

For my particular application, the XML documents would be BPEL processes in either flavor (1.1 or 2.0), and the target object model would be PXE's BPEL Object Model or “BOM”. There were additional requirements around handling extensions, but those aren't directly relevant to the approach that I settled on.

Now, surely someone else has had the same or a similar set of requirements, more or less the same sensibilities, and the altruism to post it as open source...

Of the various approaches to XML binding (the bindmark project has a good list), I didn't find any that fit the requirements. Many tools generate an object model from a schema, and while the generated models don't usually meet my taste for API ergonomics (JAXB 1.0 had a particularly rank code smell when applied to the BPEL4WS 1.1 schema...), that would be one way to go if additional dependencies were acceptable. (The idea would be to use the generated object models as data transfer objects and then maintain multiple mappings onto the internal object model as domain objects.) JiBX looked particularly interesting, but it requires XPP3 and uses bytecode enhancement, which would rule out the simultaneous support for multiple XML dialects without intermediate object models. Digester has approximately the right flavor, but the target object model wasn't particularly JavaBean-ish and location information wasn't exposed.

One of the flaws in schema-driven bindings is that XML schema rarely (if ever) encapsulates all of the semantics of the XML language that it can be used to (loosely) validate, so automated or generated bindings do at most a partial job.

The Idea and Outcomes

So I came up with a different approach. The basic idea was to construct a graph of event consumers that closely resembles the grammar for the XML document and use SAX events to walk the graph. Each edge of the graph is decorated with a function that accepts a single SAX event and returns true or false, e.g., a QName with or without an attribute mask, or a non-whitespace characters event. The edges incident to a vertex are ordered, and events are matched (or not) according to the ordering.

From another perspective, this uses the XML parser like a lexer and the graph like a parser.

From yet another perspective, the idea is rather like Haskell's pattern matching, in which case the whole thing could be looked at as a collection of functions that accept a list of SAX events and return an object. Each function consumes the head event from the list, selects another function to pass the tail of the list to, and adds the result of the call to the current object. (The presumption is that objects know how to add various kinds of children or metadata to themselves.) Of course, Haskell wasn't an option. (And of the two Jaskells, Jaskell has a few too many moving parts in the toolchain for my taste, and Jaskell doesn't have pattern matching.)

My first-pass implementation in Java (PXE's bpel-parser module) did the job nicely but wasn't quite as pretty at the code level as I might have liked, as it required a a good amount of boilerplate. That said, and in-line with the lexer/parser observation above, the boilerplate and transition set could easily be generated from a RELAX NG grammar.

Considering that JAXB 2 looks slick, has a non-regressive license, will be part of both Java EE 5 and Java SE 6, and supports passing through some XML fragments in raw form, it would be a difficult call if I faced the same problem at present. (Like JAXB 1, JAXB 2 doesn't expose location information, but location information can be added to the XML document as content using some SAX tricks, but that's a hack.)That said, the need to support semantics beyond those present in the schema might very well drive me down the same path again.