(except that this now seems to bork out the Cycling ’74 site – and I
don’t know why it’s putting session information into the URL – so
you’ll probably have to do a forum search for "HSQLDB").

I’ve just modified the package so that it can talk to external MySQL
databases as well as embedded HSQLDB ones, and I’ve build an example
MXJ object which takes SQL statements directly, basically serving the
same purpose as Bill Orcutt’s MySQL external.

This should work on OS X and Windows XP. (I’ve not tested this
version on XP, but the previous HSQLDB version worked.) I would hope
it would work unmodified on a forthcoming Max/MSP for Mac/Intel.

I’ve not thrashed this release very much – I add the MySQL support
this afternoon after having problems with Bill’s MySQL external – but
it’s now running as the backbone of a sound installation I’m
preparing for next week, and seems to be pretty happy.

> Is there a reason why you should use the MySQL solution rather than
> the HSQLDB one?

They’re rather different kinds of animal.

The appeal of HSQLDB is that (i) it’s 100% Java (so 100% portable and
can be wrapped in a single JAR file) and (ii) it can run in embedded
mode, so I designed the first release of the MXJ tools for using it
as a self-contained storage/query solution without need for an
external server.

I added support for MySQL because I wanted to query a MySQL database
which is being populated elsewhere. (My sound/video installation has
a computation engine written in C running on Linux, and the neatest/
quickest way to manipulate the data in Max/MSP was to write some Perl
on the Linux side to punt data into MySQL, and then query it out on
the Max side.)

MySQL seems to be the most popular database out there in hobby and
open-source land; I’ve also used PostgreSQL (and DB2 and Oracle, for
that matter, although the latter two aren’t free) and could be
persuaded to add support for these … if people *really* want to
interface Max/MSP to enterprise-level data stores.

HSQLDB can also run as a conventional server, but it’s not that
widely deployed as far as I can tell, and the embedded mode seems
much more useful.

> I think the Max/MSP/Jitter programming environment really needed a
> series of objects to build a "database narrative" (just to quote
> Lev Manovich’s words)

I’m not quite sure what "database narrative" means…

I’ve been wondering how hard it would be to build a generic (-ish)
graphical database access tool, rather like phpMyAdmin or some of the
Java/Swing clients, in Max, perhaps using jit.cellblock for table
display…

I found the topic really interesting, in particular the elaborations on
database and spatialisation, as I have never thought of connecting the
two this way before:

*DATABASE*. After the novel and later cinema privileged narrative as the
key form of cultural expression of the modern age, the computer age
brings with it a new form — database. What are the origins, ideology
and possible aesthetics of a database? How can we negotiate between a
narrative and a database? Why is database imagination taking over at the
end of the 20th century?

*SPATIALISATION*. The overall trend of computer culture is to spatialise
all representations and experiences. The library is replaced by
cyberspace; narrative is equated with traveling through space ("Myst");
all kinds of data are rendered in three dimensions through computer
visualization. Why is space being privileged? Shall we try to oppose
this spatialisation (i.e., what about time in new media)? What are the
different kinds of spaces possible in new media?

I believe he elaborated on this in Language of new media. I had only
read the first few chapters from before, and haven’t had the time yet to
go back reading the rest of it.

I can’t really comment about performance without knowing at least something about your project. You should try it. I’d suggest, though, doing the SQL statement assembly in Jython rather than passing it through from Max – that way you get to use prepared statements properly and don’t have injection problems (and don’t have to drop into Java).