Control MainStage faders

[Patrick Spadrille]

I want to control MainStage with Qlab using Midi. What i want is control some mikes's faders i have in MainStage. I need to create a fade from the last position of one fader to a new position. I can't find a way to do that. Right now, i use control change to do a time fade to a new fader position but i also have to set the start position of the fader. That's not very practical since i have to track every fader's positions to be sure that the start position is always the same as the end position of the previous cue. Is there another (simpler) way to achieve what i want?

[Rich Walsh]

p80 of the v2.1.3 manual: "pickup". Or look for "To set the behavior for screen controls when you move a hardware control". Might work. Fairly common problem with hardware controllers that don't take input.

Rich

On 16 Apr 2014, at 08:49, Patrick Spadrille <patrick....@gmail.com> wrote:

I want to control MainStage with Qlab using Midi. What i want is control some mikes's faders i have in MainStage. I need to create a fade from the last position of one fader to a new position. I can't find a way to do that. Right now, i use control change to do a time fade to a new fader position but i also have to set the start position of the fader. That's not very practical since i have to track every fader's positions to be sure that the start position is always the same as the end position of the previous cue. Is there another (simpler) way to achieve what i want?

--
--
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.
For more options, visit https://groups.google.com/d/optout.

[Patrick Spadrille]

Thanks for the tip. I have tried that but it doesn't work so great. It works when i set a fader with the mouse on MainStage and then i send a Qlab Midi cue control change. The fader only move when it reaches the same value the fader was on MainStage.  But if i send another midi cue again, the MainStage fader comes goes all down to 0 again before going up. It seems that it only works if i have moved the fader with the mouse before using a midi cue. That's very odd and sounds like a bug to me. But also, even if that bug was solved, the problem is that it only works if the midi cue send a fader level that is in the range of the actual MainStage fader value. For example if my MainStage fader is on 50 and the midi message send a fader movement from 0 to 20, the MainStage fader never move because it never cross 50. Or i have to change the Midi cue and make it going down (127 to 0) but i'm almost back to square one that way, i have to look to previous midi cue before programming the next midi cue. Maybe using control change is not the right way to do that? Any idea?

[Rich Walsh]

No, it seems it doesn't work as advertised; I guess because it assumes you can't have moved the hardware controller without sending MIDI – which is what QLab is effectively doing with a new cue.

I can't think of a way of getting round the absolute relationship between CC value and fader position – you'll just need to make the effort to keep track of where you last faded to. Even with a Yamaha mixing desk the best you could hope for is a bunch of highly targeted scene memories that do fades to specific levels on specific faders. This is the only mechanism I can currently think of that stores just final value, not the journey to that value too (which MIDI CC must). In Live you can set the mode to "Relative (Signed Bit)", which will make the fader jump up in steps each time you send the CC @ 127, and down for CC @ 0 – but this still isn't going to do what you want.

I guess you're actually trying to do what absolute Fade Cues do – which is go to a destination from any given start point. I can't see a way of doing that with MIDI.

By the way, it would be a lot easier to answer questions if you didn't delete everything that had gone before in the thread each time.

Rich

[Daniel Perelstein]

Likewise, in the software Reaper, you can automate faders with MIDI control changes. 

Dan

On Thursday, April 17, 2014, craig k <craig....@gmail.com> wrote:

I don't really know from Mainstage, as I've only used it as an keyboard engine. But, fades on a Yamaha can certainly be done with a direct midi command to target a new (destination) fader position without using a scene memory. QLab can even do this to a time. I'm away from my work computer at the moment ( and won't have it hooked up to a Yamaha again til monday, but this is a well established process. I would like to think that if you can send mini info to MainStage faders that they would act similarly.

Craig K

[Patrick Spadrille]

Dan, you talk about automating faders with midi control change in Reaper but how does it react regarding the problem i have in MainStage? Does Reaper create a fade from the last value of the fader in Reaper whatever the first position of the fade value sent from Qlab?

You received this message because you are subscribed to a topic in the Google Groups "QLab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qlab/mo7TkmjcuCo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qlab+uns...@googlegroups.com.

[Rich Walsh]

I think you've missed the point entirely. You can map more or less any parameter on a Yamaha desk to a MIDI CC, but if you want to move it from one value to another you need to know its current value. If the fader is at 0dB and you want to fade to -10dB you have to start your CC fade at (the equivalent of) 0dB; if you send -10dB the fader will jump directly there; if you send it a fade from -5dB to -10dB it will jump to -5dB and then fade to -10dB. Only a scene memory can tell it to fade to a value in a time _regardless of current value_.

I suspect the same is true of Reaper; it's certainly the case in Live. The MIDI control is based on the idea that you have a hardware fader that gives you a big clue as to where you last left it. The takeover modes relate to the fact that the software might not be able to move that fader, but they assume that you can't move it without it telling the software that it's moving.

Rich

On 18 Apr 2014, at 02:20, craig k <craig....@gmail.com> wrote:

I don't really know from Mainstage, as I've only used it as an keyboard engine. But, fades on a Yamaha can certainly be done with a direct midi command to target a new (destination) fader position without using a scene memory. QLab can even do this to a time. I'm away from my work computer at the moment ( and won't have it hooked up to a Yamaha again til monday, but this is a well established process. I would like to think that if you can send mini info to MainStage faders that they would act similarly.

Craig K

On Thursday, April 17, 2014 6:36:11 PM UTC-4, Rich Walsh wrote:

[Daniel Perelstein]

Yes, as Rich said, every CC command is in the form of "fade from value X to value Y". You have to specify both X & Y.

That said, it differs from your MainStage issue in that X & Y can be any values (within the MIDI range, of course), so the issue you described where the fader is at 50, so a fade from 0 to 20 is ignored, is not a problem in Reaper (and likely Live, etc.).

Also, of note, the start value of one cue does not have to be the end vale of the previous cue (although if it's not, there'll be a jump from one to the next).

It doesn't seem like a problem to specify both start & end values. Is it?

Dan

Daniel Perelstein                 

Full-service music and sound for the theater

Musical Direction | Sound Design | Composition | Multi-Instrumentalist
Conducting, Arranging & Orchestrations, Vocal Coaching, Accompanying
www . danielperelstein . com

[Rich Walsh]

On 18 Apr 2014, at 12:17, Daniel Perelstein <dpere...@gmail.com> wrote:

Yes, as Rich said, every CC command is in the form of "fade from value X to value Y". You have to specify both X & Y.

That said, it differs from your MainStage issue in that X & Y can be any values (within the MIDI range, of course), so the issue you described where the fader is at 50, so a fade from 0 to 20 is ignored, is not a problem in Reaper (and likely Live, etc.).

MainStage is ignoring CC's until they pass through the current position when the fader has been moved by the mouse because we have told it to do that with the takeover mode ("pickup"). It does not ignore them if you don't move the fader with the mouse between CC messages. This is not a MainStage issue: you can make Live do this too, and probably Logic (which is essentially MainStage anyway), and maybe even Reaper.

Also, of note, the start value of one cue does not have to be the end vale of the previous cue (although if it's not, there'll be a jump from one to the next).

Trying to avoid jumps is exactly why this thread started.

It doesn't seem like a problem to specify both start & end values. Is it?

Apparently it is, but I can't see any way round it. It's a global problem that is going to affect any MIDI-controlled parameter – even RME's Totalmix would do this I think – so thinking of it in terms of a MainStage-only issue isn't useful.

[micpool]

There are a number of somewhat imperfect solutions to this problem, which one is right will depend on why you are combining automation of levels in Qlab with mouse over ride in Mainstage.

One approach would be to control the level manually from the mainstage fader and make relative adjustments to the current level by automating the gain control in a plug in on the Mainstage fader using Midi cc from Qlab

If a rapid change in level that wasn't a jump is all that is required, then using pickup mode in a 2 sec fade from the bottom or top of the cc range might accomplish this. There would be a small variation in exactly when the pickup occurred but if you had an idea of roughly where the fader might be this could be minimised by using curves on the cc change.

If neither of the above are suitable then having some idea of what you are trying to achieve might make an appropriate solution more obvious

Mic

[Rich Walsh]

If you go back to Patrick's first post on the thread you will see what he is trying to do:

>> I want to control MainStage with Qlab using Midi. What i want is control some mikes's faders i have in MainStage. I need to create a fade from the last position of one fader to a new position. I can't find a way to do that. Right now, i use control change to do a time fade to a new fader position but i also have to set the start position of the fader. That's not very practical since i have to track every fader's positions to be sure that the start position is always the same as the end position of the previous cue. Is there another (simpler) way to achieve what i want?

I offered pickup mode as a solution, but it doesn't work - for reasons outlined repeatedly in the thread so far!

On 18 Apr 2014, at 14:53, micpool <m...@micpool.com> wrote:

> There are a number of somewhat imperfect solutions to this problem, which one is right will depend on why you are combining automation of levels in Qlab with mouse over ride in Mainstage.
>
> One approach would be to control the level manually from the mainstage fader and make relative adjustments to the current level by automating the gain control in a plug in on the Mainstage fader using Midi cc from Qlab

This just moves the problem somewhere else: you'll still need to know where you left the gain control in order to fade it to a new value without a jump.

> If a rapid change in level that wasn't a jump is all that is required, then using pickup mode in a 2 sec fade from the bottom or top of the cc range might accomplish this. There would be a small variation in exactly when the pickup occurred but if you had an idea of roughly where the fader might be this could be minimised by using curves on the cc change.

Pickup doesn't do this unless you move the fader with a mouse to tell MainStage (or Live, or whatever) that it is no longer in agreement with the hardware.

> If neither of the above are suitable then having some idea of what you are trying to achieve might make an appropriate solution more obvious

In summary: send an event from QLab to MainStage to tell it to fade gracefully to a new value _without already knowing what value it is currently at_. All because the buffer required for Mic Cues to be useful is too small to be able to deliver audio and video at the same time without dropouts...

Rich

(PS: I think it is a bad idea to respond to threads on a forum by deleting everything that has gone before - as this thread shows we keep going round in circles because people aren't reading the previous discussion. So there.)

[Patrick Spadrille]

Thank you for the summary. You understand perfectly my "problem". But i'm not sure i agree with you on the not deleting part. Personally i much prefer that every thread doesn't contain the same information over and over again resulting in very very long text. I think it's much clearer to have just the response. Unless of course you want to quote something precise that had been said to give an answer to that part only. This is of course just my opinion. :-) 

To come back to my issue, yes i could program every midi cue using the last fader position as a reference to create the following midi cue. I just thought that Qlab is such a great tool that there should of course be a way to do what i want in an easier way. Like the way Qlab communicate with a light software with Midi Show Control. Just enter the number of the cue and the fade duration and bam, it create a light fade from the current light scene to the next one without having to worry about were the previous light faders were. Simple and easy as is Qlab most of the time. But maybe there is no easy way to do what i want and i just have to do more programming than expected. Not a big deal. I just love elegant solutions and this isn't.

[Rich Walsh]

But that's got nothing to do with QLab: that's to do with how TIMED_GO is defined in the MSC spec. Your problem is to do with the industry-wide way of dealing with MIDI control change. You could achieve the equivalent of what you describe with a lighting desk by storing states in an external sound desk (albeit with the fade time stored locally) – as I described earlier.

Rich

Annoying that you now have now idea what I'm talking about, isn't it?

[micpool]

On Friday, April 18, 2014 3:04:28 PM UTC+1, Rich Walsh wrote:
> If you go back to Patrick's first post on the thread you will see what he is trying to do:
>
>
>
> >> I want to control MainStage with Qlab using Midi. What i want is control some mikes's faders i have in MainStage. I need to create a fade from the last position of one fader to a new position. I can't find a way to do that. Right now, i use control change to do a time fade to a new fader position but i also have to set the start position of the fader. That's not very practical since i have to track every fader's positions to be sure that the start position is always the same as the end position of the previous cue. Is there another (simpler) way to achieve what i want?
>

I think there is a big difference between an objective description of the way you want 2 program's to interact with each other and a description of what you are trying to achieve e.g increase the level of a mic from its current level by 10dB when a. music bed starts or whatever. Knowing why someone wants to do what they are just describing as a sequence of engineering events is often part of finding solutions in applying technology for artistic ends.

Often there is a much simpler method of achieving something which will have the same subjective result for an audience than a solution that is more complete and universally applicable in engineering terms. Knowing the practical outcome the poster wishes to achieve is easier than tackling everything as a pure engineering problem.

> >
>
> > One approach would be to control the level manually from the mainstage fader and make relative adjustments to the current level by automating the gain control in a plug in

> This just moves the problem somewhere else: you'll still need to know where you left the gain control in order to fade it to a new value without a jump.

Yes but you know that because Qlab is the only thing that is adjusting the gain and you the operator are the only thing at is adjusting the fader. This is a practical solution that for many desired subjective outcomes may work well even if it doesn't provide a complete engineering solution.
>

>
>
> (PS: I think it is a bad idea to respond to threads on a forum by deleting everything that has gone before - as this thread shows we keep going round in circles because people aren't reading the previous discussion. So there.)

I agree but judging by the number of posts that request that as much as possible is deleted, and allowing for the fact that google groups on mobiles don't quote text in replies we seem to be in the minority.

Mic

[Patrick Spadrille]

@ Rick : Of course, i don't blame Qlab. What you propose is nice but i don't have the budget to buy an external mixer just to control 2 mikes. I would prefer to use the audio softwares i own.

@ Micpool : Here is the description of what i need to be done. I have 2 actors on stage with lavalier microphones and 3 speakers : left,center and right. I need the sound of each actors coming from the place he is. If the actor 1 is on the left, i want the sound to come mainly from the left speaker. If he's on the center, i need the sound to come from the center speaker. If he's... you got my point.  So when an actor move from one part of the stage to another (which is not to often since basically there is 3 parts on the stage and mostly when they go from one to the other, they stay there for a while) i need the sound to follow them. Sometimes they speak during the moves from one part of the stage to the other so i don't want the sound to change in one step, i need a fade. A fade is also smoother for the ears and make the change less audible when there is a little background noise in the mikes.

[Daniel Perelstein]

Patrick,

Can this not be automated?

My understanding of the problem is that what you're asking can EITHER be automated OR performed live by an operator (using their fingers on faders on a console or a mouse in software). If I've been making sense of the last few threads, the issue is when you want to be able to automate it, have somebody make arbitrary adjustments once a fade is complete, and then automate the next move. 

Am I understanding it correctly? If so, and you'd like to automate it, it seems as if plenty of working solutions have been proposed ... Just come out of Touch Mode (or whatever it's called in your particular software), and you can program cues in QLab for each of your moves. 

Am I missing something?

Dan

On Friday, April 18, 2014, Patrick Spadrille <patrick....@gmail.com> wrote:

@ Rick : Of course, i don't blame Qlab. What you propose is nice but i don't have the budget to buy an external mixer just to control 2 mikes. I would prefer to use the audio softwares i own.

@ Micpool : Here is the description of what i need to be done. I have 2 actors on stage with lavalier microphones and 3 speakers : left,center and right. I need the sound of each actors coming from the place he is. If the actor 1 is on the left, i want the sound to come mainly from the left speaker. If he's on the center, i need the sound to come from the center speaker. If he's... you got my point.  So when an actor move from one part of the stage to another (which is not to often since basically there is 3 parts on the stage and mostly when they go from one to the other, they stay there for a while) i need the sound to follow them. Sometimes they speak during the moves from one part of the stage to the other so i don't want the sound to change in one step, i need a fade. A fade is also smoother for the ears and make the change less audible when there is a little background noise in the mikes.

--

[Patrick Spadrille]

@ Dan : yes i need it to be automated. No i don't need someone to make arbitrary change after the fade. Yes i know i can program the midi cues using the last fader position and the next one, it just seems to be more programing than necessary. But apparently, there is no easier way so don't sweat about it, it's just gonna take me more time than expected and who knows maybe it will inspire the Qlab programmers to propose an even better solution in the next Qlab version. :-)

[Rich Walsh]

You're just not getting the point. This is a limitation of MIDI, not QLab. You need to persuade Apple to make MainStage behave differently – and differently to all the other MIDI-controlled devices in the world.

Put all your MIDI Cues in a sub cuelist. Number them. Use Start Cues to target them: just type in the number when you want to call one. Then scroll through your cuelist and check the fades join up. Or, given that there are only a finite number of moves for two actors in 3 zones, make the 8 CC fades you need and call them via Start Cues.

[Patrick Spadrille]

I get the point. But if it’s right that Qlab haven’t create the problem they could create the solution. Maybe Qlab could find a way to automate the In point value of a midi cue based on the out point of the previous mid cue? That could be an option. I’m just thinking out loud. But really you can stop offering solutions, i know that what i was expecting doesn’t exist for now and i know what i have do to work the way i need anyway. Thank you everyone for your help.

[micpool]

>
> @ Micpool : Here is the description of what i need to be done. I have 2 actors on stage with lavalier microphones and 3 speakers : left,center and right. I need the sound of each actors coming from the place he is. If the actor 1 is on the left, i want the sound to come mainly from the left speaker. If he's on the center, i need the sound to come from the center speaker. If he's... you got my point.  So when an actor move from one part of the stage to another (which is not to often since basically there is 3 parts on the stage and mostly when they go from one to the other, they stay there for a while) i need the sound to follow them. Sometimes they speak during the moves from one part of the stage to the other so i don't want the sound to change in one step, i need a fade.

If I were going to use voltage panning on an LCR speaker system to attempt to localise the apparent source of the reinforced sound to the position of the actor (which I probably wouldn't as there are often more effective ways of achieving this) then I would probably do the following:

Automate 3 post fade aux sends on each of the 2 actors faders sending to the 3 speakers.
Only fade these aux sends between out and full leaving the actual level to be set on the fader.

So for each of the actors possible moves (zone L to C, C to R, R to C C to L) you create a fire all children group which fades the aux levels from the starting zone to the destination zone. You are only using the auxes to simulate a LCR pan pot so are only using the control,values 0 or 127 for each aux.

Once you have set up the 8 group cues required that's the end of all the numeric input.

So for example. when actor 1 moves from L to C you would use a start cue targeting the move actor 1 from L to C group cue. No level matching is necessary

However in most cases (and I acknowledge that your case may be an exception) superior imaging and localisation of the actors reinforced voice to her onstage position would be achieved far more simply by delaying the microphones so that the actors voice arrives at the listener before the sound from the loudspeakers.

Some of the required delay could even be provided by increasing the size of the audio buffers!

[Patrick Spadrille]

I’m not sure about what you propose to be superior imaging and localization. Delaying the microphones and actors and having sound, i suppose, coming from all speakers? Doesn’t that create something unnatural? I’m looking for a technique that make the amplification of actors almost « invisible » . When i was working that way with the mic cues (which was sometimes causing audio interferences) most people in the audience didn’t know i was using mikes but was amazed how good they heard the actors even if they didn’t seem to speak very loud. That was the plan since it’s a very intimate play.

[Andy Lang]

On Sat, Apr 19, 2014 at 1:10 AM, Patrick Spadrille <patrick....@gmail.com> wrote:

I'm not sure about what you propose to be superior imaging and localization. Delaying the microphones and actors and having sound, i suppose, coming from all speakers? Doesn't that create something unnatural? I'm looking for a technique that make the amplification of actors almost << invisible >> . When i was working that way with the mic cues (which was sometimes causing audio interferences) most people in the audience didn't know i was using mikes but was amazed how good they heard the actors even if they didn't seem to speak very loud. That was the plan since it's a very intimate play.

What Mic proposes is indeed a superior and successful way to provide natural imaging, practiced on every Broadway show, tour, and most off-Broadway and regional shows. It's called precedence delay, an implementation of the Haas Principle, and the short version is that, under about 35 ms or so, your brain coalesces arrivals of the same sound together, rather than hearing it as an echo, and assumes that the first sound to arrive is the original source.

So if you hear the actor's voice arrive naturally ever so slightly before the sound from the speaker, your brain assumes that all the sound is coming from the actor. It's not crazy theory, it's actually been proven in practice time and again.

It's far superior to panning, because it does not change over wide areas of seating. With panning, it's impossible to get consistent imaging and sound quality to an entire theatre, as something panned hard left will be too loud for those near that speaker, and too soft for those seated far right. With a properly aligned mono system, you time things so that the entire system (such as underbalcony fill speakers) delays back to the center cluster, so that the entire system behaves coherently as a single source. Then, the signal feeding that system is further delayed, to allow the actor's voice to reach the audience slightly before the amplified signal, and bingo, if the system is aligned and tuned properly, it sounds like the voice is coming from the actor.

With a few different delay zones for different distances, often there's not even any need for compensating left/right, provided you're using a center cluster. If you're only using left/right speakers, you may need to do further left/right groupings to allow the delay to steer the image to the appropriate side of the stage. This is a system that can work in any space, of any size, given a properly designed sound system. Stereo or LCR panning simply will not work as well in almost any space, without lots of speakers and very careful system design and calculation, paying close attention to dispersion patterns.

(The very short version is that, to get proper stereo imaging, you need a system where the patrons seated nearest the speaker location get the signal 6 dB below the patrons on the opposite side of the venue. Think about what that entails for a second! For a longer explanation, see this article: http://www.rane.com/note164.html )

And on that note, have a fantastic weekend, folks!

-Andy

[Patrick Spadrille]

That’s very interesting. I’m eager to try that (which will be in 10 days). Is there a way to measure the sound delay between the actor and the speakers in Qlab. In MainStage, the program shows this delay when you change buffer size. I haven’t found that in Qlab?

[fishmonkey]

On Saturday, April 19, 2014 4:16:49 PM UTC+10, Patrick Spadrille wrote:

That’s very interesting. I’m eager to try that (which will be in 10 days). Is there a way to measure the sound delay between the actor and the speakers in Qlab. In MainStage, the program shows this delay when you change buffer size. I haven’t found that in Qlab?

it's not actually possible for the software to know exactly what the processing latency is, since it usually relies on the reporting from the audio device driver, which may or may not be correct (the only way to know for sure is to do a loopback measurement). calculations using your audio buffer size will give you a ballpark figure (assuming you aren't doing any latency inducing processing on the mic audio), and from there you can tune it by ear using a delay plugin...

[craig k]

Patrick,
I have been following this problem of yours and I think you must agree that what you are trying to achieve is much more complex than what you first requested help with in the previous thread.
However, now that we know more about your project, here are a couple of other ideas for you. (unfortunately I don't have the time right now to research, and program these into trial code)

1. It might be possible to use Applescript to control MainStage (instead of MIDI). I haven't used the newest version so I'm not sure what the library is like now, but with other apps, you can not only move a fader to time, but also get it's current position. Or at least have Applescript trigger a cue change in MainStage?

2. Using a MIDI monitoring program, parse out any changes to the CC representing your fader right before the QLab cue, and that would be your current fader level. again Applescript can call to the monitor program to get the fader value.

Short of all this, I'm afraid you really might have to go and rent a small yamaha or something that will allow you to do this in hardware.

Good Luck, and let us know how you make out.

Craig K

[Patrick Spadrille]

Craig,

You're right. at the beginning i was thinking it was a basic question and i managed to open a big debate about the why and how and what's the sense of life! ;-)

About your propositions :

1. It seems great but right now i don't know anything about scripts and even if it seems powerful, i'm kind of scared about learning codes even if it's supposed to be a "user friendly" code

2. Great solution again. But apple script again :-(

Renting or buying a Yamaha or other i'm afraid it's out of my budget. I think what is more in my budget is buying a sound card only for the mikes, with his own buffer size and use the good old mic cues from Qlab. The mikes comes in the card and comes out of the card and the hardware mixer will mix all that with the sound from the other audio card. I think that's by far the easier solution at a cheaper cost.

[craig k]

Sound like you have a plan then,

Best of luck, and please do report back on how everything works out. Especially if you get a chance to play with some delay on the vocals to work out your imaging.

Craig K