Search Results for 'qu midi protocol'

Forums Forums Search Search Results for 'qu midi protocol'

Viewing 15 results - 196 through 210 (of 221 total)
  • Author
    Search Results
  • #34555
    Profile photo of Gerger
    Gerger
    Participant

    Good idea…

    Ive checked the QU-16 FAQ:

    “Yes, standard MIDI control is tunnelled over the USB connection. All faders and a selection of the switches on the surface can be assigned to a DAW which supports MIDI control. Alternatively, a MIDI driver is available for use with the Ethernet port.”

    This means you can send midi commands at leased for the fader positions to the computer, but as long AH is not providing midi protocol document for QU-16, its not 100% sure, if you can use any rotary knobs for midi.

    Could someone, who owns a QU-16 already, check, if it sends out any midi command, if SEL button will be pressed or any rotary knob will be used?

    #34422
    Profile photo of Stix
    Stix
    Participant

    quote:


    Originally posted by davidgiga

    Hi,
    For the last several weeks I tried to reverse engineer the ACE network protocol in order to write an remote app for Android / WP8 but it’s way more complex than I originaly thought (especially cause I don’t have access to an iLive system)

    Why can’t A&H just release a protocol documentation like https://www.behringer.com/assets/X32_OSC_Remote_Protocol_v1.01.pdf Behringer did?


    What you are really asking for here is for A&H to directly (and fully) support OSC (Open Sound Control) protocol and I think that would be an interesting and potentially progressive move for them. With the iLive mixracks A&H have one of the best hardware setups ready and waiting for custom control capability. Although we can already use TCP/IP and Midi for control (these documents are available for download) these formats are severely limited in what can be achieved due to the limited control parameters supported. Of course we have Editor for total control and that is great (and free!) but offers virtually no end user customisation.
    Take this for example: Imagine if the iLive had complete OSC support – and you have a job/client that needs one operator (or device) to have access and control of say 4 monitor sends including channel processing but no FOH control, and no access to head amps. This can’t be done with either Editor, Mixpad, Onemix, or a surface yet it would be relatively easy to design a custom OSC layout that could work on almost any preferred platform including Android! TouchOSC would be one app that comes to mind that could provide custom touchscreen control.

    Cheers

    Richard Howey
    Audio Dynamite Ltd
    IDR48/IDR16/T112/R72/Mixpad,Tweak,
    Dual M-Dante/DVS, 17″MBP/Logic 9/Custom Mackie Control

    #33886
    Profile photo of pngaudioguy
    pngaudioguy
    Participant

    quote:


    Originally posted by mervaka

    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.


    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

    #33885
    Profile photo of mervaka
    mervaka
    Participant

    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.

    #33831
    Profile photo of pngaudioguy
    pngaudioguy
    Participant

    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.

    #33824
    Profile photo of mrp123
    mrp123
    Participant

    +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?

    #33821
    Profile photo of pngaudioguy
    pngaudioguy
    Participant

    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…

    #31097

    In reply to: MIDI explanation

    Profile photo of Stix
    Stix
    Participant

    Yes you could if you know what you are doing – but why? The iLive midi commands are sent from either fader moves, mutes, pans etc and so won’t make a very convenient controller to trigger loops etc. Use a midi controller keyboard it will be much easier to set up and use. The MMC midi commands that can also be sent from the iLive touchscreen can be used for sequencer transport or could be converted to do other midi tasks but these commands coming out of the iLive are fixed so would need to be converted with external software or within your sequencer.

    The IDR midi ports also have a fixed midi protocol so you would also most likely need to convert these messages to use in cubase. The IDR midi spec is available in the A&H iLive downloads page. Editor midi is much easier to work with as it can be programmed or “learn” midi commands to send/ receive.

    Cheers

    Richard Howey
    Audio Dynamite Ltd
    IDR48/IDR16/T112/R72/Mixpad,Tweak,
    Dual M-Dante/DVS, 17″MBP/Logic 9/Custom Mackie Control

    #31051
    Profile photo of Sylvester
    Sylvester
    Participant

    quote:


    Originally posted by mervaka

    The surfaces aren’t dumb controllers like the BCF is. The MIX/SEL buttons are local to each control interface, unlike the PAFL bus, which is shared. I’m not sure how the AHNet protocol works, but I am sure the BCF won’t be able to process MIX/SEL stuff standalone. I’ve made a feature request myself for MIDI mappings in editor to include MIX/SEL as it currently does with MUTE/PAFL. Of course, this would require a computer running editor, and not just a standalone BCF.


    Mervaka, i think you misunderstood me (although it gets complicated just trying to explain to my self how it should work). The BCF is actually not really controlling anything – Logic is. Logic is then controlling my BCF (Logic having control over 64 simultaneus channels of fader, mute, PFL, gain and HPF data instead of the BCF only controlling 8 channels of simultaneus data)
    The main thing is that i would like to know what data is sent to the mixrack (through TCP) when pressing MIX in the editor.
    Sadly i am not a software engineer, so my knowledge is probably flawed when it comes to reverse engineering. I downloaded a freeware TCP-sniffer which gave me a bunch of data, but it was way out of my league trying to figure out what was going on. :)

    #31026
    Profile photo of mervaka
    mervaka
    Participant

    The surfaces aren’t dumb controllers like the BCF is. The MIX/SEL buttons are local to each control interface, unlike the PAFL bus, which is shared. I’m not sure how the AHNet protocol works, but I am sure the BCF won’t be able to process MIX/SEL stuff standalone. I’ve made a feature request myself for MIDI mappings in editor to include MIX/SEL as it currently does with MUTE/PAFL. Of course, this would require a computer running editor, and not just a standalone BCF.

    #30956

    In reply to: Network Simulation?

    Profile photo of
    Anonymous

    Yes I know, I already implemented the TCP/IP Midi thing. But I still got 2 problems:
    1. I can’t test it (Ofcourse somebody else with an ilive system could test it but it makes it quiet hard to debug things)
    2. The documented TCP/IP protocol is very limited in function. You can’t even change an eq setting! [xx(]

    But I think A&H won’t release an document about the ACE protocol?

    #30502

    quote:


    Originally posted by Stix

    Gee – that’s a pain! I don’t have a GLD but for recalling scenes you may find this post interesting as the GLD scenes can also be recalled by Tcp/ip (and MIDI):
    https://iliveforum.allen-heath.com/topic.asp?TOPIC_ID=1965&SearchTerms=Top

    Video here: https://www.youtube.com/watch?v=yzgH98b1QAs&feature=youtube_gdata_player

    The GLD TCP/IP protocol is available to download from the GLD Documents page on the A&H site.

    Might be a short term solution until next/previous scene functions are available!

    Cheers

    Richard Howey
    Audio Dynamite Ltd
    IDR48/IDR16/T112/R72/Mixpad,Tweak,
    Dual M-Dante/DVS, 17″MBP/Logic 9/Custom Mackie Control


    I looked at that and tried to see if I could do a custom MIDI comand in the softkeys which it will let you do however it only lets you choose an actual scene # to recall. Therefore I could still only recall the same 10 scenes, one for each soft key and I would lose the use of the keys for any other funtions. I haven’t looked into an outboard MIDI device to setup Program Changes in to choose all of the scenes but this is really a huge issue for me. All the little bugs that are always expected in a new products are really no big deal but without the ability to recall next or previous scenes with the push of a button is a super bummer!

    #30432

    In reply to: Ethernet Control

    Profile photo of TJCornish
    TJCornish
    Participant

    quote:


    Originally posted by GulikerAV

    quote:


    Originally posted by antonyja

    Currently you can control a sub-set of the GLD’s functions via a TCP/IP connection thru the Ethernet port. Details of this protocol (based on MIDI), and the MIDI protocol document will (soon) be available on the A&H website.

    Antony Jackson
    Software Manager
    Allen & Heath Limited


    Ehm.. my GLD-80 responds to a PING command, but how do I acces the console? Web-browser as there is no software at the moment?
    Firefox just gave error.

    GulikerAV.nl ownes GLD-80


    There is no software yet, either external or web-based. You can roll your own software using the TCP/IP information that Antony linked. Unless you’re a programmer though, this isn’t going to be what you want, as no one has written any remote control software for the GLD yet.

    #30421

    In reply to: Ethernet Control

    Profile photo of QualityAV
    QualityAV
    Participant

    quote:


    Originally posted by antonyja

    Currently you can control a sub-set of the GLD’s functions via a TCP/IP connection thru the Ethernet port. Details of this protocol (based on MIDI), and the MIDI protocol document will (soon) be available on the A&H website.

    Antony Jackson
    Software Manager
    Allen & Heath Limited


    Ehm.. my GLD-80 responds to a PING command, but how do I acces the console? Web-browser as there is no software at the moment?
    Firefox just gave error.

    GulikerAV.nl ownes GLD-80

    #29882
    Profile photo of Stealth
    Stealth
    Moderator

    Hi dburris

    The iLive systems continuously send and recieve MIDI data, so yes you can use the iLive as a MIDI interface. Here is a link to exactly what you can control.

    https://www.allen-heath.com/UK/CategoryDocuments/iLive%20MIDI%20Protocol%20V1.8.pdf

    I am afraid we do not currently have a Mac or windows driver for use to convert iLive MIDI into a DAW sequencer via TCP/IP, though this is already on our request list.

    Currently the easiest way is to use a USB MIDI interface with your computer (e.g. M-Audio MIDIsport) then connect the MIDI IN/OUT ports on either the mixrack or surface.

    Regards
    Sam A&H

Viewing 15 results - 196 through 210 (of 221 total)