QLab 3 and Behringer X-Touch

[Freddy Komp]

Hi good folks at Figure 53,


Still on the search for the features to tip me over towards QLab 3 :P... and have potentially found something...

Is there a way to send all parameters of a selected cue via MIDI and/or OSC once selected? I am thinking of Behringer's X-TOUCH here, to allow for mouseless editing of i.e. levels and trims (motorised faders), crosspoints (led endless encoders) at the tip of a cue selection, maybe even sending the Notes or Q Name or QNumber to one of these nifty little LCD scribbles etc...

Basically, brave new world without smearing finger grease onto screens :)...

http://www.behringer.com/assets/X-TOUCH_P0B1X_Top_XL.png


Just a thought.


Cheers,

Freddy

[Sam Kusnetz]

Freddy Komp wrote:
> Is there a way to send all parameters of a selected cue via MIDI
> and/or OSC once selected? I am thinking of Behringer's X-TOUCH here

The X-TOUCH, as far as I can tell, only speaks MIDI, not OSC, so what
can be done is pretty minimal.

Via OSC, you can access quite a few parameters of the currently selected
cue via OSC commands that begin with "/cue/selected" so if the X-TOUCH
did speak OSC, there would be some real possibilities there.

You can read up on our OSC API here: http://figure53.com/qlab/docs/osc-api/

Cheerio
Sam
--
Sam Kusnetz
QLab Field Operative
s...@figure53.com

[Freddy Komp]

Thanks Sam,

sooo... I had a bit of a read, but still have questions :)...



I see if you would have to (as an OSC client) request updates, so:

A) can you send a generalised update request - i.e., all workspaces who are at this specific IP address will automatically react to this request?

B) Once cuccessfully registered with a workspace, I understand QLab would send the following command when the playback position is changed: /update/workspace/{workspace_id}/cueList/{cue_list_id}/playbackPosition {cue_id} , correct?

C) That would only send the cue_uid, as opposed to all related properties of the cue, correct? So in order to set a controller, you would then somehow use the supplied cue_id to request all of these individual properties, correct?

If I am assessing this correct, than the process of trying to achieve what I am proposing is looking a bit arduous... any plans to change it?

OSC is not the biggest problem (i.e. OSCulator could translate), but this whole backing and froing might be a bit much... obviously up for a challenge ;P....

Has anyone had any experience yet with setting the LCD scribble with anything programmatic (as opposed to using their editor software)?


Cheers,

Freddy

[Drew Schmidt]

Correct me if I'm wrong, but the thing I've found that stops any interaction with a workspace is primarily the JSON response. This is a problem even with TouchOSC. 

I can command QLab all I want (Which I adore. People just assume when a random sound happens or lights turn on in the theatre while I'm on my phone that I made it happen wirelessly). But I can never receive information to adjust values in TouchOSC because the response isn't simple text. 

The second problem would be the /reply suffix for the return address. Any button, knob, fader, etc would be defined as a given OSC address and assumes it sends and receives on said address. So a reply that starts with "/reply" will never find its way back to the originating button, knob, fader.

Finally, as Freddy pointed out, many of the OSC address structures include {workspace_id} and {cue_id} elements which are essentially hidden to the user. You could however utilize some of the more relative address such as "/cue/selected/{whatever}" which would address the currently selected workspace / cue. Using this you could command QLab with your device. But if those very specific address elements are included in the reply, again, that ruins the ability to identify the response.

QLab's OSC is an amazingly powerful tool, but it's not built for or meant for custom workspaces (except of course for the QLab remote app).

I've thought creating an app that lives in between. Some python script that dumbs down JSON and restores the original address. I haven't tried very hard. Or at all beyond just thinking about it. 

[Christopher Ashworth]

(mobile)

> On Sep 4, 2014, at 7:10 AM, Drew Schmidt <drew.s...@nwciowa.edu> wrote:
>
> Correct me if I'm wrong, but the thing I've found that stops any interaction with a workspace is primarily the JSON response. This is a problem even with TouchOSC.
>
> I can command QLab all I want (Which I adore. People just assume when a random sound happens or lights turn on in the theatre while I'm on my phone that I made it happen wirelessly). But I can never receive information to adjust values in TouchOSC because the response isn't simple text.

This is something we're interested in improving.

The current reply format is very good for certain environments but not good for others. A simpler reply format is something we'd like to explore.

>
> The second problem would be the /reply suffix for the return address. Any button, knob, fader, etc would be defined as a given OSC address and assumes it sends and receives on said address. So a reply that starts with "/reply" will never find its way back to the originating button, knob, fader.

Interesting; I wasn't aware of this structure in TouchOSC. Could look in to an option to turn off the "reply" along with a simpler message back.

>
> Finally, as Freddy pointed out, many of the OSC address structures include {workspace_id} and {cue_id} elements which are essentially hidden to the user.

Yes, much of the OSC API is currently designed for use by programmers. For those parts it's not really going to help you if you're not a programmer.

C

[Christopher Ashworth]

Although if you ARE a programmer I highly recommend our open source project which does all the work of communication for you:

https://github.com/Figure53/QLabKit.objc

(mobile)

[Freddy Komp]

Hi again,


Still trying to track down an actual pdf manual, but I am actually assuming that the LCD scribble strips are likely to be OSC, as the device has an ethernet port, and OSC seems to be the way the X32 does its scribble strips, too...

But yeah, a go-between program to translate JSON to dedicated OSC addresses and information would be cool (until QLab offers this out of the box).


Cheers,

Freddy

[Drew Schmidt]

The X32 is an OSC unit. Its highly possible that the X32 Touch is as well

[Drew Schmidt]

I might try and learn Objective C to do this project in a couple of weeks. We have an X32 and I use TouchOSC (and osculator) a lot. I would love this.

Chris. Is this a long radar idea? Or simple "I have an itch on a Tuesday morning" type of project?

[Christopher Ashworth]

Sorry, which idea are you referring to?

(mobile)

[Drew Schmidt]

Crafting a simple reply version for OSC.

There sure are a lot of ideas floating around aren't there? Maybe we should stop using ambiguous pronouns.

[Chris Ashworth]

On September 9, 2014 at 8:38:12 AM, Drew Schmidt (drew.s...@nwciowa.edu) wrote:

Crafting a simple reply version for OSC. 

This will help:

https://github.com/Figure53/F53OSC

Apple has built-in code for encoding/decoding JSON.

If you are talking over TCP you’d need to talk to the utility app which would serve as a middleman between the client and QLab, since QLab will talk back on the same TCP channel that it receives incoming messages.

If you are talking over UDP, you should be able to send QLab OSC directly on 53000 but have your utility listen on UDP 53001 and translate the replies into some new action. 

I’d recommend trying the latter, as that shouldn’t be too hard since we already have the OSC code for you. You’ll just get OSC message from QLab, you can decode the JSON, then decide what to do with them.

-C

[Freddy Komp]

It's been a while, but since in another topic you guys flagged that you were a bit busy ;)... I am now seriously contemplating getting my head around Objective-C for this...

My plan - based on QLabKit and F53OSC, building a command line utility that takes as parameters simply incoming port, and outgoing address and port, and then goes ahead to simply parse the JSON and sends on the different variables included as distinct OSC messages... Therefore, it should then be allowed to send all OSC hooks that are offered in any particular cue automatically, both when moving the playhead position and when remotely moving any fader/knob/field in that cue, correct?

Or am I overlooking something? Anything from you Objective-C gurus that I should be looking out for? Or will my basic Java knowledge and a few online tutorials get me there just fine you'd think?

Hopefully all going well, a few weeks later, we'll know more ;). Planning to test this with an iPad, TouchOSC, and potentially (if needed) OSCulator for further formatting/changing of values, but ultimately to make use of control surfaces, even if they are more MIDI CC inclined. BTW, from looking at the way the X32 works, it does seem the scribble strips are configured via ethernet (will have to check, but assume via OSC), and since the X-Touch also has an ethernet port, I assume similar technology... ultimately of course the goal would be to then set the scribble strips dynamically when changing cues to reflect i.e. Channel or property names (when moving from an audio cue to a video cue).


Cheers,

Freddy

[Chris Ashworth]

Hi Freddy,

On January 21, 2015 at 9:24:03 AM, Freddy Komp (busy...@gmail.com) wrote:

It's been a while, but since in another topic you guys flagged that you were a bit busy ;)... I am now seriously contemplating getting my head around Objective-C for this...

My plan - based on QLabKit and F53OSC, building a command line utility that takes as parameters simply incoming port, and outgoing address and port, and then goes ahead to simply parse the JSON and sends on the different variables included as distinct OSC messages... Therefore, it should then be allowed to send all OSC hooks that are offered in any particular cue automatically, both when moving the playhead position and when remotely moving any fader/knob/field in that cue, correct?

It depends on what you are describing / trying to do.  It sounds like you’re describing the idea that a cue would send out changes to a fader when someone drags the fader, which is not currently what happens.  Right now it sends out granular “update” notifications when something about a cue changes, and it is a client’s responsibility to retrieve any updated values it might care about.

However, yes, you should be able to create a client that can act as an intermediary for any OSC messages that get replies, and translate the replies from QLab to whatever format you want to send back to, say, TouchOSC.

Or am I overlooking something? Anything from you Objective-C gurus that I should be looking out for? Or will my basic Java knowledge and a few online tutorials get me there just fine you'd think?

There’s a lot of good tutorial material out there for getting started, I think you should find helpful stuff.

-C

[Freddy Komp]

Hi Chris,

On Friday, January 23, 2015 at 1:24:40 AM UTC+10:30, Christopher Ashworth wrote:

It depends on what you are describing / trying to do.  It sounds like you’re describing the idea that a cue would send out changes to a fader when someone drags the fader, which is not currently what happens.  Right now it sends out granular “update” notifications when something about a cue changes, and it is a client’s responsibility to retrieve any updated values it might care about.

Scenario then:

1.a) I move an endless rotary encoder on i.e. a external MIDI Hardware one click to the right. This sends some MIDI Note or CC, which is registered in QL3 to move select the next cue, OR

b) A cue is selected locally (mouse/keyboard), OR

c) Any value of the current cue is changed through externally mapped MIDI or OSC faders, OR

D) Any value of the current cue is changed through local entry (mouse/keyboard)

2. All of these events trigger an OSC trigger/update notification/... to the intermediary program? Would this be correct?

3. The intermediary program then requests the cue as a whole (JSON) object.

4. QLab receives the request and sends the whole cue as a JSON object to the intermediary

5. The intermediary parses all variables contained in the JSON objects, converts/parses/sends their names as OSC addresses and their values as values of individual/simple OSC messages to an OSC recipient configured in the intermediate program,

6. Whether directly or through further translation in i.e. OSCulator, these values will then set motorised faders/encoders/scribble strips of an external hardware or TouchOSC controller.

While the setup sounds surely a bit complex :), the result would be intuitive and simple, kind of like a mackie control, Where your faders will always be at the right position at any given time (so no jumps or similar when moving them, and an instant visual update for manual control.

Did I understand it right how QLab's "update" functionality works here?

Cheers,

Freddy

[Chris Ashworth]

Hi Freddy,

I’d recommend spending a little time experimenting and reading the OSC API documentation, as I think it will clarify what exactly is being sent back and forth between a client and QLab.

It doesn’t, for example, send back JSON which represents an entire cue, it sends back replies to specific messages, the contents of which are encoded using JSON.

Playing with the QLabKit code and the F53OSC code will, I suspect, clarify some things more directly….

-C

Subject:  Re: [QLab] QLab 3 and Behringer X-Touch

[Freddy Komp]

Hi Chris,

Of course I take your point. And, I am of course happy to do that. However, I guess my point was, if there are general design restrictions currently in place that would prohibit me getting the scenario to work, then I would not bother to embark on a potentially tedious journey, if you know what I mean :)?

If it will be just a matter of me putting more time into my little go-between black box, then no worries; but if say QLab is not going to be able to actively let the black box know when a) the playhead has moved or b) a value has changed, then I would be wasting time and energy on a dead end...

Cheers,

Freddy

[Andy Lang]

Hi Freddy!

On Thu, Jan 22, 2015 at 10:00 PM, Freddy Komp <busy...@gmail.com> wrote:
> Of course I take your point. And, I am of course happy to do that. However,
> I guess my point was, if there are general design restrictions currently in
> place that would prohibit me getting the scenario to work, then I would not
> bother to embark on a potentially tedious journey, if you know what I mean
> :)?

The OSC API is a rather short document, relatively speaking, and will
provide a much more complete picture of what is or isn't possible than
one of us could here; what you're asking isn't the simple question you
may think it is :-)

Give it a read, and see if that answers your questions:

http://figure53.com/qlab/docs/osc-api/

I think you'll find that most of it is possible, at least in theory,
but may involve a bit of back-and-forth between your client and QLab
to get the data you're looking for, as QLab doesn't just spit out a
constant status stream. A lot of what you're asking is explained in
the API. If that doesn't clear it up, hit us back with specific
questions, and we'll be happy to clarify!

Best always,
Andy

[Freddy Komp]

Hi Andy,

I had read through the API earlier, reread it again in depth, and I believe I can make it work based on what I read. I tried to get the demo in QLabKit to work without alterations, (OSX 10.8.5, XCode 5.1.1, with latest QLabKit and F53OSC), and it threw this error in the built:

Undefined symbols for architecture x86_64:
  "_GLKQuaternionIdentity", referenced from:
      -[QLKCue quaternion] in QLKCue.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1

anything fundamental I am missing here?

Cheers,

Freddy

[Freddy Komp]

Sorry, got it - I simply needed to link the project against GLKit (hadn't spotted that in the notes) :)

[Freddy Komp]

*Sigh* Not to be a weakling, but I'm giving up for now... after hours of wading through code, I admit defeat, and admit that I am a procedural scripter at heart, and that GUI, delegates and notifications are perfectly able to mess with my tiny brains :/... It is certainly on days like these when I appreciate the professional product that you are developing and maintaining, which of course does go so much deeper than the little helper tools that I struggle with here...

So sorry, but yeah, until I break my legs and end up chained to a hospital bed with a comprehensive O'Reilly's on Objective-C, I will give up - waiting, perhaps in vain, that the OSC response format of QLab will become more Control-Surface-friendly out of the box :)...

My dream would be that if one could configure somewhere (i.e. with a /updatesComprehensive message?) that any OSC client that has registered with QLab like that for comprehensive updates gets an inferno of individual OSC messages, giving i.e. all OSC discoverable information about the currently selected cue as individual OSC messages when i.e. the playhead moves, then one could easily create a proper TouchOSC or Control Surface setup...

I also wandered if it would be possible to consider adding a different OSC syntax, both to the existing format, as well as what you might develop in the future, making more use of i.e. arrays for information that can be important, but can also be superfluous and annoying :)... i.e.:

Would it be possible to ADD (not replace, in order to not break anything) an /update/playbackPosition [{workspace_id},{cue_list_id},{cue_id}] message that way the address could stay the same, and one could decide what to do (i.e. in OSCulator) by splitting the triggered reactions...?

I know you guys support Wildcards (brilliant), but unfortunately two of the major OSC related tools out there (OSCulator and TouchOSC) do NOT comply with OSC standard by not offering wildcard support... therefore it is really hard to "ignore" workspace and cuelist ids for the sake of simply knowing which is the current playhead position of the front workspace... and correct me if I am wrong, but cue_ids are unique across the whole workspace anyway, right?

Anyway, a bit of a rant, but that's frustration for yer :)...

[Drew Schmidt]

I've been working on a Python solution for this same issue. It's mostly up and running, I just need a few more "code and coffee" mornings where my kids don't wake up early too. The idea is that it's a bridge between TouchOSC and Qlab. I think I'm going to adapt it for our X32 as well. No real reason to do so. Just want to see if I can. So please, don't be discouraged yet! 

[Freddy Komp]

Hi all,


So, I finally have a Behringer X-Touch, yay... beautiful unit, BUT (currently) only speaks Mackie Control or HUI (they have not released it with the ability to speak to the X32 yet *sigh*)... question, does anyone know of a successful middleware that fully implements Mackie Control and translates it to either MIDI CC or (even better) OSC? I found this one here http://sourceforge.net/projects/controsc/ , but it is source code only and seem to have been abandoned after a very nice proof of concept with a Mackie C4 in 2009.

Any help would be greatly appreciated :D!


Cheers,

Freddy

[Freddy Komp]

Hey Drew,


Any more developments within the JSON to configurable OSC or MIDI go-between-allstar-bridge :)?

Currently working with LC Xmu, which translates mackie control to midi for me... together with OSCulator, I can set values from the Behringer X-TOUCH...

now for the way back from QLab, through the incredible machine (still one of my favourite games) back to the X-TOUCH...

Cheers,

Freddy