ASCII Light Cue Parser/Lexer/Grammar

[peternewman]

So a while ago I asked a similar question about the Strand 500 command line here.

 

I'm now looking to do the same thing with ASCII Light Cue files (ALQ), so has anyone done anything already? I'll quote the relevant bits of my previous post as its fairly similar:

 

Bit of a shot in the dark, and I guess I'm mostly looking at people like Richard, Gareth and probably a few other likely suspects, but has anyone ever written a parser or lexer for the 500 series command line syntaxASCII Light Cue files, or written anything about the grammar? Equally are there references anywhere of all valid commands or will I need to dig through the manualdata?

 

I need to parse some basic 500 series commands and output the relevant MIDI data to trigger themdata at a minimum, and do a bit of processing on it, so while I realise I could just knock something up quickly and dirtily in Perl, I thought the future potential for a full parser/lexer and further processing of these files could be quite interesting.

 

If the above was all gobbledygook (and you want to know more), have a look at Parsing and Lexical analysis on Wikipedia.

 

So far I've just got something working which accepts a group with channel and/or attribute contents, there are still a few bugs in it which need ironing out, as well as support for the rest of the file, and actually doing something with the data, rather than just effectively validating a file someone else has generated, which is obviously a bit pointless apart from to test the grammar.

 

So any offers, has anyone done this already, does anyone have anything that is crying out for this kind of code to work with it?

[peternewman]

Well I've now got the groups part of the file parsing and into a usable format. The rest of the file is hopefully just a grammar extension away.

 

Out of interest does anyone know if there is any documentation/guides on the format, I'm assuming its supposed to be fairly open, as its designed to allow interchange between consoles isn't it?

 

I should probably have added some comment to my first post that clearly some manufacturers will already have grammars or similar for parsing it, but I appreciate they might not want to just give them away for free.

 

A concurrent post has been automatically merged from this point on.

 

I've just had more success Googling for "USITT ASCII protocol", including hits on our very own wiki here, which I should probably have checked first! For anyone else who finds this thread in the future, the original standard is unsurprisingly quite useful.

[Tomo]

The original USITT standard is 'mostly' followed by Strand Showport ALQ files - but they did add quite a few extensions of their own to support moving lights, tracking, movefades etc.

(I'd advise that you ignore the bit where the standard says only to parse the first 10 characters of keywords. Pretty much everyone ignored it.)

 

Strand give a summary of their extensions here - but it is incomplete.

Unfortunately there is quite a lot of very important data that's totally missing from Strand ALQ files so there's a lot of guesswork involved, and IIRC they aren't particularly internally consistent.

 

Congo and SmartFade show files are actually native ASCII Light Cue formats (with lots of extensions) - and it may surprise you to find that Congo v6 show files actually explain what the extensions to vanilla USITT ASCII mean.

 

A couple of years ago I wrote a Highlighter for the ConTEXT Programmers Editor which you might find useful - it's attached to this post on the ETC Community Forum.