Dear Allen & Heath,
Please consider allowing full control of the iLive MixRacks via either MIDI, OSC, or TCP/IP, to include EQ, compression, gate, and limiter/de-esser parameters and meters, scenes, etc. Obviously the control system is in place given your native app can do all of this over wifi, and the manual states that the control surfaces simply use TCP/IP protocol.
Thanks in advance!
CS
I went back and reread the TCP/IP and MIDI protocol guides for 1.9. In the TCP/IP guide, it specifies that the control sends MIDI messages over TCP/IP. The question then becomes whether or not the TCP/IP MIDI messages are the same sysex that would be required over the MIDI ports… in theory, analyzing the data being sent over the network could be used to determine a sysex stream between appropriate F0 SOX and F7 EOX values…
+1
Agreed, agreed, agreed.
Dear A&H,
Opening up only a subset of the control functions to the MIDI and TCP/IP protocols to date is disappointing, and hinders the creativity of your users. I’ve long envisioned doing more with my iLive if only I had access to more controls over MIDI. Others have ideas too. Please open up full control to MIDI / TCP/IP. Considering Editor has the very remote control capabilities that were looking, for albeit in a closed environment, can you please go the distance and allow 3rd party access to these same controls to satisfy our unique applications?
I must say I disagree with you guys, and must jump to Allen & Heaths defense here. The iLive is supposed to be a professional environment, and that does not mean supporting all sorts of homebrewed solutions. It is already hard to get people to recognize the very healthy sound of the iLive system, which is actually the only thing besides sound craft/studer and midas out there, that really sounds very very good.
But the build quality and feel of the fixed format racks and surfaces is sub-par unfortunately, and opening up to an endless amount of weird midi-solutions out there, will only make the rider acceptance decrease even further.
The iLive is a great system, let A&H work on improving it, not worry about solutions that will eventually hurt surface sales - the surfaces are already too expensive.
vilddyr - Interesting viewpoint. I agree that it does open it up to an array of possibilities, and I can imagine that as a result getting one on a rider correctly would be a challenge. For the work I do, a rider is not important, because I work with one dedicated group that carries all our own equipment, so haven’t had to deal with a rider in quite some time.
Due to the cost of the control surfaces, we opted not to get one. We had been mixing all our shows from an iPad for the last year or two anyway, using a custom interface I’d designed on Lemur to control a Yamaha console - which, includes a list of full MIDI protocol, yet is on almost every budget rider out there… The console sat on stage and basically did what the iLive rack is doing for us now, except it took up more space.
It seems that people have been requesting an easier way to switch mixes on the app from A&H for several years now, yet it has not been integrated. If I knew the sysex commands, I could drop them in my template and be up and running in a matter of hours. Granted, had I known the sysex commands, I wouldn’t have given A&H an extra $100 for the app, so they’ve got that going for not making the protocol public.
quote:
Originally posted by vilddyrThe iLive is a great system, let A&H work on improving it, not worry about solutions that will eventually hurt surface sales - the surfaces are already too expensive.
Weird reasoning. You’d be surprised how iDR-sales could be raised by allowing crowd-sourcing.
Closing off environments has never helped sales on the long term, although some companies seem to keep on thinking like that.
And only people that use/own an iDR are potential surface clients!
Actually I would love to be able to share lemur-projects with interfaces optimized for certain use (small bands, theater,…).
Just think of this iLive online community that would work together on ideal interfaces, rather than just complaining about the official interface 
There’s not a single reason to think that this could hurt the image of the brand. It just offers even more possibilities.
There is indeed a market out there of people that want to mix professionally whilst keeping stuff completely portable! That’s definitely a part of A&H’s iLive market, or it could be if they recognize the potential.
Wouter
IDR32, R72, Dante, Mixpad
laptop, TP-Link TL-WR1043ND</font id=“size1”></font id=“navy”>
I’m not sure that would be the correct move. It would also open up a world of support tickets for. Like buying a macbook and installing windows on it, in my book, asking for trouble.
Again, I would prefer more and cheaper surfaces - things that could easily be integrated in the same way. Like a small 8 fader + master surface. Done right, you could make some really innovative stuff to work as sidecars for a laptop with editor.
quote:
Originally posted by vilddyrIt would also open up a world of support tickets for.I would prefer more and cheaper surfaces.
</font id=“quote”></blockquote id=“quote”>A&H could easily just say, sorry - we don’t provide support for aftermarket products used with our system, only our official products. No need to have support tickets for that. Their policy could be clearly stated that should you choose to use 3rd party controls, you’re on your own to make sure they work right.
Weren’t you already saying that their interfaces feel cheap as is? Why would you want cheaper surfaces? If their expensive surface feels cheap, imagine how flimsy an inexpensive surface would feel!
I fully agree with woutert that it would allow us to stop complaining about missing features in the A&H app. You could supplement their system with whatever feature it is you personally feel is missing using your own template. You could share that template with the community for whoever else feels the desire to do something similar, of course, with the caveat that they’ll have to adjust parameters to match their system configuration. Anyone who is delving into Lemur will know that anyway, though.
Just an example: If I could tap-tempo by MIDI, I’d giggle like a schoolgirl.
quote:
Originally posted by timtraceJust an example: If I could tap-tempo by MIDI, I’d giggle like a schoolgirl.
That, and support for Mackie Control, and i’d be happy as a clam!
quote:
Originally posted by vilddyr…that does not mean supporting all sorts of homebrewed solutions. …
</font id=“quote”></blockquote id=“quote”>There is a big difference between publishing your protocol specifications and supporting user developed products.
Most companies that publish their specs do not provide support for third party applications/hardware that use that specification (precisely for the reasons you site). That support is up to the vendor providing the add-on solution/hardware.
I don’t see how publishing this information would hinder Allen and Heath whatsoever.
Jason
Really?
Jeremy Koch
Innovative Production Services - www.innovative.net.au
Current stock:
2x T112, 1x T80, 2x R72, 2x iDR-48, 3x iDR-16, 2x xDR-16
4x Dante Cards, 3x ACE Cards
Yes, I’d really like to have a complete MIDI sysex spec sheet available
quote:
Originally posted by jgroomsquote:
Originally posted by vilddyr…that does not mean supporting all sorts of homebrewed solutions. …
</font id=“quote”></blockquote id=“quote”>There is a big difference between publishing your protocol specifications and supporting user developed products.
Most companies that publish their specs do not provide support for third party applications/hardware that use that specification (precisely for the reasons you site). That support is up to the vendor providing the add-on solution/hardware.
I don’t see how publishing this information would hinder Allen and Heath whatsoever.
Jason
+1
Wouter
IDR32, R72, Dante, Mixpad
laptop, TP-Link TL-WR1043ND</font id=“size1”></font id=“navy”>
Cheers
Richard Howey
Audio Dynamite Ltd
IDR48/IDR16/T112/R72/Mixpad,Tweak,
Dual M-Dante/DVS, 17"MBP/Logic 9/Custom Mackie Control
Do these controllers that you guys are proposing all support NRPN messages? I don’t see any other way in which the MIDI protocol could cope with the extensive addressing requirements. Metering feedback will undoubtedly not be possible via MIDI, as it lacks the bandwidth required.
quote:
Originally posted by mervakaDo these controllers that you guys are proposing all support NRPN messages? I don’t see any other way in which the MIDI protocol could cope with the extensive addressing requirements. Metering feedback will undoubtedly not be possible via MIDI, as it lacks the bandwidth required.
Quite the contrary, sir. MIDI system exclusive commands (or sysex for short) are fully capable of addressing every parameter on the console, including metering. Bandwidth is adequate for metering 24 channels, dependent on the hardware capabilities. I personally haven’t tried to push it beyond that.
For an example of the level of control you can achieve to include metering, check out the Yamaha LS9 midi spec sheet (https://download.yamaha.com/file/47461 ~295Kb .zip file) - definitely not an A&H link! My Lemur template makes use of this, and the 01V MIDI and DM1000/DM2000 MIDI for control of those consoles. The 01V doesn’t quite handle metering smoothly, the others do fine. Actually, the MIDI spec for 01V/DM1000/DM2000 is nearly identical. They changed metering data to a single byte in their newer series of consoles (older ones were 10 bit resolution, which requires 2 bytes of data to convey hence more processing power which I believe the 01V lacks.)
I’ve done some limited reverse engineering via wireshark of the commands that A&H live editor is sending to the rack. There is a 13 byte message starting with F0 and ending with F7 (standard sysex start and end of exchange messages), but they don’t correspond to the specs they have posted. The rack then responds with a series of 2 or 3 messages depending on whether you have channel window open in the editor, which the editor sends an “ACK” packet to. The first response message from the rack also activates the MIDI “in” LED on my midiman when I adjust a level, and the data packet of that message terminates with the standard NRPN message as described in their spec page (which does not match the level range of 0000 to 8a00 that the editor sends, btw - 35329 point resolution - as NRPN is limited to a single byte with range 00 to FF - 256 point resolution.)
Attempts at sending the same messages via MIDI result in a “received end of sysex message, but no start of message was found” error in the editor. I haven’t been able to determine if some sort of handshake takes place between the editor and the rack to “authorize” these modified messages, but it appears as though everything the editor sends to control the rack is just a MIDI sysex message. This is consistent with how A&H describe their TCP/IP protocol in that spec sheet.
There’s one 16 byte and one 27 byte message every second as well, the 16 byte appears to be a timecode of sorts, and my hunch is that the 27 byte is metering that gets averaged in the app somehow, but I’ll have to do some more testing to see if I can figure that out and make use of it.
I’ll be sure to keep you all posted if I am able to make any more headway, but it will be a good month before I have the rig off the road to bench test some more.
CS
iDR-32