Control surfaces for faders?

[Patrick Spadrille]

Is there a possibility to use a control surface for setting the faders? If not it would be very useful to use in Audio Device & Levels and Trim, in Fade Levels and in device routing. Even for audio effects.

[Dominic Hargreaves]

+1, this would be a great idea.

Cheers,
Dominic.

--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)

[Rich Walsh]

http://figure53.com/qlab/remote/

[Dominic Hargreaves]

I think what Patrick (and certainly I) are suggesting is integration
with things like:

http://www.mackie.com/products/mcupro/

(to take a random example from google, I don't have any experience with
them so far). I think I'd be a lot happier using a hardware fader module
than the touch screen of a general purpose tablet for tech/design purposes.

> --
> --
> 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/groups/opt_out.

[Rabyn]

And if the MCU protocol was supported, scrub would be really handy for going back 30 sec during tech :)

Also with MCU support there are lots of hardware and iPad options. V Control being one of them for IPad.

ra byn (robin)

[Patrick Spadrille]

Indeed i meant a physical control surface with button and real faders. QLab IPad remote is great but you can't control the device routing with it and for the rest the faders are really tiny on it. On a Mac Book Pro you have to adjust the fader one at a time and it's not easy with the mouse. Really time consuming when you have a lot of faders to adjust. On the iPad you can use multiple fingers but you have to be really precise and to look at the screen and even with that, good luck moving more than 3 faders at the same time on the first try. I really would prefer big standard physicals faders that i can put all down or half volume in one second without even looking at it. I think we would be a lot willing that.

[Paul Gotch]

On 13/05/2013 23:50, Patrick Spadrille wrote:
> Indeed i meant a physical control surface with button and real faders.

So this could be done with a Behringer X32 which generates OSC. What is
needed is a mapping tool turns the X32's OSC messages into QLab OSC
messages and vica versa.

-p

[Patrick Spadrille]

Yes but are faders in Qlab controllable by OSC?

[Paul Gotch]

On 14 May 2013, at 08:55, Patrick Spadrille <patrick....@gmail.com> wrote:

> Yes but are faders in Qlab controllable by OSC?

Yes, the nature if OSC is such that it's more of a spec of how to transport messages between two places rather that what those messages are. Hence the need for something to translate what the X32 is saying into something QLab could understand.

A starting point for this would be figure53's OSC code which they have published on GitHub.

-p

[Freddy Komp]

Chiming in here, as this is on my MAJOR wish list since... well, since Filip Vandueren released his MIDIPipe "Set levels with MIDIPipe"...

currently, this is what I got to work:

1. QLab 3 Speaking to OSCulator (and vice versa)
2. Korg NanoKontrol2, set up in OSCulator to interpret the 0-127 MIDI values of one fader as -60 to +12, and then OSC re-routed (with address re-writing) to write into /cue/selected/sliderLevel 0

Here my questions/issues:

a) There is still quite a bit of lagging, each time you move the fader (obviously, ideally the goal is to set levels as the cue is playing)... i.e. if I slide the fader on the nanoKontrol, it can take around 2-4 seconds for the audible level in QLab to keep up. Is there any way to streamline this? In the past, (i.e. in Lighting software), I have never experienced such lags, so I suppose it will not be OSCulators fault...? It would be an extremely powerful way to quickly and intuitively set levels on the fly... Oh, and as I am still in "discussion" with myself until the next pay rolls in, I hadn't bought QLAB3 or the ipad remote yet... but I wonder, is that lag similar when controlling levels in there?

b) If I read the OSC API description right, there is currently no way to actually adjust the TRIM as opposed to the LEVEL - I don't know how many audio people do their best practice audio here, but I usually set the trim of a track first (to get from the director the correct level for the track in general, and then create standard fade cues with scripts to fade from -inf to 0 and back.. (and dips). My point is, being able to automate/set trim levels on OSC would be rather important to me...

c) how cool would a control surface integration be... imagine, motorised faders swinging to action, each time you select an audio cue, (depicting the current TRIM?), and maybe when on Fade Cues, depicting LEVELS? The teching process would speed up significantly...


In many ways, getting this working reliably, fast, smoothly would be a major selling point for me... I guess, my question is, what are the chances :)?

[Jeremy Lee]

Interesting. I can't tell you the last time I used the TRIM sliders. I always use the levels faders. What do you gain from doing this?

Jeremy Lee
- A thumb is a terrible speller. Please forgive my trespasses.

[Freddy Komp]

Hm, primarily it comes from the notion that quite a few directors I have worked with seem to be happy/wanting to set an overall level for the track, and potentially add F/I and F/O to it; even with builds and dips in it, often I get "can the track as a whole be louder (or softer)";

So the way I usually work is
- load to time somewhere after a potential intro bit or potential fade/in
- set trim until director is happy
- create f/ins and outs as desired (these, I have as standard scripts on hotkeys (5sec f/ins, 7secs f/o); in case of f/i, it automatically sets the level of the track to -inf, and then creates the fade cue to zero)
- if during the track, builds and dips are asked for, the hotkey scripts I am running reference the level of the selected cue and raise/lower it by 10db in a new fade cue. So these build and dips work kind of similar to relative fades on whatever cue is selected when executing the script, but set it as (calculated) absolute fade values (which I find easier to use for adjustment and communicating with other people over).

All these scripts automatically create cue names that describe their actions (i.e. fade cues that read "DIP: <original track name>" or "F/O: <original track name".

The reason why I use this is in my best practice stems from wanting to give as much information to whoever is looking at the QLab screen (i.e. me, when I am programming, or even the operator, to be able to see what is going on when). For similar reasons (of optical, logical structure) I tend to work with fire-all-children-simultaneously groups, which on top-level represent the operator-executed cues, and can have nested group cues with pre-waits for follow-on situations. At one glance you see what is happening together, what is following together, and if you are not interested in seeing the "guts", you can collapse it all, and only see the operator-executed cues as one-liners. I do tend to avoid most auto-continue and auto-follow "arrows" on the right, as they don't provide that same optical clarity to most people (I find). And of course, I work similarly with Video and Animation cues.

I have attached a screen shot to illustrate :). Of course it would be interesting to see if anyone out there works in similar ways, or if I am just really really strange :)...


Cheers,

Freddy

[Freddy Komp]

Just thought I'd give this topic another 'nudge' - either or (i.e., either if you plan to incorporate OSC access to Trim or not), it would be good to know if OSC control of Levels can be as instant as dragging a level fader with a mouse/trackpad)?

[Christopher Ashworth]

On May 20, 2013, at 5:21 AM, Freddy Komp <busy...@gmail.com> wrote:

> Just thought I'd give this topic another 'nudge' - either or (i.e., either if you plan to incorporate OSC access to Trim or not),

sure, I can add that

> it would be good to know if OSC control of Levels can be as instant as dragging a level fader with a mouse/trackpad)?

Are you saying you have tried it and it is not? Or that you wonder if it will be?

[Freddy Komp]

Yes, I have tried - korg NanoKontrol2, through OSCulator, talking to QLab3 through OSC = Lagging behaviour of the adjustment (similar to what I experienced setting it in QLab 2 through Applescript/MIDIPipe). i.e. a growing delay (not sound delay, but delay for the sound levels "arriving" at the level they are set at), based on how many MIDI Values are being scrolled through. This happens as the track in question is playing, and as I adjust the level in real time. By the power of deduction ;P (by the powers of Greyskull?), it is a behaviour that I have not seen before with the same HW/SW combination between the korg and OSCulator (i.e. sending the fader values to LX software via OSC = instantaneous results).

And thanks for putting Trim on the list :D!

F.

[Christopher Ashworth]

On May 21, 2013, at 4:18 AM, Freddy Komp <busy...@gmail.com> wrote:

> Yes, I have tried - korg NanoKontrol2, through OSCulator, talking to QLab3 through OSC = Lagging behaviour of the adjustment (similar to what I experienced setting it in QLab 2 through Applescript/MIDIPipe). i.e. a growing delay (not sound delay, but delay for the sound levels "arriving" at the level they are set at), based on how many MIDI Values are being scrolled through. This happens as the track in question is playing, and as I adjust the level in real time. By the power of deduction ;P (by the powers of Greyskull?), it is a behaviour that I have not seen before with the same HW/SW combination between the korg and OSCulator (i.e. sending the fader values to LX software via OSC = instantaneous results).

I must admit I've never used OSCulator — I tried once, took one look at it, and gave up. Couldn't figure out how to do anything with it.

I'll put a note down to test this as I'm working on the other reported OSC API issues. I don't believe there is a reason it would lag, but I'll see if I can find something.

-C

[Freddy Komp]

Thanks, and yes, getting into it was a bit of a learning curve; Once configured though (i.e. MIDI input devices, as well as OSC output routing), OSCulator adds triggers automatically (i.e. when you move a fader on your nanoKONTROL2, your list of routings will grow by a new line named after that specific CC that you have touched. next to that, you select the action (i.e. executing an applescript, or i.e. OSC routing), and then next define the specifics of your action (i.e. the specific AppleScript, or a specific OSC routing). The OSC address can be completely re-written/translated, and the relationship between incoming values (i.e. 0-127 MIDI) and outgoing values (i.e. -60dB to 20dB) can be freely defined.

As I said, mainly because of my ipad based keystoning, I can not switch to QLab 3 just yet - but I guess my question is, via your QLab remote ipad app, is the setting of levels on the fly (while the cue is playing) rather instantaneous? or does that lag in similar ways? I wonder if a "maximum time-resolution" for receiving these OSC commands might be needed; a sort of filter that will only action something like 25 commands per second per cue level, and does not cue the others but discards them, so that there is not a growing cue that needs to be processed until done? Just guessing, of course :).

Please let me know if there is anything you would like me to test on this, or if you would like things like the OSCulator file for the nanoKontrol 2  etc...


Cheers,

Freddy.

[Lucas Krech]

I've got a 1 not a 2 but can attest to lag certainly with MIDI controlled QC patches. I find it is a bit of a wake-up delay and once moving is decently responsive. Given I paid something like $60 for the controller I don't really expect zero-delay precision.

-L

On May 23, 2013, at 5:49 AM, Filip Vandueren wrote:

Actually i've seen the same behaviour with Midi-patches in Quartz Composer with the NanoKontrol2

Lagging behavior when more then 1 fader is moved.

I always figured it was a fault of the cheap Korg…

[Patrick Spadrille]

Yes, i really would like to do that without any additional software.

Le samedi 25 mai 2013 00:02:40 UTC+2, vampiredmx a écrit :

Hi, what I would really like is the ability to select a fader  or other control in Qlab and then move a fader on my control surface and it is automatically mapped, this is the type of behaviour that is found in Ableton Live.  It is very easy in live to create on the fly mapping of faders and buttons without the need for additional software.

Vampiredmx

[Jeremy Lee]

It seems like some sort of hardware box that speaks OSC is the way forward here.

-- 

Jeremy Lee

    Sound Designer, NYC - USA 829

        http://www.jjlee.com

[Patrik Wipp]

http://www.lividinstruments.com/hardware_code_details.php#specs  ?

Ha det bra!
Patrik Wipp

pat...@wipp.se
Wipp MultiMedia AB
Huvudstorpsvägen 297
244 95 Dösjebro
Tel 0418-66 08 06
mob 0705-919583

2013/5/26 Jeremy Lee <jer...@jjlee.com>

[Patrik Wipp]

or: http://www.cmlabs.net/index.html  ?

[Rich Walsh]

I'm intrigued to know how you would use such a function in your QLab workflow: I've bought the iPad app and been impressed by how responsive it is, but it doesn't provide functionality I desperately need – I can get along just fine with a laptop and screen sharing, and rarely move a virtual fader, let alone wish I could grab a real one. So, how would you use this? For programming, or for real-time live use?

I've used Ableton Live many a time, and for me it provides the opposite end of the functional spectrum to QLab. I use Live when I have fluid, half-formed ideas that require random access; I use QLab when I need a locked-down linear progression through a sequence of cues. To look at it another way, Live (and a good old mixing desk) is about mixing many things together to a few outputs, whilst QLab is about playing a few things at a time to many outputs. You only have to look at the UI: Live allows you to see multiple tracks at once and work with them together – with a detailed view for individual clip tweaking – whilst QLab only really allows you to work on one cue at a time.

So, would your flying faders grab the currently selected cue and present all 49 master faders for instant access (or is it 1,225 crosspoints you need to map to a fader?)? I honestly can't think of a time where I've needed to manipulate the outputs of a single cue using all ten digits rather than just tabbing around a bit and typing – and always using bump scripts to slide the master level up and down quickly, of course.

I could possibly see the appeal of having the master levels of the active cues list dynamically appear on faders, but cues pass fleetingly through the active cues list like neutrinos in an underground swimming pool, so my faders would be reassigning faster than I could ever find them and move them…

As I've said before, I hardly use a mouse when in QLab, so I'm genuinely fascinated by why someone would need physical faders. Do please explain!

Incidentally, it seems to me that if you knew more than nothing about Max, PD, Reaktor or Plogue Bidule you could knock up a runtime plugin that could sit in a Mic Cue and convert MIDI to OSC for you. Starting from scratch I've almost made a single fader do this; does anyone know enough about one of these applications to create something like that?

Rich

[Christopher Ashworth]

By the by, part of our plans for the iPad app were to start simple and work on adding things as it became clear what was really important, so everyone please feel free to let us know what it is missing and that will help guide our work on it.

[Lucas Krech]

A phone version…

-L

[Joey Buddenberg]

I second Lucas... But a simpler layout.

[Adam]

 -- Access To Crosspoints
 -- Scrubbing
 -- Access To Workspace Preferences
 -- Pause & Reset Buttons
 -- Redundancy Control Mode (MSC and/or MIDI)

[Andy Leviss]

On Sunday, May 26, 2013, Christopher Ashworth wrote:

By the by, part of our plans for the iPad app were to start simple and work on adding things as it became clear what was really important, so everyone please feel free to let us know what it is missing and that will help guide our work on it.

On the simple (seeming) end, a "quick flag" mode where the whole screen is just a huge "flag currently playing cue" button on an iPhone would be quite handy during previews. 

-Andy

[Sam Kusnetz]

Andy-

No snark intended here: if eight cues are playing, would it flag all eight?

Cheerio
Sam

Andy Leviss wrote:

[Andy Leviss]

On Fri, May 31, 2013 at 11:25 AM, Sam Kusnetz <s...@figure53.com> wrote:

No snark intended here: if eight cues are playing, would it flag all eight?

None taken, it's a great question. And for the answer, I'm not sure. I can make a reasonable argument that yes, it should, or that it should flag the last triggered cue. 

My thinking is just that it'd be really handy during previews to just be able to flag so you can go back to whatever problem you heard and suss it out, without having to scribble down or type a note in the dark.

I can almost see an argument for a third-party(?) companion app that would just log "flags" with notes of what cues were running/their elapsed time, and then you'd pull that list up at the notes session to look at it. Hmm...

-Andy

[Joshua Langman]

Or those notes would be displayed in the "broken cues" panel.

[sam kusnetz]

> I can almost see an argument for a third-party(?) companion app that
> would just log "flags" with notes of what cues were running/their
> elapsed time, and then you'd pull that list up at the notes session to
> look at it. Hmm...

hmm indeed! quack, quack!

sk
--
sam kusnetz, sound & projection design | USA-829
503.201.2591
s...@notquite.net

[Dave "luckydave" Memory]

On Friday, May 31, 2013 at 11:37 AM, Andy Leviss wrote:

My thinking is just that it'd be really handy during previews to just be able to flag so you can go back to whatever problem you heard and suss it out, without having to scribble down or type a note in the dark.

That's pretty much the entire intention of flags. I'm sure they'll be used in a thousand scenarios, but when we were playing with QLab Remote in the early days, that's specifically the use case we imagined, which is why we came up with flags. In QLab Remote, it's very easy to select a cue, flag it, and add notes. The thing that makes it so handy is you have a list of active cues, so you can flag one specific cue. If you have a Start All group, or auto-continued cues, there's potentially a long list of cues to flag if  you're just going with "last triggered", so that could be cumbersome. With the active cues list in QLab Remote, you can flag only what's relevant.

Also, flagged cues show up in the Broken Cues and Warnings pane.

-- 

luck...@figure53.com 

[Charles Coes]

wait, there isn't supposed to be an echo... is there?

Charles Coes
cco...@gmail.com
www.charlescoes.com
"Forms and rhythms in music are never changed without producing changes in the most important political forms and ways" - Plato

[Sam Kusnetz]

Charles Coes wrote:

wait, there isn't supposed to be an echo... is there?

indeed no... that was two separate quacks, there.

s

[Joshua Langman]

It would be great if, instead of using the "notes" panel, which as I understand it is for ops, the designer could enter separate notes that would show up in Broken Cues & Warnings — i.e., enter a custom reason why a cue is broken or flagged.

[Dave "luckydave" Memory]

On Friday, May 31, 2013 at 1:06 PM, Joshua Langman wrote:

It would be great if, instead of using the "notes" panel, which as I understand it is for ops, the designer could enter separate notes that would show up in Broken Cues & Warnings — i.e., enter a custom reason why a cue is broken or flagged. 

Well, notes are for any reason. They're just notes. If you use them to take notes to yourself, you're doing it right. If you use them for operators, you're doing it right.

-- 

luck...@figure53.com

 

[Joshua Langman]

Yes, of course, but my point is that I think it would be beneficial for QLab to recognize two types of notes — one that shows up in the Notes panel, and the other which relates to the reason cues are flagged. These seem like sufficiently distinct purposes that it would make sense to separate them in the program and treat them differently.

[Christopher Ashworth]

On May 31, 2013, at 11:44 AM, Dave luckydave Memory <luck...@figure53.com> wrote:

On Friday, May 31, 2013 at 11:37 AM, Andy Leviss wrote:

My thinking is just that it'd be really handy during previews to just be able to flag so you can go back to whatever problem you heard and suss it out, without having to scribble down or type a note in the dark.

That's pretty much the entire intention of flags. I'm sure they'll be used in a thousand scenarios, but when we were playing with QLab Remote in the early days, that's specifically the use case we imagined, which is why we came up with flags. 

I should clarify the historical record here, since luckydave didn't have the benefit of being in the room when flags were introduced.  

It was actually during a visit by sound designer Veronika Vorel, before QLab 3 was out.  I was showing her what we had so far and she asked if she could flag cues, and I wrote it down immediately as something to add because it was obviously a good idea.  But her idea, not ours.

-C

[Freddy Komp]

Hi Rich,

I realize I am still owing an answer :)... So, for what it's worth, my two cents behind my control surface aspirations...

A) Call me a simpleton, but I rarely (not never, but rarely) need more than 2 channels in an cue, and have never used more than 8, spot speakers and all. I also hardly use adjustments of cross points. I am certainly not a brilliant sound designer, but I am sure this user profile does not represent a negligable minority ;). In short, in almost all shows I have worked on, the meaning/connections of the faders does not change a lot from cue to cue, and rather the Level Faders of each cue are used to adjust the balance of L+R where necessary.
B) maybe it should be a mode that can be switched on or off (so as to not destroy motorised faders along the way ;)), but what I dream of when the control surface is connected (for programming, not for ephemeral live adjustments) is this:
 1. Whenever I move the selector/playhead onto a cue, it automatically adjusts the motorised faders of let's say the first 8 channels to the value recorded in that cue (or better - configurably to whatever channel level, trim, or crosspoint! The idea of going into an "edit surface connection mode" where you can click on any of the moving parts of QLab, then move the connected control surface of your choice, and have thus assigned whatever the control surface spits out to the selected QLab item sounds amazing)
 2. I quickly, and intuitively touch it up - I know that you can or could do this with buttons/scripts, but let's face it a fader that gives you a tangible, touchable, absolute position is something that we know and love from other workflows, so why not here?
 3. by touching it up, I have permanently set/changed the level/trim/crosspoint recorded in that particular cue. Without tabbing myself through fields, without doing maths, without adding or subtracting pre-defined values to the volume n times - just by touching a fader.

So as I said, this control surface action could be toggled on or off, depending if you are programming or running the show (in that respect, it could be even coupled to the Edit/Show mode toggle), and could work with controllers like BCF2000 (maybe with a Mackie BabyHUI emulation?).

Does this make sense? I do feel there is quite a broad spectrum of how users use the wonderful tool that is QLab, and for some, this feature might be arbitrary, but I do think that for some (including me) that work a lot with simple stereo shows, it would certainly create a brilliant, intuitive workflow.

Thoughts?