Reports are part of the original spec for the console, infact there used to be a button in the preferences window. We plan to add them to the system in the future.
The structure of the Wholehog 3 show file is far more complex than the Wholehog 2 was. Because all parameter data is computed and stored using real-world values, developing a tool to import and export data is going to be a very involved process. I doubt that this will happen in the near future, but I'd be happy to get a feature request opened for your request. Can you tell me a bit about what data you're hoping to import and export, what format(s) you'd like it in, and what other consoles or applications you're hoping to be able to work with?
[quote=teerickson]The structure of the Wholehog 3 show file is far more complex than the Wholehog 2 was.’tis true! as i’m certain we’re not discussing the manipulation of actual .H3’s, i’ll assume you’re referring to III’s object model in general.
[quote=teerickson]parameter data is computed and stored using real-world valuesprecisely why i propose using strongly-typed XML. i’m sure someone around there has a poster with all of III’s datatypes hanging in their office (not just the ones available in Fixture “Builder”, i’m talkin about the Texas-sized UML wall of fame!) and i’m almost willing to bet that everything on there can be both expressed and validated with XSD.
[quote=teerickson]developing a tool to import and export data is going to be a very involved process.given all the transactional messaging involved in such a networked system, on top of targeting windows, linux, and whatever the I/OP’s run, i suppose data gets de/serialized... often...
i’ll admit, i’m a little surprised that XML isn’t the method of choice.
but that’s a useless opinion.
looking forward, i’m sure a lot of really great work went into the II to III converter, a branch there sounds... just about right...
[quote=teerickson]what data you're hoping to import and exportquite simply, any and every thing i can get.
except the garbage.
very very few examples of things that i wouldn’t expect to be your problem, but would like to be in a position to take on as my own:
compile a list of cues that don’t follow, wait, or >T, i.e. called cues, then have that compared against yesterday’s show, and provide the SM with not a new cue list, but a very short list of changes, including deletions. sorry, red deletions. at four minutes to half hour. taping tonight? make any fronts that come up come up to at least 30 but no more than 80. make sure the cyc is never at more than 1.2 * the new frontlight level by reducing proportionately. go. on which pages will my template page be partially obstructed? Morpheus Color Faders haven’t been color calibrated?!? well i’ll just propagate my palettes from this handy electronic list of color conversion values, won’t i? dude... my paperwork didn’t just update itself... did it?and, of course, we can’t forget:
are there desk channels that are not used in any cue or scene? it would be great to have the spreadsheet function that obsession and expression havey’all have provided an awesome platform. i thank you. but the data belongs to the people. and we *will* do amazing things with it.
[quote=teerickson]what other consolesi? none. but i’m immensely moved that you thought to go there.
[quote=teerickson]applications you're hoping to be able to work withi suppose the most well-known would be Access and Excel...?
but again, the beauty of XML is it can work almost anywhere. i really can’t think of a more truly portable and universal format. add the right XSLT and your cue list report shows up all pretty on your cell phone...
to be honest, the very first thing i’d do would be to crank out some .NET objects for general use, and then some MSH-PowerShell gak for the quick fixes / info.
I can't claim there would be many but I'm sure plenty of users who would love to have a converter to take show file clips and import them directly into excel. How available is the source syntax for data storage in cues, scenes, palettes, etc? I would be willing to write a converter to publish openly. Of course I've mentioned this before but I'll say again that being able to use shortcut keys like in excel within the editors would be fantastic.
The structure for storing show file data is not public, is very complex, and changes on a fairly regular basis. The data is all binary and is organized for efficient access, not for easy data presentation. Writing a conversion application would be phenomenally difficult without the Wholehog 3 source code.
If you can provide details, or even examples for the type of data and formatting you'd like to have, I can make sure that those requests get logged.
Actually, I'll be in touch with you on that. Of course I caught myself today trying to hit insert when I was working on an excel file. :aargh4: What's wrong with me :fgd:
