[DocDocDocDocParticipant]

Dante is not really cross-manufacturer since all Dante hardware contains chips by Audinate. And Dante to my understanding does not define anything concerning gain control, thus manufacturers all have their own incompatible solutions again.

AES67 is likely to be a good option for the future, since it is a simpler standard and implemented in all recent Dante chips (but not in software such as Dante VIA and Dante Virtual Soundcard). Doesn’t feature gain control either. Which is somewhat flabbergasting, since it’s technically really not so hard compared to realtime audio transport.

Seeburg has recently introduced AES67 for their network-equipped active speakers. Makes sense to me. L-Acoustics has announced to go into the AES67 direction for their latest controller amp in May this year.

[DocDocDocDocParticipant]

I’d be interested in knowing more exactly where A&H consoles use which bit depth. The attached PDF I found in this thread makes sense to me. As far as I understand it, integer arithmetic guarantees fixed processing time, while floating point operations can vary depending on the data (=audio), thus needing more latency for safety. DAW users of open source plugins, some of which are programmed badly, know the issues of denormal numbers. In this special case, numbers very close to zero blow up the processing power requirement of a plugin and all of the sudden after the end of the song as the reverb fades away, CPU load pumps up as hell. It is a somewhat tricky issue that is for sure avoided with integer computations.

What bothers me is precision for low volume stuff. Yes, 56 or 96bit accumulators. Right. But if you don’t feed these properly, how low will your bit depth drop?

I do a lot of live streaming these days and this means I go digital from the ADs right through to the receiver’s device on the other side of the Internet (except for monitoring). I use a digital broadcast limiter that boosts the signal by 15dB internally, then limiting safely to exactly-1dB (so basically it’s a 15dB headroom thing). It turns out that some mixing engineers who grew up with analog hesitate to drive their digital consoles “hot enough” in order to a) seize the ADs not only in like 12 bits of range and b) provide enough output for the broadcast.

So for those shy guys it would be nice to know how the A&H consoles fare when not actually using their 56 or 96 bits, but way below. Floating point would just make the issue go away, shifting the precision behind the comma, so to say.

Concerning me & myself, no trouble getting hot on the inputs. 😀

[DocDocDocDocParticipant]

I regularly use a Qu16 which isn’t mine, and I’m trying to get an SQ for myself. And I subscribe to the wish: De-Esser, please! And/or a Dynamiq EQ of some sort. Actually the latter could be enough, since it can be used as a De-Esser.

I’d even pay for this as an extra plugin, I guess.

I hope some update will bring this as mentioned above.

[DocDocDocDocParticipant]

I have never seen the iRig Blue Board in real life. But from the description, I read: You need an app or software for iOS or OS X that converts the button presses on the board into MIDI messages.

OK, you cannot control the Qu Apps this way. But you could control a Qu console. In this case, you would need to “virtually wire” the Blue Board App with the Qu console. I think the Qu provides a MIDI driver over the network for OS X, which means on OS X you should have a) the Blue Board as virtual MIDI connetor and b) the Qu console as virtual MIDI connector. And hopefully some means of actually connecting them. I do not use OS X so I can’t tell.

It is also likely to work via the USB/MIDI of the Qu console. Since the Qu is class compliant, it might show up as MIDI device in iOS when connected via the camera kit (for old iOS devices, newer ones I don’t have). However, the “virtual wiring” on Mac products again…

And then of course you’d have to teach the Blue Board App all the MIDI commands.

Just my educated guesses/5¢.

Best
Doc

[DocDocDocDocParticipant]

Actually it would be cool to have a “distro” for the foot switch based in piCore. Something you simply copy to a SD card using dd on the command line and then let it rumble. I think this would make it easier for many people and enlarge the user base. However, there are 2 things to solve: 1) generating a unique SSH key on first startup 2) getting one user account set up properly (or have a default user with default password, which is… well, a backdoor in many routers, still 😉 Mh could work if the user is forced to change the password on first login.

[DocDocDocDocParticipant]

Mh, so there is a “proper” shutdown routine via the quPy.sh script. However, people won’t do that with a foot switch. As described in my blog post about the project, I used piCore Linux (the SSH variant, that comes without X11/graphics). One hassle but also but advantage of piCore is that it never stores stuff to the SD card. The hassle is that things need to be unpacked/loaded from the SD card on startup (which is slow) and that this probably needs quite a bit of RAM since all data end up in RAM disks. The huge advantage, however, is that it never performs any write access to the SD card, unless you issue a special command. Resulting in: a) damage of the SD card is unlikely, since SD cards get “spent” mostly on write access b) you don’t need a proper shutdown because the system cannot leave behind corrupted file systems (since it never leaves behind anything anyways) – simply pull the power and you’re safe.

[DocDocDocDocParticipant]

@zueri: Well, since the stuff is open source, I can’t keep you from continuing anyways. 😉 Beware that there is code that is not really open source (it says so in the headers/comments of those files), so you need a solution for that on the long run.

@Keef: config.py indeed needs the IP address. This could be improved by a quick scan on the local subnet which should work for almost all cases.

The dirname thing: This is nothing more than a bash command that finds the name of the current directory. It ensures that from which working directory ever you start the script, it knows where it lives itself.

If I remember correctly, I used quPy.sh as part of the PyCore Linux system init structure. (I’d need to log into my foot switch to check.) Basically, it attaches STDIN of start.sh to a FIFO, so that it later can send a shutdown command via that FIFO. startup.sh redirects it output to the system log.

The purpose of this: a) getting the foot switch software up and running on system start b) being able to later on log into your foot switch and monitor the debug output of the code on via the system log.

I think quPy.sh does not use the dirname trick because I symlinked it from the system init directory structure of piCore Linux, so dirname would think the script lives in some other place.

During development, you would simply run python ./App.py as root.

@zueri: I am not a regular user of Github. Could we continue this rather detailed technical discussion there? If so, please make a start and feel free to copy this forum post here to an appropriate place.

[DocDocDocDocParticipant]

Oh and by the way, I found that some more recent versions of the Qu-App can actually trigger the user defined keys, so for those who want to start their own foot switch project from scratch, this might be a lot easier. However, I’m not sure how precise the tapping of delay tempo “over then net” works in the end. I wasn’t satisfied with the experience on doing this via the iPad.

[DocDocDocDocParticipant]

Keef, cool to hear that the stuff works for somebody else too.

The code linked below my blog post is still the latest version I have. I did this project in between two jobs when I had plenty of time… It would still be great to have the delay time in the opposite direction (qu->foot switch) implemented but I can’t find the time and motivation at the moment. After all, the stuff works for my purposes.

Of course, I am willing to accept contributions. 🙂

Concerning wireless, this for sure is a good idea and I’d love to have it, too. I got some WLAN USB key, but for some reasons I didn’t manage to get it to work with the Pi and also it is not very sturdy. Furthermore – at least in Germany – old wireless mics are now forbidden since they re-assigned the frequencies to mobile phones and stuff. So people are going for the more recent 2,4Ghz wireless audio which conflicts with WLAN. So, if you use WLAN, be it with the iPad or this foot switch, better go for a solution that can use the 5GHz band. (I recently had two wireless mics killing my entire WLAN communication with the ipad… grrr!)

[DocDocDocDocParticipant]

Guys, all of this is speculation, but I think it should be possible to use the QuPac as digital stage box. The thing is: the Qu-series already features sending out audio via dSnake, that is for the personal monitoring system. However, I guess another Qu cannot receive these data.

The question always is: do you want some kind of trick or hack? Like using the monitoring system in a funny way? Or would you go for using the QuPac like the official audio rack, simply like “behave like a audio rack and broadcast all 22 channels”… or would you go for the big thing, like in the oldschool 01V96i series, and even implement chaining up two Qu16 mixers to one large thing? (You can connect one 01V96 to the other via ADAT and chain them up to a 2×40=80 channel-console)

As for control surfaces, I agree. But hey guys… if I were A&H, I’d try to sell you an iLive system, if you want a separate mix rack and a control surface. 🙂

[DocDocDocDocParticipant]

So, here we go with the blog post about the DIY foot switch, including schematics and source code: https://zwei.drni.de/archives/1553-Kick-the-Qu-A-DIY-Foot-Switch-for-the-Allen-Heath-Qu-Series.html

[DocDocDocDocParticipant]

Hi there,

for all those who thing the DIY foot switch is just some kind of powerless phantom, here’s a little video demo:

Ive been working on a blog post including source code and schematics but it has been delayed by months by a real bunch if life’s obstacles… hoping to get it done finally in the next couple of days!

Best
Doc4

[DocDocDocDocParticipant]

Thanks a lot, Boum2, that did the trick!

My DIY foot switch (tcp/ip, wired) now works simultaneously with the iPad with 1.7. That’s a feature I’ve been longing for! Great work, A&H!

[DocDocDocDocParticipant]

Dick, yes I got your point with the RTA. I’m gonna try that. Btw, Voxengo SPAN (freeware, mentioned earlier) has a very simple correlation meter that does the job for most cases. It’s just that I prefer not to drag around extra stuff like laptops or polarity XLR adapters and stuff. I’m constantly trying to own and drag around less stuff. 🙂

[DocDocDocDocParticipant]

Mh, a polarity switch on the mix outs would be another feature request for the Qu series! After all, it is a very cheap operation in terms of CPU time (n*-1, could perhaps even be done with some bit flipping/bit shifting? (It’s been a while that I failed the assembler programming class.)

Concerning my ears: They work well for tonal signals in detecting phase issues, but I find it hard to do so especially on drums.

Of course, one always has to check how it sounds. This is especially true for small venues, when you’ve got a lot of drums spilling from stage into the room. Depending on rock’n’rolliness the drummer, of course.

[Author]

Posts