The most popular current Web 2.0 representation is geography: putting everything on a map. It's a powerful thing to do: when we can SEE how close registered sex offenders are to schools and day cares, we have certain reactions about where our psychic sense of "too near" or "too far" meets the legal/phyiscal interpretation of "appropriate distance." A little bit of information, as has been said many times, can be a dangerous thing. This particular offender/schools mash up does not provide a brushing interface that, say, relates re-offender statistics based on various distances from schools to help confirm whether our sense of dread is well-founded our not.
It is with this caveat in mind that, our group has been thinking about how adding not just mapping but temporal mapping might be for a project we have called musicSpace to integrate a variety of musicology sources for easy exploration. More recently in a project called continuum we'd been looking at how to map rich data sets like classical music onto timelines so that the visualization doesn't implode. That is, if there's lots of stuff going on at the same time in a time line, all the info looks like a big blob, or if you zoom out, you lose the surrounding context. Our challenge was to solve the "too much info=blob; too little=not enough information" dilemma. Inspired by that work, we'd like to take what we learned there and think map thoughts.
Mapping Time
What we are calling Temporal Mapping is not unknown but it's not common. to be clear, temporal mapping has one meaning in discussions of disease tracking for instance that doesn't involve visualizations; spatio-temporal mapping has another meaning in computing. The kind of temporal mapping we're considering is more akin to an example from the Land Cover Institute which on a map over a relatively stable geography shows how population density has grown and spread over 200 years. Other work shows how the geography of a place itself (such as a river valley) changes over time.
'Istanbul was Constantinople now its Istanbul" - They Might Be Giants
Our sense of temporal mapping it turns out is more complex than these example because it turns out we are looking at a variety or parameters that change: in terms of locations, borders change; names change and even the geography can change. One way to reflect this change is to use maps that can present borders/locations that are accurate for a given period - this assumes that various places recognize the same borders/place names. Consider the mapping of Taiwan as a political representation issue. To use the music examples, if a composer created something in the 1700s, the borders of the domains were different and the place names may be too, so we need to have maps with borders and place names that are accurate for that time. As we discuss below, there are other issues that come into play when, to coin a phrase, wanting to co-map points that cross times, and thus cross representations of locations.
Even if we don't want to co-map, but restrict ourselves to single maps, there are some challenges: if we know where a piece was composed we map that; if we know where a composer was born we map that, if we know where a composer first performed a piece we map that.
There are a few data subtleties there: do all objects in a classical music repository now need Lat/Long data associated with them, as well as a date? Even there the temporal bit is not so obvious: there are kinds of dates and kinds of locations: how tease these out so they are clear in the UI? so it's clear a person is choosing to see performance dates/locations rather than composition dates/locations. What happens if a work was known to have been taken out and put away over a range of places and times? How is that stored in an object in order to be represented?
If we put aside that question of the back end data representations and UI finesse for the moment, let's assume whatever it is we want to map in music we can map, the more glaring, basic challenges are how both borders and place names have changed not just over the centuries but even within decades. Maps that only map against geography lat/long have it somewhat easier than mapping against historically/politically accurate representations.
And as always, the question of how to represent the information is non-obvious. For instance, how handle multiple names or boundaries for a place? Only show the appropriate name for the specific time? Show all versions to provide context not only of place but between times? These kinds of decisions become critical when crossing domain representations. For example, what happens when looking for a location in europe that produced the most major compositions of the Romantic Era relative to location(s) in Europe of most significant performances in early 20thC. The borders and place names from the 1700s and indeed even between 1914 and 1920 change several times.
So Temporal Mapping is?
Perhaps a fast way to begin to think about temporal mapping in arts and humanities data that involves people, places and times is to be able to accurately reflect these places as they were interpreted both in their times, and in ours, and to be able view these comparisons from any variety of perspectives - comparatively, relatively.
Animation and Insight
A potential benefit of developing temporal mapping approaches for arts/humanities data is in meaning that is communicated through animation: if we can step through the various places by time of where Beethoven worked - see who else was in the neighborhoods at various points, and correlate that with specific works, and perhaps specific historical events and their key locations, can we begin, almost at a glance, to get a new appreciation of a domain space? Do seeing these patterns animated over time and space and politics and whatever else let us ask new kinds of questions - questions that would have been potentially intractable to ask before?
These are early days for our investigations, but from early scenarios domain experts have given us, the ability to step through time, and to see events of interest comparatively across time and space, is a thing devoutly to be wished. These representational desires are driving our current UI research efforts.
Recently, avid's digidesign group released Pro Tools LE MBox 2 mini: a wee (6" * 1.75 * 5 inch, 1.1 lb) usb 1.1 based audio only interface (no midi and again no firewire or "pro" version as there is with the regular Mbox 2's) that includes Pro Tools LE audio/midi recording and editing software that, at 300 USD, promises to put the Pro Tools experience into even more musician's hands. For those who already use existing protools systems, the Mini promises to be an expensive dongle that will finally enable access to Pro Tools LE software while working on the go. Whether it's a price current LE owners will be willing to swallow is another matter.
Pro Tools systems are the industry standard for recording. It is the Microsoft Office of the digital audio studio domain. The LE line of Pro Tools products has let home and indie studio musicians/engineers access the (near) same features as the Pro Tools HD systems found in many professional studios - at a fraction of their professional price. The advantage of using the LE software is that one can easily take audio files made at home into an HD studio for the full bore studio treatment. File exchange is also facilitated: just like word and power point files can be easily swapped. Read any of the discussions on product sites about software musicians or dj's use, and you'll see most of the time in the discussions on technology, pro tools is the final audio mix system of choice - Logic, Digital Performer or Live for sequencing, but ProTools for the final audio mix.
The Pro Tools LE systems come in a variety of configurations, from the $2500 digi002 8 channel audio/midi mixers/control surfaces to the variety of mobile MBox (usb) and MBox pro (firewire) systems, and now the $300 MBox 2 mini. With Avid's acquisition of M-Audio, Digidesign also recently released a special version of the software, M-powered Pro Tools, specially designed to work with certain M-Audio devices with audio/midi interfaces. So, for 279 on top of your instrument purchase you can use Pro Tools software with these interfaces.
The disappointing disadvantage to these systems is that use of the software requires that one of the specified interfaces be attached to the computer when using the software. Forget about whipping out your laptop to edit your work while you're on a train/plane somewhere: unless you have that hardware plugged in, the software won't start. And if you already have a protools system and then get an m-audio, m-powered aware device, can you use that m-audio device to boot up your protools LE software? No. You have to buy the m-powered pro tools version of le to use directly with those devices. Of course you can use those devices with pro tools - when your pro tools hardware is attached.
Think of the hardware interfaces as giant iLoks, or dongles that won't let you access the software without some hardware authorization device attached. At least, i'm guessing this is digidesign's rationale for not allowing paid and licensed users to access the software without the hardware attached. Hence begins the rant.
Technorati Tags: audio, pro tools, technology
Audio is one of the last holdouts for arcane protection mechanisms. While many companies like Ableton and Native Instruments have moved to online registration systems for their software, there are still several key Old School manufacturers that rely on some form of crippling physical authentication. While some companies (apple with Logic Pro is an example) use their own proprietary format USB dongles, ILok's are the major dongle of choice for many in the audio world - and they have a lovely insurance policy if something happens to your iLok - you can pay $30 a year for "zero downtime" to get *temporary* licenses back should your lok be lost or stolen, and then one gets the permanent licenses from the software vendor - somehow - but that only works if the company using the iLok system agrees to that replacement policy.
One of the biggest audio effects makers, WAVES, does not support ANY recovery of license authorizations if your iLok is lost or stolen. Instead, they say "Waves does not offer replacement keys for lost or stolen iLok keys or authorizations. We suggest insuring your iLok key to cover the possibility of such misfortune happening." Does that mean they expect license holders to have to repurchase the software? YES! that's what the insurance is for, stupid: buy new software. This i fail to understand - what i fail to understand is WHY NOT just work like a credit card when it's reported lost or stolen: with a credit card, as soon as you report it lost or stolen, the issuer kills the numbers and issues new ones on new cards. Surely the same could happen with these plugins? Authorization is validated at each use on any machine: if the numbers have been cancelled, the dongle no longer functions.
Plainly there's a business model that says NOT supporting something this straightforward with zeros and ones is in the company's interest, and since Waves has the lion's share of the effects market in big production work, what motivation is there to change? As many many posters on many audio forums note, all waves plugins have been hacked and work flawlessly on the PC (too bad for mac users!) so once again, the only group this copy protection strategy hurts are legitimate users.
But i digress. This is about Pro Tools. As for Pro Tools, their hardware acts like such an authorization dongle, and is equally if not more exasperatingly irritating than a dongle because usually their physical dongle hardware has some heft to it. The MBox 2 Mini is small, but it's not tiny. On the plus side, it has a kensignton lock port on it (try that with an iLok! ha!). And it does offer what's reputed to be a good headphone jack which is nice for editing on the go. So a dongle with some features that may actually be useful when NOT RECORDING just editing.
Don't get me wrong: for someone looking for a decent audio interface that will let them into a Pro Tools space, this could be just great. For those who want midi and more than two tracks on a portalbe interface, there's other MBox's. For those already there with pro Tools who have been wanting a way to edit their sessions on the go, the MBox 2 Mini may just be the dongle to set one free - relatively speaking.
It will be interesting to see how many people who already have digi002's for instance add the Mbox 2 Mini to their gear finally just to get on the go with their session editing - of course, carrying their usb hub, too, so that they can plug in all those platform specific dongles.
The UK Government wants to push through ID Cards to use biometric data to connect the card, its data ("basic personal information") and its owner. Uh huh. While one can theoretically imagine how such a scheme would work (and the govn't is dealing in theory since its own site says it doesn't know yet what the cards will actually be like), you would be hard pressed to find any technologist (not funded by a biometrics company) who would say that such a scheme is practical at scale. Indeed, the summary of the consultation exercise on ID cards, which found largely against the practicality or efficacy of such a scheme is - no longer to be found on the Govn't web site. You can still find news articles quoting various computer science experts who spoke to the committee on the multiple problems with ID cards.
And you'd think that such concerns might be part of why the house of lords chucked out the ID Card Bill yesterday. Apparently, though, they were worried about costs - the fact that they weren't well enough defined by the government. Who knows, maybe that's a really good first act rejection: because if the government comes back with a better cost breakdown, perhaps the House will get to the gnarly question of "how can we trust those figures."
Why would they ask such a question? Because the Government has a lousy track record when it comes to specifying and delivering - no matter what the budget - national IT systems. And if they can't get a national database right on the smaller scale of specialist IT systems like the Magistrates court, Ambulance Services [additional research paper pdf], doctor's surgery systems, the police's IMPACT program or Tax Credits, how on earth can they be trusted to get an even more complex system like an ID registry with databases, specialized hardware for collection of biometric data, specialized hardware and software for matching biometric data, specialized training, and specialized secure documents delivered?
So the question is pretty simple the next time the house of lords gets the ID Card Bill back: even if delivering an excellent ID Card system were possible, and even if there were no questions about the technology, about the biometrics, the database security, the security layers between the system itself and humans accessing it, the hackability of the cards, and never mind the social, moral, or economic issues, or for that matter the political ones about whether or not such a system could even stop a terrorist [look here for a list of all these issues and the organizations that query them], disregarding all that and cutting to the chase, would the UK Government simply have the wherewithall to deliver it?