How to send a MIDI NRPN from Qlab?

[Scott McGlynn]

Hey all,

I want to control an Allen & Heath iLive console from Qlab and it responds to NRPN MIDI messages. It looks like these are simply sets of three CC messages but I'm unclear on how to convert this information from the iLive MIDI reference to a MIDI cue in Qlab:

N = midi channel,  CH= iLive channel (fader), LV = fader level

Fader Level 

NRPN with parameter ID 17 

Fader value LV –inf to +10dB = 00 to 7F

 

Select channel    Parameter         Set fader value 

BN, 63, CH,         BN, 62, 17,         BN, 06, LV

(taken from http://www.allen-heath.com/media/iLive-MIDI-Protocol-V1.91.pdf)

If I understand correctly (although I have no idea what the letter B represents above), to change fader #1 to full (+10db) on MIDI channel #1 would require three CC messages from Qlab like so:

Command: Control Change

Channel:1 Control Number: 63 Control Value: 01

Command: Control Change

Channel:1 Control Number: 62 Control Value: 17

Command: Control Change

Channel:1 Control Number: 06 Control Value: 7F

Or is there an easier way to do this as one cue instead of three separate ones? Can a sysex form an NRPN message?

Thank you,

Scott McGlynn 

[Alexander (Mailing List) Taylor]

I've done this, I'll look through my old shows to find the workspace and get back to you.

Alexander

--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/9c937cf5-43d0-4bc8-a87e-34b102f9bee3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

The Right-To-Know Law provides that most e-mail communications to or from School District employees regarding the business of the School District are government records available to the public upon request. Therefore, this e-mail communication may be subject to public disclosure.

[Alexander (Mailing List) Taylor]

Here's the cues in a workspace.  Note I had a discussion about this on February 2nd, and there were some suggestions for fixing some bugs in the way I've implemented it.  I haven't put that in yet, though I really need to.

Alexander

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/EF31A8EA-7E39-4DFD-B8A3-4C0EFFBBCEA4%40orcsd.org.

For more options, visit https://groups.google.com/d/optout.

[Scott McGlynn]

Cool, thank you. Looks like SysEx to the rescue!

Scott

[Jay Hogg]

Scott,

About a year ago I needed to control an LS9 console (mutes) from qLab via NRPN, but wasn't up to the level of work needed in qLab and I needed some macro expansion capability to keep life simple.

A python script, some configuration and it has now been used in 5 shows.  The documentation isn't the prettiest but you should be able to easily adapt this if needed.

https://github.com/jhogg/LS9Control

Let me know if I can help with anything.  I'm currently taking the OSC-like commands and expansion over to dLive for qLab control.

Jay

[Andy Dolph]

For macro expansion I highly recommend Text Expander for the mac - very flexible and super useful.

Sent from my iPhone

--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/74383485-f935-41a5-bd92-328ec09b9ce5%40googlegroups.com.

[Jay Hogg]

Andy,

Text Expander is great, but I think you missed the point here. The expansion, in this case, is done at cue execution time, not creation time, to keep qLab clean and concise.

/channel/[headset]/mute to mute all headsets - be there 16, 18 or 20 active on a given day
/channel/[char:sandy,char:danny]/unmute to un-mute the lead characters, regardless of who is playing them on what channels based on channel tags

By having several different configuration files for the LS9 gateway, it handles if we are running a large or small ensemble and who is playing different characters on a given run all without having different sets of cues.

Depending on the level of complexity between qLab and the console, some people may find this overkill and others may love it.

Jay

[Andy Dolph]

Oh ok - that makes sense.

Sent from my iPhone

> --
> --
> Change your preferences or unsubscribe here:
> http://groups.google.com/group/qlab
>
> Follow Figure 53 on Twitter: http://twitter.com/Figure53
> ---
> You received this message because you are subscribed to the Google Groups "QLab" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/238e7e26-1595-429d-9d02-dde576e49648%40googlegroups.com.

[Scott McGlynn]

Jay

Alex's workspace worked like a charm. It uses SYSEX for the first two CC's and then groups an actual CC with it for the final parameter of the three that make up an NRPN.

However, once I started firing multiple NRPN messages at a time I ran into some trouble. Using a MIDI monitor I could see that no matter how I told Qlab to fire the group, it would send all the SYSEX messages first and then all the CC messages next after a .05 second delay. It's strange that telling the group cue to fire the first child and enter the cue and then set each cue to auto continue or auto follow had no impact; every SYSEX would go first.

My solution was to set the group cue to enter the group on the first child and continue. Then I set up each child to to Auto Continue and applied a post wait of .05. This setup kept each CC right next to the corresponding SYSEX it needed to go with. It means it doesn't all happen at once, but firing five cues still completes in less than half a second which works fine for my needs.

It'd be nice to have an NRPN option in the MIDI cue to take care of all this though.

I know just enough about Python that I try to avoid using it. I'll keep you notes in mind though if I get stuck on something else that Python might help solve.

Scott McGlynn

[Rich Walsh]

Did you notice that all of Alex’s CC messages have a 0.05s pre wait on them? If you take that out then the “messages” arrive in the same order they are listed in a start-all group.

I say “messages” because (as I’ve said before) you aren’t sending SysEx _at all_. You are using a bodge to enter 6 bytes in hex into a SysEx cue rather than convert them to decimal and generate 2 CC cues (for CC98 & CC99). For each SysEx/CC clusterfudge, MIDI Monitor reports an empty SysEx message, 2 CC messages, an invalid message (00 F7) and then the CC message sent as nature intended.

NRPN is NOT SysEx. Nor is it any kind of magic. It’s just a pair of CCs used to specify the action of the following pair of CCs; conceptually identical to how bank change works. You don’t need an NRPN cue: you just need 4 CC cues (or just 3 for coarse control). A 14-bit CC cue might be useful, but frankly I think if you can hear more than 127 steps in a fader maybe you should use your hands to mix?

You can’t send status bytes inside a SysEx message – they immediately abort the SysEx and travel as their actual message types (eg: CC – $BN). Perhaps a hex mode for data values in MIDI Voice Cues would be useful?

The Allen & Heath documentation is poor – and it’s also bizarre not to allow assignable CC control as Yamaha have always done (although we’re still waiting for DiGiCo to work out how to spell MIDI…).

Rich

[Arshan Gailus]

A couple thoughts:

1. Like Rich pointed out, this is actually a hack-y work around using the SysEx cue to do something it isn't supposed to.  If you really wanted to use the SysEx cue for whatever reason, a tidier way would be to start your content in the SysEx cue with and F7 and end it with an F0.  This will effectively send an empty SysEx message, followed by your MIDI message(s), followed by another empty SysEx message.  Still a clunky hack, but at least it would be proper MIDI messaging to hopefully avoid the off chance of gear flipping out based on invalid messages.

I wonder if there is a compelling reason to have a SysEx cue instead of just and arbitrary Hex MIDI message cue (which could, of course, be formatted as SysEx)?

2. A reason to have a proper NRPN MIDI cue available in QLab is for fades (which it looks like Alexander's demo workspace is doing).  If you assign an NRPN parameter number, start a fade on CC 6, and then assign a new NRPN parameter number before that fade is complete, the new NRPN parameter will be taking those CC 6 messages instead of the old one.  ie. you can't simultaneously fade two or more NRPN parameters without continually re-assigning the NRPN parameter throughout the fade which isn't possible without a dedicated NRPN MIDI cue to handle this.

-Arshan

[Sam Kusnetz]

Hello all

Honest question, not trying to troll: has anyone used NRPNs in any situation other than with a Yamaha console?

Best

Sam

—

Sam Kusnetz | Figure 53

s...@figure53.com

--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/d02b48e7-f450-4d54-b302-ed3c8c7e8993%40googlegroups.com.

[Andy Dolph]

I've mostly used them with Yamaha consoles, but there are a LOT of them out there.  A&H also uses them.  

I think I might have controlled a light board with them too somewhere, but I can't remember what it was...  

To unsubscribe from this group and stop receiving emails from it, send an email to qlab+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/d02b48e7-f450-4d54-b302-ed3c8c7e8993%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53
---
You received this message because you are subscribed to the Google Groups "QLab" group.

To unsubscribe from this group and stop receiving emails from it, send an email to qlab+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/CAOOK5Ab1QDehOOT9eAF1fBeLr%3DT-sSSNkZH%3DExmPs030MoJzhA%40mail.gmail.com.

[Gordon P. Howell, Jr.]

A&H iLive, GLD and QU systems use NNRP.  From the QU MIDI specification:

"Qu mixer parameters are transmitted and received as MIDI NRPN (Non-Registered Parameter Number) messages. The MSB (most significant byte) selects the mixer channel (CH), and the LSB (least significant byte) selects the parameter number (ID). The data entry MSB sets the parameter value (VA) and LSB sets the index value for its range (VX) where needed.”

Chris Hubbard at CH Sound Design has worked extensively with the A&H MIDI specifications for his Palladium program and might be of some help.

Geep

 

To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/CALBN1sYsGoq6R%3DjCGqtGD-6jX10AKnsKTAoAnuPJTdzr5PBiWg%40mail.gmail.com.

[Gordon P. Howell, Jr.]

Oops.  NRPN...

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/D2A3F28C-D46F-4B99-AAFF-2828E744DED0%40wa4rts.net.

[Alexander (Mailing List) Taylor]

Yes, I've used them with Allen and Heath consoles (iLive specifically, though others are similar).

Alexander

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/CAOOK5Ab1QDehOOT9eAF1fBeLr%3DT-sSSNkZH%3DExmPs030MoJzhA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Rich Walsh]

I’ve not come across a Yamaha console that doesn’t allow you to assign CCs to do whatever you need, so why go through the additional pain of using NRPNs?

Rich

[Rich Walsh]

On 3 Jan 2017, at 18:15, Arshan Gailus <ars...@arshangailus.com> wrote:

A couple thoughts:

1. Like Rich pointed out, this is actually a hack-y work around using the SysEx cue to do something it isn't supposed to.  If you really wanted to use the SysEx cue for whatever reason, a tidier way would be to start your content in the SysEx cue with and F7 and end it with an F0.  This will effectively send an empty SysEx message, followed by your MIDI message(s), followed by another empty SysEx message.  Still a clunky hack, but at least it would be proper MIDI messaging to hopefully avoid the off chance of gear flipping out based on invalid messages.

I wonder if there is a compelling reason to have a SysEx cue instead of just and arbitrary Hex MIDI message cue (which could, of course, be formatted as SysEx)?

Is it to avoid user confusion that the current implementation automatically adds the SysEx start and end bytes? Maybe it doesn’t need to do this – I don’t think ShowMan or SFX did, but it’s been a while…

2. A reason to have a proper NRPN MIDI cue available in QLab is for fades (which it looks like Alexander's demo workspace is doing).  If you assign an NRPN parameter number, start a fade on CC 6, and then assign a new NRPN parameter number before that fade is complete, the new NRPN parameter will be taking those CC 6 messages instead of the old one.  ie. you can't simultaneously fade two or more NRPN parameters without continually re-assigning the NRPN parameter throughout the fade which isn't possible without a dedicated NRPN MIDI cue to handle this.

So an NRPN cue would send all 3 (or 4) CC messages required every time it sends a new data value? I’d not thought about that, but looking at the manual for one of my MIDI controllers – that is buried somewhere at the moment so I can’t physically check – it does read as if an encoder assigned to send NRPN must do this… So maybe there is a need for an NRPN Cue after all!

Rich

[Scott McGlynn]

I did not notice that. You'd think I would've with the amount of troubleshooting I went through to figure out what was happening. Sigh.

sm

[Andy Lang]

The other thing that Rich hasn’t explicitly said here is that short waits in between grouped MIDI cues are often necessary because the vast majority of MIDI devices (both interfaces and receiving devices) have very old designs, with very limited memory. As such, they don’t have much in the way of buffer capacity, and it’s very, very easy to cause an overflow, which then causes messages to either get dropped or corrupted (if only partial messages are dropped).

This is why it is our rather boldfaced recommendation that SysEx messages should not be misused to send multiple other MIDI commands in a single cue.

In many, many cases, it just won’t work properly. Even when grouping individual MIDI cues together, it’s often necessary to add small delays to get things to play nice.

(This is also why I personally only recommend MIDI devices by iConnectivity and ESI, as they’re the only ones I know that have adequate enough buffers to reliably send MTC and long SysEx strings. I’ve seen darn near every other brand choke on one or the other at some point, usually at the worst possible moment.)

-Andy

—

Andy Lang
@SoundGuyAndy
sup...@figure53.com

--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/a266c675-8a7d-41cf-9842-fa4cbe910a98%40googlegroups.com.

​

[Alexander (Mailing List) Taylor]

I'm curious, how would you go about implementing this?  I'm going to be cleaning up iLive controlling for my setup soon, I'd love to do it correctly.  I don't see a simple solution, though it could be the fog of my cold.

Thanks,

Alexander

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/CACCWb6v0x7L%3DNd19BKC%2Byy47NyUD43JbasuW_ss-332g6Gpovg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Andy Lang]

On Tue, Jan 10, 2017 at 12:42 PM Alexander (Mailing List) Taylor ataylo...@orcsd.org wrote:

I'm curious, how would you go about implementing this?  I'm going to be cleaning up iLive controlling for my setup soon, I'd love to do it correctly.  I don't see a simple solution, though it could be the fog of my cold.

You’ll need to define “this”, as I’m not sure which specifically you mean.

If you mean sending a single NRPN at a time, I would, as others have stated, send the two consecutive CC messages from two consecutive MIDI cues, with a teeny tiny wait on the second, since that’s what an NRPN is; two consecutive control change messages. Don't try to get clever, just send the two messages in a group.

If you mean fading values (which a SysEx message won’t help with, in any case), I’d personally heed Rich’s wise observation that, in a moving fade in a live environment with noise floor and such being what they are, I’d just send the major value, and ignore the minor value. If your name isn’t Jon Weston, you probably won’t hear the steps.

You could also just record scenes in the console that do the fades, provided the console allows that, and recall those from QLab. Let the console do the part it’s good at, and the computer do the part it’s good at.

Finally, you could record the move in a MIDI sequencer, export that as a MIDI file, and then play back the file with a MIDI File Cue instead of trying to create it with MIDI Cues. That’ll be more humanized, too, since it’s a recording of an actual human.

Otherwise, the answer is the one we gave earlier, that QLab doesn’t support fading NRPN values at this time, but it’s good to know that it’s useful to you, and we’ve got it on the list for future consideration :-)

[Alexander (Mailing List) Taylor]

Great, I guess I was really asking the two different versions of "this" you addressed.  Very useful answers, and good to know fading NRPN values aren't supported currently.

Thanks again,

Alexander

--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/CACCWb6tf_0do6Mpe3hNgd8FEbkeH8W7xfaw9F%2ByEuVLGT3jMGg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Rich Walsh]

For the sake of completeness:

• I think Andy meant to say “three or four consecutive CC messages”: NRPN is 2 messages to define the parameter and then 1 (for coarse) or 2 (for fine) further messages to set the value
• You can send the 2 CC messages to set the parameter and then fade the coarse value in QLab – provided no other NPRN messages need to be sent during the fade
• You can’t do 14-bit fades – ie: combine coarse and fine
• You can’t send the parameter definition with each data value

There is a simple solution: get a desk with sensible MIDI on it!

Off the top of my head I’m not sure I could even generate NRPN fades in any of my DAWs. Maybe with Max…

Rich

[Andy Dolph]

I've done nrpns in puredata, and it worked OK but was not perfectly reliable. I was using it to iPad control an o1v and it was fine for setup and monitors, but I wouldn't want to mix a show that way.

Sent from my iPhone

--

--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/8D0A9C06-452E-4499-805C-44338FE01D98%40mac.com.

[Rich Walsh]

Why? The 01V can freely assign control changes to parameters – as can the 01V96 and so on (I think even the ProMix 01 could). (Actually, the 01V didn’t support NRPN – but I think I know what you mean ;)

Let’s also not forget the baud rate of MIDI: 31250. If I can still do the calculations correctly that means each byte takes ~0.25ms, so each 3-byte message takes nearly 1ms to send. If you send a full 3-byte sequence for all 4 of the CCs that make up a fine NRPN message that’s going to take 3ms. If you then send all 16,384 values of the 14-bit data variable it will take 50s to do a full fade – just to get the electricity down the cables…

I have to assume the baud rate specified for the original UART hardware is maintained, as there’d be no point going faster over USB unless you can guarantee the message is never going to hit an actual MIDI connector somewhere…

Rich

[Andy Dolph]

I needed more controls then were available via standard CC so I had to do it as nrpn 

Sent from my iPhone

--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/C6FA323E-35B7-44EE-8E47-CA8064059A11%40mac.com.

[Rich Walsh]

You can assign across 16 MIDI channels, so you’ve got pushing 2,000 CC messages available to assign to any parameter, haven’t you?

Rich

[Andy Dolph]

I haven't look at at it in ages, but  my recollection was it only had 100 or 127 available.

Sent from my iPhone

--

--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/62871BF8-87AC-4182-A950-3E5AE0A7A027%40mac.com.

[Rich Walsh]

I think there are 114 per channel, so 1,824 in total. Appendix C shows the default assignments, CC00-95 &102-119, CH01-16.

Rich

[Andy Dolph]

cool - I haven't looked at it in ages, so I have no idea why I didn't do it that way...

Andy

--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53
---
You received this message because you are subscribed to the Google Groups "QLab" group.

To unsubscribe from this group and stop receiving emails from it, send an email to qlab+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/9214D805-9BFF-491C-920C-6571E95184F3%40mac.com.