Nice to see somebody doing their research before buying the desk.
So much better than people buying one, then ranting all over the place because they’d made a false assumption!
All these desks have slightly different features, so it’s important to look closely to make the right decision.
IMHO an offline editor would be the single biggest improvement A&H could make, and I’m guessing, not that hard to do from the iPad app either, so perhaps we’ll have it one day.
Anyway, good luck Grant - maybe let us know what you go for, and how you get on?
Yep - I’ve got a lot of apps for desks at this price point - there to allow me to make comparisons without spending the cash on every desk available…
Much as I love the QU for my own work I don’t think it’s on my list for my current church… (The record to USB stick is the one feature that nearly brings it back)
Mamerica started this column back in 2013/10/18 at 3:40 pm
When I first bought any QUs’ I never even thought about iPads let alone off line editor?
Then through those later ‘near’ 4 years the iPads appeared!
I just can not believe that A & H dont use the Demo mode to build the editor to be saved back into the QU?
There must be some powerful brain storming or marketing happening over a cuppa back in their tea rooms?
Partly because of the lack of offline editor… [If Grant is correct that other brands have this or similar?
And if the QU is not on Bobs list for future mixers?] then someone at A & H needs to be listening!
I know A & H want to promote the iPad scenario so why is the no action? discussion? murmurs about this?
It’s not the offline editor that takes it off the table.
It’s the fact that I know that I have mixed into people’s monitors instead of FOH, I want/need a way to make that very hard for inexperienced volunteers.
At the moment the Expression 1 is top of my list… properly set up it has many similar features to the QU - less good use of the screen, slightly lesser EQ control, more sends, flexible patching from local inputs (so that roving mic can have both speech and singing channels)…
It’s mostly a wash until fader glow. That single feature should eliminate mixing FOH into a monitor or vice-versa.
There is little to no price difference, both have personal mixer options and QuYou style apps, both have digital snakes if needed.
It’s down to little things. For a theatre/festival I’d recommend Qu, but hesitate because of the lack of an offline editor…
I finally have a reason to want the editor. We’ve got a sound guy who is scared of the learning curve. I’d like him to be able to learn to mix QUsd on IPad with the band’s actual settings rather than a blank demo. I could show him custom pages and other features that would make his job so much easier, but the persuasion would be in seeing our actual channel names, channel libraries, etvc. He could practice at home away from the mixer, which I own and cannot part with.
Just want to throw my +1 at an offline editor. I just upgraded from a QU-16 to a QU-PAC and ar2412. I need to do significant routing changes to many, many scenes by doing this switch and I’m crying at not being able to just easily do these changes on an editor.
Yeah… If you’re that close (I’ll assume you are) it is absolute evidence A&H have no intention of either providing help, or to allow a QU editor in the wild, or EVER provide an editor. They know how it’s done, they’ve “had plenty of time” to develop their own, and we’ll NEVER see one – even as an extra cost option.
If I could afford to sell my early QU16 (with the fixable phantom-pop problem, a defect they corrected on later versions, that they say I have to pay for), and my AB168 without taking a bath, I’d dump A&H in a heartbeat, though I do love the console itself.
If nothing else, when asked (over and over) they had have come clean and definitively said “Never Ever!, I may have had some respect left for them. Lying by omission is still lying.
Shame on A&H. For lying about the editor, and trying to stick me with the bill for the phantom-pop fix.
can someone host a Wiki, which collects all known facts about the file format?
I compared to identical scenes. In the file you can see the scene number (4. byte). And that is
the only difference. → if there is a CRC, not all of the file is included in the calculation.
As I do not have access to the Mixer, can someone try the following:
Make 2 scene, keep all settings identical, double check Qu can load it.
Check the CRC at position 0x651C, if it is identical.
Than start modifiying beginning of the file until it fails loading.
I recommend binary search.
By that we should be able to identifying the range for the CRC calculation
To make format analyzing more exciting my files have different length.
Some have 0x6520, others 0x6640. But CRC is at same position.
Yea, a5a5a5 seems to be a section separator. For some reason I always thought of it as marking the end of a section, maybe because I consider the CRC less of a section than the file header. I guess that doesn’t really matter either way.
Could you upload a few of the files with length 0x6640?
attached some files with extra bytes after the CRC. I guess this happens when you overwrite a sceen. Had to rename it to txt as the forum software does not like .DAT SCENE008.txt (25.6 KB) SCENE009.txt (25.6 KB) SCENE049.txt (25.6 KB)
@Rayn meanwhile I’m back with the idea of CRC.
The tricky part is: how do they calculate it?
I have constructed 2 scenes with the same settings, same Name, but different scene numbers , ending up in different .DAT file names. starting with A1 00 FE 06 and the other A1 00 FE 07. They end up with the same CRC. So I guess the first 4 bytes are not within the CRC calculation.
Might be the same for the A5 makers, as there a easily to check, whether they are correct or not.
And for the math: changing scene name from Scene 1 to Scene 2, changes 2 bits, ending up in different CRC. 11 4C 68 A7 and EA B8 BE 74
By the way tricky part was to put all faders to max low, as there could be some “noise” in the position data otherwise.
@daubi I’d need to check the specific way they combine the current crc with the next byte (starting a few bytes after the file start, up until 4 bytes before the file end), but it is roughly the equivalent of crc = lut[byte^(crc&0xFF)] because of their implementation flaw. There might’ve also been a shift in the value used as an index to the lut.
@Rayn I missed your reply.
what makes me wonder: the CRC is 4 bytes long. your propose is byte oriented. And if they use lut (look up table) how to find that one?
I made some test with a python script
no success so far.
to be fair, I even have no glue how the binascii.crc32 really works.
@daubi It isn’t a proper CRC, since the CRC calculated in previous steps isn’t mixed with the CRC for the new byte – the CRC at each step is taken from the lut (256 entries) based on the value looked up for the previous byte (with an xor thrown in for the new byte).