Hooray, audacity files are XML

Plumbing for the next web, by ian forrester

I’ve been looking for a way to create SMIL files with an editor for a while. Main reason being to speed up the creation of creating podcasts for the Perceptive Podcast client and make it easier for those who don’t understand markup/code.

One of the techniques we deployed during the Visual Perceptive Media project was to export final cut xml out of final cut/premiere pro then transform the lot with XSL/Python/etc to something else more usable. Its something I’ve had in mind for a long time, as you can see with this paper/presentation I wrote 12 years ago.

There was a point when Wmas, could create an editor for our director/writer (Julius) or allow him to use tools he was familiar with (non-linear editor like Finalcut/Premiere). Of course we choose the latter and converted the final cut xml (which isn’t really an official spec) into json using python. We were able to use markers and zones to great effect, indicating the interactive intentions of the director in a non-linear editor. This meant the intentions can exist and run completely through to the very end, rather than tacking it on at the end.

So with all that in mind, I started thinking if I could turn Audacity into a editor in a similar way? Is there a final cut xml format for audio? Thats when I came across this article which made perfect sense – Audacity files are just XML documents, sooo

Structure of a empty project

<?xml version=”1.0″ standalone=”no” ?>
<!DOCTYPE project PUBLIC “-//audacityproject-1.3.0//DTD//EN” “http://audacity.sourceforge.net/xml/audacityproject-1.3.0.dtd” >
<project xmlns=”http://audacity.sourceforge.net/xml/” projname=”blank-audacity_data” version=”1.3.0″ audacityversion=”2.2.1″ sel0=”0.0000000000″ sel1=”0.0000000000″ vpos=”0″ h=”0.0000000000″ zoom=”86.1328125000″ rate=”44100.0″ snapto=”off” selectionformat=”hh:mm:ss + milliseconds” frequencyformat=”Hz” bandwidthformat=”octaves”>
<tags/>
</project>

Just the title ignited my mind, the actual content of the blog is less interesting but I realised I may have a free & open-source editor which runs on every platform and with a bit of XSL magic could be the start of the editor I was looking for? The idea of it being a pipe, which leads on to more is something which fits in the bigger pipeline chain

I also found a GIT project to Parse audio track times from an audacity .aup projects. Its uses XSL to do the processing, so I may spend a bit of time playing with it to make something useful.

Just need to dust off my old XSL development skills… Which reminds me what happened to XPROC (XML pipeline language)?

Google driving…

GoogleDrive

You got to hand it Google, ups and downs

I’ve been looking for somewhere to host my Twitter archive, and I was going to host it at cubicgarden.com but haven’t got around to sorting that out. When I saw Kevinmarks tweeted about hosting your twitter archive on Google Drive, my mind instantly went into overdrive.

Not only is Google drive a storage space but its a active webspace, where you can run scripts.

I haven’t had a play with the scripting yet, but my twitter archive is now hosted on my google drive.

One step at a time, shame you can’t run XSL on Google drive, because I would be well away!!!

24 ways to impress your friends

24 ways to impress your friends site

So I've been pretty quiet about 24ways to impress your friends this year. The reason why is because I've been writing a tip titled Making XML beautiful again to go into the 24ways collection for 2006. The tip centres around a client side XSL transformation on a ATOM feed. I thought this would be simplier that RSS because I would have to create templates to support RSS 0.91, 0.92, 1.0 and 2.0. ATOM 1.0 feeds are also very much a like so a safe ground to start on (although a lot of ATOM 0.3 feeds use a different date element).

The actual XSL took me all of about 5mins to write but the explaining took a good few weeks. I have spell checked it, grammer checked and run it past the eyes of Sheila (my XSL friend). Sheila helped a lot on making it sound less like me talking and more like me writing, but there is still bits of my twisted humour in there. I also wanted to explain the difference between client-side and server-side transformations but decided it was out of scope. As was spending 3 paragraphs on what XSL is, which I finally cut down to 1. There is also something else which has been bugging me while writing the tip. Firefox 2.0, I can not work out if its actually broken when it comes to client side transformations or not. Some people seem to think so, but I'm getting just odd results like the output escaping not working. I've tried to install Firefox 1.5 in a Virtual Machine but I can't get it online (for many reasons). So I'm currently loading up a old Ubuntu Boot CD on a spare machine. I'm sure the comments will come flooding in soon.

Anyway big thanks to Drew McLellan for thinking about me when relaunching the 24ways project this year. Maybe Drew took it to heart when (in a good way of course) I asked why he didn't use XSL for parsing Microformats at BarCampLondon. I was still amazed he used a non rules based language to parse Microformats. It shows talent. Thanks again Drew, I just hope it comes across as well, as the other excellent authors on 24ways..

Comments [Comments]
Trackbacks [0]

RSS as the vaseline that’s greasing the wheels of Web 2.0

Jeremy Keith writes about how everything he uses outputs RSS of some kind which can easily be mashed up. Yes this is pretty straight forward and I hope commonly known now but what prompted me to blog was this bit.

At the recent Take Back The Web event here in Brighton, Rob Purdie talked about RSS being the vaseline that’s greasing the wheels of Web 2.0. He makes a good point.

Over the course of any particular day, I could be updating five or six RSS feeds, depending on how much I’m blogging, how many links I’m posting, or how much music I’m listening to. I’d like to take those individual feeds and mush ‘em all up together.

I think were finally at the stage where its accepted that RSS and ATOM can be like RESTful API's. I remember having a email exchange with Jeff Barr about this and he disagreed. Well I'm sorry but it looks I was right.

What Jeremy also talks about is why I love XSL so much. As long as its valid XML and web accessable I can do something with it. I've been asked to be involved in a special project for Christmas to do with XSL, so look out for that soon.

Comments [Comments]
Trackbacks [0]

Who says the Social scene in London is nothing compared to San Fran?

Socialising at the geekdinner with Dave Shea

What the heck is going on? Next week is insane! There are tons of events going on in London next week. I'll outline the crazyness…

Now imagine if Momo Monday, Girl geekdinner and Pub Standards were all added to the mix! Someone needs to sort this all out. Its too insane that all these events are happening the same week.

So getting serious for a while now. To be fair everything is ending up on Upcoming which is a good thing. I was using Eventful for quite sometime but since most of the events are ending up on upcoming, i'm not going to fight it. So things are getting a little more origanised here but the problem is that the actual event holders are not looking at upcoming first let alone posting them. Then add the extra pain in the butt that you need to sign in to register yourself with an event, not everyone likes that. So actually things are not that rosey. I thought the Jigsaw wiki might be a good idea but it seems few people use it for events. Then I thought Techcrunch UK might bring some calm to the crazyness but nope, its not happened.

I've filled you all in on the context but this conversation has gone on a little longer in the TechCrunch comments on the same subject. The suggestion of using a google calendar by D4rr3ll sounds good but I'm not sure it solves the problem of sign up but it will certainly help with clashes. As he said a XSL would mean anyone could see it on a normal webpage, and yes using the API event.add or event new, it would be possible to automaticlly add it to Upcoming and Eventful.

So I've setup a Google account for London Social events which I'll email around to people who run events in London. The Calendar is here – http://www.google.com/calendar/render?cid=londonsocialevents@googlemail.com. You can subscribe to the RSS here and Ical here.

Comments [Comments]
Trackbacks [0]

Eventful events turned into signs with xsl

How my posters turned out after printing

Its so funny, I tend to shy away from printed media. But I can see the value in some printed content. So anyway this is the result of my XSL which simply takes an Eventful ATOM feed and transforms it into simple XHTML+CSS for printing (next stage would be PDF). Here it is if you would like to do the same before Monday. Please bear in mind this works with ANY eventful event, as long as you take the id of the event and add it to the end of this url – http://cubicgarden.com/cocoon/eventful/poster/{eventful id}. Here's a couple more for the hell of it.

Comments [Comments]
Trackbacks [0]

One of the meetup features I miss

Meetup

I will be first to admit that Meetup.com has some good features, but since they started charging the group origaniser it seems like there has been a move away from its system. The problem is where do you move to? Eventful and Upcoming are my prefered services but there are things like Zevents also. However all of them don't quite have all the features of meetup.

One of the features which I miss from Meetup is the ability to print out signs to attract people to the event when your at the actual venue. Last nights London Blogger's meetup was a small affair but attracted some regulars to geekdinner but I also finally met Jo. Jo printed out the meetup sign and placed it on the long table in all bar one, soho. I certainly miss this.

So I've decide to build a XSL transform to generate one of these for Eventful events. My first thought was to transform the XHTML page which already has microformat data for the event.. But quickly realised that the page isn't XHTML at all, for example my next geekdinner event. So unless I cleaned up the HTML first using something like Jtidy first it seemed pointless. So I started looking at the RSS and ATOM feeds. And there is where I struck gold. In the ATOM feed there is everything you need and more. Unlike the RSS feed which is simple RSS 2.0 with A9 Opensearch and Yahoo Media RSS extentions, the ATOM feed has some google data extention. The schema links no where but contains the event dates, location and more. All defined in nice namespaced elements which means its easy to pull out the data needed for the XSL transformation. I was hoping to adapt the XSL to transform not only Eventful ATOM feeds but also upcoming events. But there syndication is either ical or some odd combined html/javascript yahoo or google export. Which really sucks because its not valid XHTML. I'll post my XSL one I'm done. But I'm also considering a XSL-FO transform instead of CSS and XSL. Although its tempting to use XSL 2.0, I 'm going to resist so people can download it and apply the XSL locally. Humm maybe a simple Greasemonkey script will make this even easier to apply to any eventful event.

So using Cocoon and a simple XSL, you can now see any event from Eventful in a design which can be printed out on a black and white printer and pinned up at the event or before the event. Its not quite the table things I was thinking about before, Instead its a useful A4 poster. To use the service? simply enter the eventful unique code into the url after http://cubicgarden.com/cocoon/eventful/poster/{eventful code}. So here's a list of test events.

Please note you need to view the print preview to actually see the correct poster, because I'm using two stylesheets one for print and another for the screen. Oh and the current XSL is here. Please modify it if you feel the need, its released under a creative commons licence.

Comments [Comments]
Trackbacks [0]

A XSL transformation mindset

Someone asks on Metafilter.

When you imagine XSLT transformations happening in your mind's eye, what does it look like?

Its a really good question and opens up a whole range of thinking about the differences in peoples thought processes. So first Jeff talks about the question.

This is a very powerful question to ask, because ancient, procedurally oriented developers like me sometimes have trouble following the non-linear, pattern-driven processing that takes place when an XSLT template is applied to a tree of XML elements. In fact I have noticed that non-developers sometimes have an easier time with XSLT than do experienced developers, because they don't try as hard to figure out what is happening beneath the covers.

I would kind of agree with that statement. Theres something about XSL and XML which just makes sense in my head. I'm not from a traditional software or computer science background, so I still find it weird to be called a programmer by some of my peers. John wrote this fantastic comment.

My first project with XSLT a few years back was to actually generate XSLT *from* XML and XSLT and forced me to break my ideas of how it worked. When I finally got the whole “it happens all at once” approach, it started to make sense. However, every programmer that I've brought on board to an XSLT project since has had trouble getting out of the procedural thinking and that ends up being the biggest source for their mistakes.

Unfortunately, like MagicEye images, some people just aren't able to unfocus their minds in the right way to really grok XSLT beyond the simplest examples.

I have heard of programmers comparing XSLT to Prolog and even Lisp, I'm not sure how true this is but its certain that you can't approch XSLT in a regular way. Recursion is one of those things which seems to drive people mad. In XSL there's a lot of recursion and declaration which seems to fit the way I think. I always wanted to create a SVG of a XSLT process. So you can see in lines and boxes what templates are being called and add some kind of dimension to XSL. I'm sure its not that hard and even my experiements with transforming Cocoon's Sitemap file into SVG didn't require too much work. Talking about recursion someone posted this nice animated gif of how it all works. There's no douht that XSL requires a different mindset and working with a programming language like Java or Perl will be more of a hinderance that an advantage.

I posted this question to a few of the XSL developers I know and got a variaty of answers. In my own mind I see lots of lines and trees which get broken into branches

Comments [Comments]
Trackbacks [0]

Does presentation matter in a world of RSS?

So Ben Metcalfe asks the question Does presentation matter anymore? This is exactly what me, Miles, Harry and Dave talked about one night over dinner. Honestly I think it does but as Ben identifies its moved around the chain now. If we take it that RSS has a huge audience and that its not changed a lot from its current form (aka no JS, CSS, Ajax, etc in RSS or ATOM) for a moment. The presentation shifts to feed promotion and the news reader style. For example Great News which I'm using for my desktop aggregator supports CSS and I can actually define a style sheet per feed if I want to. This was useful today when Google news was delivering me all the WorldService and ArabicTV stories, as I could use the brief stylesheet to show a lot of entries on one screen. While I use the readability stylesheet for reading Ben's blog and most of RSS content.

But it goes deeper than that, design isnt just about presentation. A designer should have a hand in the structured elements of the RSS feed, the useability of how its pushed and pulled around the internet and the accessability of the feed and its content. Its what I prefer to call the whole process the Flow of the content. Its part of what I do and I feel its part of the emerging role for new media designers. I mean is it too much to ask for a designer to build a client side XSL page for a RSS feed?

Just stepping away from the world of huge RSS audiences now. There something which smart designers understand well. The media, there designing for. web media isnt print media. Sounds obvious, but were talking about the vision for how the site should look and work being thrown out the window. I'm not talking about just browser quirks, screen resoultions and font size differents. I'm talking about the range of toolbars, extensions and the like which deconstruct the website beyond the control of the tightest web designer. Then if you go down the Greasemonkey path, you have something where you can actually share your deconstructions. Smart designers understand and embrace this and actually push for CSS driven sites to make this even easier. There are a few even testing the waters with Client side XSL transformations for all content with CSS for style.

I've included a screenshot of how I currently see BBC news story pages and how its meant to look. I custom built this simple script because it makes loading up bbc news stories from my RSS reader quicker and is easier to read for myself. Others would disagree, but then I would suggest you write your own greasemonkey script.

So back to the question, yes presentation does matter and the role of a designer is very important but like everything, roles shift with the times and media. Branding is another issue which I wont go into right now either…

I found this great little post about WIndows Longhorn/Vista's redline designs. Ryan suggests Redlines are a throw back to another generation of design, and I have to agree. Dactylx asks this question in the comments
I'm down with that idea, but then how do you as a designer communicate how the design should be rendered to a developer? What can we use to replace the redlines? and Ryan replies with a slightly optimistic but good answer.

Here is the first step. Do not separate the teams. There should be no technical team and design team working separately (on different floors or on different continents). They should sit right next to each other and *understand* the problem just as great as the designers. Design is manifested in code, so if the coders don't understand, then the product is inevitable to fail.

I'm once again in total agreement, in my experience the best projects are always when everyone is involved in the problem. Not passed around like a rugby ball on a winters day.

Comments [Comments]
Trackbacks [0]