OSC Question

[John Huntington]

I'm trying to fire QLab from Medialon Manager using OSC.  Manager doesn't currently have OSC support built in, so I'm writing the commands directly in raw ASCII to the output.

I have the systems connected, and can ping back and forth between the IP addresses, and I'm targeting port 53000 (which shows up on the QLab OSC page but not in the documentation).  I have the "Use OSC Controls box checked.  We own a site license, but I'm running the free QLab version (long boring departmental bureaucracy story).

Sending via UDP, I can see the messages going out via Wireshark on the PC, but I don't see any reply.

Sending via TCP, I can see the messages going out via Wireshark, and I get a TCP ACK back from the QLab IP address, but I don't see the actual response I'm looking for.  When I terminate QLab, I see a whole bunch of TCP errors in Wireshark, so it does seem like it connected to the program.

I'm starting with very simple messages:

/version

/workspace/go

/cue/1/start

I tried these with appended 0A 0D (CR/LF) and without.  

I also tried the OSC message capture feature in QLab, but it didn't show anything...

Any suggestions?  

Thanks!

John

www.controlgeek.net

[daniel....@gmail.com]

Regarding Qlab's OSC capture, it doesn't seem to register OSC commands that are already used in its API. So for example if Qlab was receiving cue/1/start, that command wouldn't show up in the custom OSC command window.

[John Huntington]

Thanks...

John

[Christopher Ashworth]

Hi John,

Apologies for the delay. A few thoughts:

If you go to QLab --> Preferences --> Logging Level: 2 you will get log messages associated with the incoming OSC messages. You can review these log messages using the /Applications/Utilities/Console.app

For example, the "/cue/1/start" message would produce something like:

2013-07-01 16:25:41.737 QLab[18716:303] [UDP socket 127.0.0.1:53001] sent OSC message: /cue/1/start

If you are using 3.0.6, there is another option to turn on even more debug logging.

From the command line, enter:

defaults write com.figure53.QLab.3 debugIncomingOSC -bool YES

This will produce output such as:

2013-07-01 16:32:26.810 QLab[18716:303] Incoming OSC message:
2013-07-01 16:32:26.810 QLab[18716:303] /cue/1/colorName
2013-07-01 16:32:26.810 QLab[18716:303] arguments:
2013-07-01 16:32:26.811 QLab[18716:303] string: "green"
2013-07-01 16:32:26.811 QLab[18716:303] [UDP socket 127.0.0.1:53001] sent OSC message: /cue/1/colorName green

One potential hazard in writing the commands directly in raw ASCII is the necessity of padding various fields to multiples of 4 bytes. (In OSC everything is null-terminated and a multiple of 4 bytes.) I'm sure you're already aware of that, just figured I'd mention it as something to double check.

Hopefully the above logging output provides a lead. Let me know if I can help troubleshoot further.

-C

[Christopher Ashworth]

On Jul 1, 2013, at 4:36 PM, Christopher Ashworth <ch...@figure53.com> wrote:

For example, the "/cue/1/start" message would produce something like:

2013-07-01 16:25:41.737 QLab[18716:303] [UDP socket 127.0.0.1:53001] sent OSC message:   /cue/1/start

I should clarify, the output here is confusing.  The socket QLab is logging here is the one it will reply on.  In the case of UDP it will reply on 53001, so the log message that port 53001 "sent" that message is misleading. 

A product of internal logic being exposed; this detail wasn't thought through in the context of public consumption!

The actual lines from the code look like:

    if ( [F53Environment logLevel] >= 2 )

            NSLog( @"%@ sent OSC message:   %@", message.replySocket, message );

-C

[John Huntington]

Thanks, I've had to move onto other projects now and I won't likely get back to this until late July or August, but I bet it's that byte padding which I forgot about.  One of the things I hate about OSC :-)

John

--
--
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.
 
 

-- 
--
www.controlgeek.net

[John Huntington]

OK, I've made a bit of progress, but now have a new question :-)  You were right--I forgot the null padding, and also left out the argument type tag indicator.

So, to send the "Version" command (the simplest one, it seemed to me), you have to actually send (where the "!" indicates to Medialon Manager to send the associated hex value of non-alphanumeric ASCII characters):

/version!00,!0A!0D

The null (!00) is there to indicate the end of the "version" string, and must round out the string to a total byte count (not including the "/") evenly divisible by four ("version" has seven characters).  The "," is there to indicate that there are no "arguments" to this "method".  The 0A and 0D is the 'ol carriage return/line feed.  Thanks to your tip about the console logging, I'm able to get an "unable to parse OSC method address" whenever there's a problem, and I tested a bunch of options and it needed all of these parts to work.

So, next I tried to fire a cue. After some testing, I found that:

/go!00!00,!0A!0D

will fire the next cue in the current workspace.

Now I tried to fire a specific cue, and I got stuck again.  I'm currently trying to send:

/cue!00/9!00!00!00/start!00!00!00,!0A!0D

I'm sure I'm missing something obvious, but I also couldn't find in your OSC API any mention of what the cue number format is.  I'm assuming in my example command that it's ASCII, since there are so many potential cue number formats (even--god forbid--letter cues :-) )?   It looks from the API where it shows "/cue/{number}/start that the cue number would not be a separate argument, and instead is part of the method, but maybe it should be an argument instead?

OSC may be good for a lot of things, but it sure is awfully complicated for simple network-based remote control. :-)

Thanks!

John

www.controlgeek.net

--
http://www.controlgeek.net/blog

[Christopher Ashworth]

Hi John,

On Jul 3, 2013, at 5:36 PM, John Huntington <jch3ny...@gmail.com> wrote:

> OK, I've made a bit of progress, but now have a new question :-)

No problem.

> You were right--I forgot the null padding, and also left out the argument type tag indicator.
>
> So, to send the "Version" command (the simplest one, it seemed to me), you have to actually send (where the "!" indicates to Medialon Manager to send the associated hex value of non-alphanumeric ASCII characters):
> /version!00,!0A!0D
>
> The null (!00) is there to indicate the end of the "version" string, and must round out the string to a total byte count (not including the "/") evenly divisible by four ("version" has seven characters). The "," is there to indicate that there are no "arguments" to this "method". The 0A and 0D is the 'ol carriage return/line feed. Thanks to your tip about the console logging, I'm able to get an "unable to parse OSC method address" whenever there's a problem, and I tested a bunch of options and it needed all of these parts to work.
>
> So, next I tried to fire a cue. After some testing, I found that:
> /go!00!00,!0A!0D
> will fire the next cue in the current workspace.
>
> Now I tried to fire a specific cue, and I got stuck again. I'm currently trying to send:
> /cue!00/9!00!00!00/start!00!00!00,!0A!0D
>
> I'm sure I'm missing something obvious, but I also couldn't find in your OSC API any mention of what the cue number format is. I'm assuming in my example command that it's ASCII, since there are so many potential cue number formats (even--god forbid--letter cues :-) )? It looks from the API where it shows "/cue/{number}/start that the cue number would not be a separate argument, and instead is part of the method, but maybe it should be an argument instead?

The cue "number" is, as you guess, a string. In QLab the cue number can be any string, to support things like letter "numbers".

In this case the cue number is part of the address of the OSC method, as that's the OSC-ish way to address an object in the program. Thus, the whole address is a string, and the string includes a portion that is interpreted as a cue number in QLab.

> OSC may be good for a lot of things, but it sure is awfully complicated for simple network-based remote control. :-)

I wouldn't say that OSC is the pinnacle of network APIs, certainly. (The complete agnosticism about the transport layer in the 1.0 specification is especially weird.)

That said, I'm not sure it's totally fair to critique OSC based on trying to write it in raw bytes. :-)

I mean, we *could* program QLab in assembly, but that would be horrible. :-)

The fact that one machine can control another one by sending a "/go" OSC message is, in my view, pretty darn simple network-based remote control. :-)

-C

[John Huntington]

Thanks for the speedy reply!

On 7/3/2013 18:23, Christopher Ashworth wrote:
> The cue "number" is, as you guess, a string. In QLab the cue number
> can be any string, to support things like letter "numbers". In this
> case the cue number is part of the address of the OSC method, as
> that's the OSC-ish way to address an object in the program. Thus, the
> whole address is a string, and the string includes a portion that is
> interpreted as a cue number in QLab.

Cool, do you see any problems with my syntax of:
/cue!00/9!00!00!00/start!00!00!00,!0A!0D

It wasn't firing cue 9, although if I recall correctly, I was getting a
"/cue" acknowledgement in the QLab logging.

Also, how would I fire a cue on a particular list? I see this method:
/cue/{number}/listName

Would it be something like?
/cue/{number}/listName/start

>> OSC may be good for a lot of things, but it sure is awfully complicated for simple network-based remote control. :-)
> I wouldn't say that OSC is the pinnacle of network APIs, certainly. (The complete agnosticism about the transport layer in the 1.0 specification is especially weird.)
>
> That said, I'm not sure it's totally fair to critique OSC based on trying to write it in raw bytes. :-)

Oh believe me, I'm not a glutton for punishment--I've been after
Medialon for a while to include OSC. :-) They do have a pretty powerful
"Low Level Communicator" which allows assembly of strings from
variables, automated monitoring, some parsing, etc etc, which is what
I'm working in. Once I get the syntax right, I can write it all into
commands and then it's pretty easy to use. I can probably even automate
the byte padding.

> The fact that one machine can control another one by sending a "/go" OSC message is, in my view, pretty darn simple network-based remote control. :-)

I guess the key part of your phrase is that one "machine" can control
another :-) Of course, for a human to send "go" from any program that
doesn't have OSC support they'd have to type /go!00!00,!0A!0D :-)


I've long been a fan of simple, human-typeable, ASCII based control
messages, back to the days of the Pioneer Laser Disc player, which would
take simple commands like "pl" for play, or "st" for still (each just
followed by cr/lf). That simple protocol is very easy to test, use and
program, and was a big improvement, from my perspective, over things
like the then common Sony 9 Pin control scheme, a three byte binary
message with a check sum. And that kind of simple human typeable
control is still common today; here's an animatronic controller I just
got firing from Medialon last week (I'm doing a lot of haunted house
upgrades this summer):
http://controlgeek.net/blog/2013/6/28/controlling-the-weigl-procommander-2-from-medialon-manager

And a lot of systems these days basically just accept their internal
scripting language controls over an IP port (these two systems--SFX and
GrandMa2--have been running lighting and sound for our haunted house
this way for the last few years):
http://controlgeek.net/blog/2008/10/24/in-praise-of-custom-ip-based-entertainment-control-part-2.html
http://controlgeek.net/blog/2010/10/14/controlling-a-grandma2-via-tcp-and-medialon-manager.html

All that said, going through this exercise has shown me how OSC is a
great choice for something like your iPad remote, where you're
managing/recalling cue lists, etc..

And and let me chime in with the chorus saying how great the new version
is, and how much I admire the way you guys operate, thanks!

I'm heading out shortly to the eastern land across the bay from you
(visiting family on the eastern shore), I'll be back at the Qlab machine
Monday. Have a great holiday!

John

--
--
www.controlgeek.net

[Dave Tosti-Lane]

Hi John - this is an ignorance based suggestion really - so take it for
what it's worth!
But, I wonder if "09" might work instead of "9"? It seems to me I've had
something like that happen when trying to get an ION and Qlab to negotiate
- which is completely unrelated to OSC of course, but it's the one thing
that popped into my mind when I looked at your command syntax.

DTL

On Thursday7/4,Thursday7/4:611 AM 6:11 AM, "John Huntington"

[Dave "luckydave" Memory]

On Thursday, July 4, 2013 at 11:56 AM, Dave Tosti-Lane wrote:

Hi John - this is an ignorance based suggestion really - so take it for

what it's worth!

But, I wonder if "09" might work instead of "9"? It seems to me I've had

something like that happen when trying to get an ION and Qlab to negotiate

- which is completely unrelated to OSC of course, but it's the one thing

that popped into my mind when I looked at your command syntax.

A cue number is a string that must be unique, so "09" and "9" are different. When working with MSC, that matters, because QLab (and, I'd imagine, the Ion) can have a cue numbered 9, and another cue numbered 09, so it's essential to be specific. In OSC, that wouldn't be the change you're looking for, because you need the specific cue number string to match.

-- 

luck...@figure53.com

[Dave "luckydave" Memory]

On Thursday, July 4, 2013 at 9:11 AM, John Huntington wrote:

Also, how would I fire a cue on a particular list? I see this method:

/cue/{number}/listName

Would it be something like?

/cue/{number}/listName/start

/cue/{number}/listName would return the name of the cue. Since every cue number must be unique, it doesn't matter which list it's in if you want to trigger it by number, so this same method would work:

/cue/{number}/start

And to start a cue list, which would be the same as pressing GO on that list, do the same, but use the cue list's number there.

-- 

luck...@figure53.com

[Christopher Ashworth]

Hi John,

On Jul 4, 2013, at 9:11 AM, John Huntington <jch3ny...@gmail.com> wrote:

Thanks for the speedy reply!

On 7/3/2013 18:23, Christopher Ashworth wrote:

The cue "number" is, as you guess, a string. In QLab the cue number can be any string, to support things like letter "numbers". In this case the cue number is part of the address of the OSC method, as that's the OSC-ish way to address an object in the program. Thus, the whole address is a string, and the string includes a portion that is interpreted as a cue number in QLab.

Cool, do you see any problems with my syntax of:
/cue!00/9!00!00!00/start!00!00!00,!0A!0D

It wasn't firing cue 9, although if I recall correctly, I was getting a "/cue" acknowledgement in the QLab logging.

I'll need to dig in to what they byte representation that should be; I'll be able to do that more easily later (on a plane at the moment).

Also, how would I fire a cue on a particular list?  I see this method:
/cue/{number}/listName

The listName property is a read-only property that returns the name of the cue as it would appear in a cue list.  

This is a bit confusing, so as a quick explanation (which I should add to the API docs):

name - the name a human assigns

defaultName - the name the cue generates by default, if it knows how. might be empty

listName - the name you would see in the cue list, i.e. the name if it exists, or then the defaultName if that exists

displayName - the name you would see in the "standby" area next to the GO button; the name if it exists, then the default name if that exists, then a final backup "(Untitled Cue name)" to ensure something is visible

As I believe luckydave mentioned, but I'll add it here to be sure:

All cue numbers in a QLab workspace are unique, so if the cue has a number it can be addressed by that number wherever it might be.  The cue list it is in doesn't matter.

OSC may be good for a lot of things, but it sure is awfully complicated for simple network-based remote control. :-)

I wouldn't say that OSC is the pinnacle of network APIs, certainly.  (The complete agnosticism about the transport layer in the 1.0 specification is especially weird.)

That said, I'm not sure it's totally fair to critique OSC based on trying to write it in raw bytes. :-)

Oh believe me, I'm not a glutton for punishment--I've been after Medialon for a while to include OSC. :-)  They do have a pretty powerful "Low Level Communicator" which allows assembly of strings from variables, automated monitoring, some parsing, etc etc, which is what I'm working in.  Once I get the syntax right, I can write it all into commands and then it's pretty easy to use.  I can probably even automate the byte padding.

The fact that one machine can control another one by sending a "/go" OSC message is, in my view, pretty darn simple network-based remote control. :-)

I guess the key part of your phrase is that one "machine" can control another :-)  Of course, for a human to send "go" from any program that doesn't have OSC support they'd have to type /go!00!00,!0A!0D  :-)


I've long been a fan of simple, human-typeable, ASCII based control messages, back to the days of the Pioneer Laser Disc player, which would take simple commands like "pl" for play, or "st" for still (each just followed by cr/lf).  That simple protocol is very easy to test, use and program, and was a big improvement, from my perspective, over things like the then common Sony 9 Pin control scheme, a three byte binary message with a check sum.   And that kind of simple human typeable control is still common today; here's an animatronic controller I just got firing from Medialon last week (I'm doing a lot of haunted house upgrades this summer):
http://controlgeek.net/blog/2013/6/28/controlling-the-weigl-procommander-2-from-medialon-manager

And a lot of systems these days basically just accept their internal scripting language controls over an IP port (these two systems--SFX and GrandMa2--have been running lighting and sound for our haunted house this way for the last few years):
http://controlgeek.net/blog/2008/10/24/in-praise-of-custom-ip-based-entertainment-control-part-2.html
http://controlgeek.net/blog/2010/10/14/controlling-a-grandma2-via-tcp-and-medialon-manager.html

All that said, going through this exercise has shown me how OSC is a great choice for something like your iPad remote, where you're managing/recalling cue lists, etc..

I find this really interesting from both a design and a philosophical standpoint.   I know that I'm speaking to the master here, so I'd like to push on this a little further as I suspect I'll learn something.

What I particularly find interesting is as follows:

I've long been a fan of simple, human-typeable, ASCII based control messages

Built in to this sentence is an assumption of what it means to be human-typeable.  If you sit down to enter strings of ASCII byte values you're typing them in to something.  It assumes a default way of humans talking to computers where we know how to make them send raw ASCII bytes, with some kind of easy framing mechanism to distinguish separate messages.

Is that a safe assumption?  Ask an average user (heck, ask ME) to sit down at a random Mac and start sending arrays of ASCII bytes out over the network and I'm not sure they'd know how to do that.

Thus, I propose that this might be just as arbitrary as typing in OSC messages; both are assuming a program between the human and the wire that accepts the human input and sends out a message over the wire.

The determining factor, it seems to me, then becomes: "for the environment in which we're building, what is (or will soon be) the default way a human enters simply human-typeable messages in to a computer, to send them over the network to another computer". 

The place my ignorance probably comes in to play is in knowing the list of devices in the show control environment that talk raw arrays of human-writeable ASCII. I bet there are a lot out there I don't know about, which would indeed be an argument for adding this kind of network API to QLab.

That said, the ways we saw people actively trying to control QLab 2 over a network were almost all based on either 1) MIDI over ethernet (between two QLab machines) or 2) OSC (from 3rd party software controlling QLab).

For (1), OSC is clearly a superior replacement. It's got all the advantages of MSC, plus can be easily (and semantically) extended. And unlike MIDI, it lives natively on an IP network.

For (2), OSC appears to be an increasingly accepted standard for this purpose. TouchOSC, for example, has become a very popular way to have a human-typeable control message sent over the network to the computer, and people found ways to use that with QLab 2, even thought QLab 2 didn't know how to talk OSC.  

Finally, we knew that we could also release our own OSC library as open source ( https://github.com/Figure53/F53OSC ), and an open source OSC command-line client ( https://github.com/Figure53/qcmd ) so that it would be much easier to build custom software or interact with QLab by just firing up a terminal.

So, I guess that leaves me with the question: if the above analysis is fair, the key point is understanding what other stuff out there are people commonly using that knows how to talk raw ASCII bytes but doesn't know how to talk OSC?

For one reason or another, they haven't appeared in the world of QLab before, so I'm not aware of them.  But I'm very interested to learn!

Cheers from 30,000 feet,

Chris

[Pierre-Luc Brunet]

This is a great discussion and I must jump in!

I, myself, do a fait bit of show control for different types of environments.

Nowadays almost everything is connectable to a network. This is todays most useful way of interconnecting devices (hardware and software). And this trend will probably last for quite a while!
So having the ability to talk device to device over network is very useful and pretty straight forward.

The problem is that every software and hardware have their own communication protocols. And while a decent bit of them share some of those (midi, msc, timecode, osc) not all of them do. Some support one and not the other or are specific about it. But almost all devices have a scripting language or API (which is of course different every time) but can often be received over network.

This is where the ability to send and receive commands in ASCII (plan text) over network comes in to play and I think is a very big player in the show control environment. This is because the multiples softwares and hardwares that we might use together (and there's a lot of them!) will never all speak the same language (or protocol).
The Network is the common ground for all the bits and piece so let's use it!

I think having OSC in Qlab is great but once again, not everything talks OSC.
To me, flexibility is a key factor show control and I consider Qlab as a show control software. Qlab has always had the ability to be a bridge between various pieces and I think expanding those possibilities would very helpful.

With this you could talk to many More softwares (existing ones and new custom ones), you could also talk to a lot of hardware. Things like projectors, TVs, switchers, matrixes,maybe even radio mics, processors(Audio and video), hardware controllers, consoles and the list will only grow.

And on the Qlab side of things, for receiving purposes, could you use your existing OSC commands but being able to receive it in plain text like what John is trying to do? That way you wouldn't have to write a whole new API.

In any case I think networking is the way of the future and Qlab would greatly benefit from such features.Actually I thought that it would have been part of v3 from the start. But let's not get too carried away. :P

My thoughts.
Pierre-Luc
(Just out of a plane :)

[John Huntington]

On 7/5/2013 11:33, Christopher Ashworth wrote:

Cool, do you see any problems with my syntax of:
/cue!00/9!00!00!00/start!00!00!00,!0A!0D

It wasn't firing cue 9, although if I recall correctly, I was getting a "/cue" acknowledgement in the QLab logging.

I'll need to dig in to what they byte representation that should be; I'll be able to do that more easily later (on a plane at the moment).

Cool, no rush.  If I could get this working this week before I go on holiday that would be great.

As I believe luckydave mentioned, but I'll add it here to be sure:

All cue numbers in a QLab workspace are unique, so if the cue has a number it can be addressed by that number wherever it might be.  The cue list it is in doesn't matter.

Hmm, interesting.  I'm a QLab noob, and I can't currently get to the only machine we have that can run V3, so let me ask a stupid question.  In QLab, can I have a Q1 on list 1, and another Q1 on list 2?  In our haunted hotel, for example, we have a list for the "Skullery" and another for "Tipsy's Parlour".  Each has a Q1, since they are separate areas but run from the same machine completely asynchronously.  I need a way to fire either one at any time.  MSC, of course, handles this by just having ASCII cue and cue list fields.  For the haunted house, the lists are named things like SKY for skullery, so we could fire Q1 on list SKY and Q1 on TPY at the same time.  (Of course, after advocating for MSC for many years in the 90's I'm now advocating more modern alternatives, so I don't want to use MSC here :-)

I find this really interesting from both a design and a philosophical standpoint.   I know that I'm speaking to the master here,

Thanks for the kind words, but I don't consider myself a master at any of this stuff!  I just hack away at it until I get it to work, and I've been doing that (and writing about it) for a long time.   I can't even imagine writing code for sample-accurate sync--you are operating in another world :-)

so I'd like to push on this a little further as I suspect I'll learn something.

What I particularly find interesting is as follows:

I've long been a fan of simple, human-typeable, ASCII based control messages

Built in to this sentence is an assumption of what it means to be human-typeable.  If you sit down to enter strings of ASCII byte values you're typing them in to something.  It assumes a default way of humans talking to computers where we know how to make them send raw ASCII bytes, with some kind of easy framing mechanism to distinguish separate messages.

Is that a safe assumption?  Ask an average user (heck, ask ME) to sit down at a random Mac and start sending arrays of ASCII bytes out over the network and I'm not sure they'd know how to do that.

Your comment made me think about this a bit too.  I actually teach undergrad students in my (required, basic) Entertainment Controls Class to do exactly this--type ASCII messages back and forth to each other, first using open-source Teraterm over serial, and then Essential Net Tools over a little network (although I'd love to find an open PC replacement for that ENT program--we use old/wimpy PC's for this since they are cheaper).  The students usually start out a bit confused, but by the end of the lab they are usually sending jokes to everyone over UDP broadcast.  I find it to be a really good way to explain what goes over the cable (I know I learn best by seeing this stuff in action), and to make it all a bit less abstract (always important for show biz students), since they can get the idea that "characters" on the wire are really just voltages on and off, coded to the binary values of the ASCII.

They then move onto  controlling a piece of gear using simple ASCII commands (currently, an old Pioneer DVD player but I'm planning on upgrading that soon).  Of course, they would never run a show this way, but it's important for them to understand how this kind of simple control works, and if you can use some sort of terminal program to debug out a working string that does something, then you can just cut and paste that string into whatever program you want to do the control, et voila! :-)   In show control class, some of the more advanced students can use things like Medialon Manager to take that string and then embed a variable name where the working Q number was, and then they can do pretty sophisticated stuff with that simple setup.

I guess there's some invisible line of complexity that gets crossed with OSC for me with the abstraction in the objects (I only took C back in the day and never C++ so I'm always on thin ice any time I use the word "object" around real developers), and also the byte padding.  Stuff like that means that you really need to have a pretty significant coding background to even comprehend the basic interchange process, and two strings that do the exact same thing "Go Q123" and "Go Q1234" actually would not be just one byte different ("123 0x00" vs "1234 0x00 0x00 0x00 0x00") That's a tough thing to explain to most of our students, who have only one required programming class (typically in Processing).  Even for me, I had to go to Wikipedia and read up on the C string termination stuff to even get started with OSC.

The place my ignorance probably comes in to play is in knowing the list of devices in the show control environment that talk raw arrays of human-writeable ASCII. I bet there are a lot out there I don't know about, which would indeed be an argument for adding this kind of network API to QLab.

There's probably literally thousands of controlled devices that work this way.  Here's a couple lists from:
http://www.medialon.com/ca/control_plugins_store.aspx
Some of these are pretty sophisticated, Here's a list of "drivers" written in the simpler "Low Level Communicator" device:
http://www.medialon.com/57/ftp/downloads/download_v6/ktor_drivers/

So in the long run it would be cool if QLab could offer some sort of outgoing ASCII cue (SFX does this over serial or telnet), but more importantly to me is a simple way to respond to simple incoming commands.  Maybe I'm the only one who wants this?  I was talking to the GrandMA lighting console people and AFAIK I'm the only one who has fired console commands into their boards over the network for a show purpose (we're probably the only ones using a GrandMA to run a haunted house too :-)  In most cases people are just using the console or running time code.

That said, the ways we saw people actively trying to control QLab 2 over a network were almost all based on either 1) MIDI over ethernet (between two QLab machines) or 2) OSC (from 3rd party software controlling QLab).

For (1), OSC is clearly a superior replacement. It's got all the advantages of MSC, plus can be easily (and semantically) extended. And unlike MIDI, it lives natively on an IP network.

Definitely! 

For (2), OSC appears to be an increasingly accepted standard for this purpose. TouchOSC, for example, has become a very popular way to have a human-typeable control message sent over the network to the computer, and people found ways to use that with QLab 2, even thought QLab 2 didn't know how to talk OSC. 

I probably wouldn't even be looking at this if Medialon wrote an mxm for OSC, or for QLab :-) 

So, I guess that leaves me with the question: if the above analysis is fair, the key point is understanding what other stuff out there are people commonly using that knows how to talk raw ASCII bytes but doesn't know how to talk OSC?

From the control side, off the top of my head, in our market, Medialon can definitely do this, and is probably the most widely used system on larger shows.  Alcorn-McBride definitely does this too, and they are a big player in the theme park market.  Venue Magic/Weigl (I just posted a link about this earlier) can do it, and there are dozens of others.  In the related "Media Control" (boardrooms, big residential installs, etc) market this kind of communication is king, and both AMX and Crestron do this pretty extensively.

QLab most definitely meets my definition of a show controller (ability to link two separate entertainment disciplines), but I don't think you need to compete with Medialon/Alcorn, etc, since they have a lot of conditional operation capability and are really in a different market space.  But thinking this through, though, if you were going to add something I think would second Mr. Brunet, when he suggested, "And on the Qlab side of things, for receiving purposes, could you use your existing OSC commands but being able to receive it in plain text". 

Is it possible to operate QLab by typing commands on the keyboard (I ran out of time to look at this last week, and Googling didn't find it)?  If so, if you could just accept and acknowledge those commands on a TCP/UPD port of your choosing then people could use that for simple control, and then use OSC when they need more sophisticated data exchange.

Thanks, it's been a fascinating conversation!

John (who is still full of crab after a visit to MD :-) )

-- 
--
www.controlgeek.net

[Dave "luckydave" Memory]

On Sunday, July 7, 2013 at 2:12 PM, John Huntington wrote:

Hmm, interesting.  I'm a QLab noob, and I can't currently get to the only machine we have that can run V3, so let me ask a stupid question.  In QLab, can I have a Q1 on list 1, and another Q1 on list 2?  In our haunted hotel, for example, we have a list for the "Skullery" and another for "Tipsy's Parlour".  Each has a Q1, since they are separate areas but run from the same machine completely asynchronously.  I need a way to fire either one at any time.

In QLab, a "cue list" is a special type of group cue, which doesn't have a Mode, like a typical group cue does, and has timecode settings for triggering of cues within the cue list. It's not a separate abstraction like you'd find in a light board, where the cues inside it don't know about the cues in other cue lists. I think this deviates slightly from what MSC would have you expect, if I'm understanding the concepts correctly, and in this way, you could consider QLab to be "cue list agnostic" in a manner of speaking.

So, a cue list's number is just another cue number in the world of QLab. And any cues inside any cue lists are still subject to the unique numbering requirement, on the workspace level, not the cue list level. You can have cues numbered 1, 01, 1.0, 01.0, 1.0000, and they're all different according to QLab, and indeed, according to MSC. But you can't have two cues numbered 1.

For your case, it sounds like a cue list called "Skullery" could have numbers without a prepended 0, and another called "Tipsy's Parlour" could have prepended 0's, so any Skullery cue is numbered as 1, 2, 3, etc, and any Tipsy's cues would have 01, 02, 03 and on. Is that a workable solution? In that case, you don't need the cue list number, just the cue number, and you could almost count the cue list number as just the number or prepended 0's, conceptually.

-- 

luck...@figure53.com

[John Huntington]

On 7/7/2013 14:29, Dave "luckydave" Memory wrote:
> In QLab, a "cue list" is a special type of group cue, which doesn't
> have a Mode, like a typical group cue does, and has timecode settings
> for triggering of cues within the cue list. It's not a separate
> abstraction like you'd find in a light board, where the cues inside it
> don't know about the cues in other cue lists. I think this deviates
> slightly from what MSC would have you expect, if I'm understanding the
> concepts correctly, and in this way, you could consider QLab to be
> "cue list agnostic" in a manner of speaking.

Aha, interesting! I'll mess around more with this this week. On this
show, I'm not the sound designer, but I think the pre-pending might work.

In SFX (and Richmond Command Cue/Stage Manager/etc before that) a cue
list is a separate entity with its own clock, etc., and that's what they
were thinking of during the development of MSC.

It's interesting, with that cue list structure, you can even use a list
as a sort of "subroutine", where one cue in another list could send an
"Open Cue List 27" command, and the first command in List 27 would start
the clock of List 27, which would then automatically fire a bunch of
cues. The last cue in the list would be "Close Cue List 27". Is that
kind of stuff possible in QLab?

John

--
--
www.controlgeek.net

[Dave "luckydave" Memory]

On Sunday, July 7, 2013 at 3:05 PM, John Huntington wrote:

In SFX (and Richmond Command Cue/Stage Manager/etc before that) a cue

list is a separate entity with its own clock, etc., and that's what they

were thinking of during the development of MSC.

It's interesting, with that cue list structure, you can even use a list

as a sort of "subroutine", where one cue in another list could send an

"Open Cue List 27" command, and the first command in List 27 would start

the clock of List 27, which would then automatically fire a bunch of

cues. The last cue in the list would be "Close Cue List 27". Is that

kind of stuff possible in QLab?

Each cue list has its own timecode sync source, so that's similar. Cues within that cue list that are triggered from incoming timecode use that sync source. That way, you can use multiple timecode sources for multiple cue lists, which can be helpful in something like your haunted house setup (as I understand it).

Each cue sequence has its own "clock" as I understand what you're describing. "/cue/1/start" would start cue 1, and subsequently, its cue sequence, so any auto-continued or auto-followed cues, and their pre- and post-waits. Starting a cue list is like pressing GO on that cue list, so if your cue list is numbered 002, then "/cue/002/start" would work just like a GO on cue list 002. "cue/1/stop" or "/cue/002/stop" would be the analogue to your "close", like "start" would be like your "open".

-- 

luck...@figure53.com 

[John Huntington]

Cool, thanks!

John

[Christopher Ashworth]

(Briefly, again from a plane.)

On Jul 7, 2013, at 2:12 PM, John Huntington <jch3ny...@gmail.com> wrote:

I guess there's some invisible line of complexity that gets crossed with OSC for me with the abstraction in the objects (I only took C back in the day and never C++ so I'm always on thin ice any time I use the word "object" around real developers), and also the byte padding.  Stuff like that means that you really need to have a pretty significant coding background to even comprehend the basic interchange process, and two strings that do the exact same thing "Go Q123" and "Go Q1234" actually would not be just one byte different ("123 0x00" vs "1234 0x00 0x00 0x00 0x00") That's a tough thing to explain to most of our students, who have only one required programming class (typically in Processing).  Even for me, I had to go to Wikipedia and read up on the C string termination stuff to even get started with OSC.

To me the key to this is that you're still working at the raw level.  If you're dealing with OSC at the byte level (in a real show situation, rather than a learning situation) then something is wrong, since the computer should be doing all of that stuff for you.

Example:

If you enter a "raw" (I need to change the name of this, since it's not really raw) OSC command in QLab, you enter something like this:

/hello/to/some/other/program here are some arguments 1.23 

Then QLab translates that to the correct OSC message, handles byte padding, argument types, etc. 

At that level all you need to think about is what address and arguments you need to send to the other program.  That's the level that I think OSC should be considered at, when it comes to how it can (and should) be used.  

The place my ignorance probably comes in to play is in knowing the list of devices in the show control environment that talk raw arrays of human-writeable ASCII. I bet there are a lot out there I don't know about, which would indeed be an argument for adding this kind of network API to QLab.

There's probably literally thousands of controlled devices that work this way.  Here's a couple lists from:
http://www.medialon.com/ca/control_plugins_store.aspx
Some of these are pretty sophisticated, Here's a list of "drivers" written in the simpler "Low Level Communicator" device:
http://www.medialon.com/57/ftp/downloads/download_v6/ktor_drivers/

So in the long run it would be cool if QLab could offer some sort of outgoing ASCII cue (SFX does this over serial or telnet),

This I think is the most persuasive argument for sending a raw byte stream; controlling devices like those listed in the links. It would be network based, as the concept of a serial port is more or less dead in the world of Macs. You can get a USB -> serial convertor but I'm reluctant to build something into QLab that inherently requires non-standard hardware to use. (It would be an interesting candidate for a 3rd-party utility though. Someone out there could use our OSC library to build a way to translate between OSC and serial commands.)

but more importantly to me is a simple way to respond to simple incoming commands.  Maybe I'm the only one who wants this? 

I will admit I can't recall it coming up much, but we may hear more about it as QLab seeps into new venues and markets. 

 But thinking this through, though, if you were going to add something I think would second Mr. Brunet, when he suggested, "And on the Qlab side of things, for receiving purposes, could you use your existing OSC commands but being able to receive it in plain text". 

This is interesting, since we already have code (as noted above) that translates a human-written string into an OSC command.  I could certainly imagine opening up another port to accept such commands, translating them to OSC, and then passing them straight into the existing OSC pipeline.

Very interesting.

Is it possible to operate QLab by typing commands on the keyboard (I ran out of time to look at this last week, and Googling didn't find it)?  If so, if you could just accept and acknowledge those commands on a TCP/UPD port of your choosing then people could use that for simple control, and then use OSC when they need more sophisticated data exchange.

We do have a command-line client that provides some nice keyboard control for using the OSC api. ( https://github.com/Figure53/qcmd )  However I think it would end up being a cleaner fit to try the above-mentioned translation of plain-text commands to OSC commands.

Thanks, it's been a fascinating conversation!

Likewise!

-C

[Jeremy Lee]

This whole discussion makes me want to stick with MIDI!!!

Jeremy Lee

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

--

[Christopher Ashworth]

On Jul 7, 2013, at 8:42 PM, Jeremy Lee <jerem...@jjlee.com> wrote:

> This whole discussion makes me want to stick with MIDI!!!

Why? We're talking nuts and bolts. You don't need to worry about this stuff if you're just using it.

-C

[Jeremy Lee]

Well, I haven't been able to really follow the entire conversation in depth since we're in the middle of packing. But if the guy who literally wrote the book on show control has this much trouble getting 2 devices to talk over OSC, them it's likely way over my head. And I can be a pretty geeky guy...

John may have stopped programming at C. I stopped somewhere around Pascal, dabbling a little in Perl and AppleScript. Parsing ASCII into Hex and byte padding are not things I want to think about.

Is this whole thing because Medialon doesn't speak OSC, and he's trying to force the protocol into it?

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

[Christopher Ashworth]

On Jul 7, 2013, at 8:57 PM, Jeremy Lee <jerem...@jjlee.com> wrote:
>
> Is this whole thing because Medialon doesn't speak OSC, and he's trying to force the protocol into it?

More or less, yes.

It's fair to say that if his tool doesn't speak OSC he's forced into the position of trying to do it this way.

That said, the way you (and many people on this list) have traditionally needed to control QLab, this is not the experience you'd have. For example, if you're having one QLab machine send messages to another QLab machine, precisely zero of this conversation is relevant. Just make your OSC cues, send the messages, and you're done.

-C

[John Huntington]

On 7/7/2013 20:14, Christopher Ashworth wrote:

To me the key to this is that you're still working at the raw level.  If you're dealing with OSC at the byte level (in a real show situation, rather than a learning situation) then something is wrong, since the computer should be doing all of that stuff for you.

Now if I could just convince Medialon of this :-)  They probably will do it, eventually.  But then one of their developers is going to do all this work I'm doing now, so it's worth figuring out anyway :-)

 But thinking this through, though, if you were going to add something I think would second Mr. Brunet, when he suggested, "And on the Qlab side of things, for receiving purposes, could you use your existing OSC commands but being able to receive it in plain text". 

This is interesting, since we already have code (as noted above) that translates a human-written string into an OSC command.  I could certainly imagine opening up another port to accept such commands, translating them to OSC, and then passing them straight into the existing OSC pipeline.

That would be great!  It also might open up new avenues for other kinds of simple network control.

I'd still like to get this basic OSC triggering going though, so if you have a chance to check that cue number syntax I'd appreciate it.

Thanks!

John

-- 
--
www.controlgeek.net

[John Huntington]

On 7/7/2013 21:20, Christopher Ashworth wrote:
> On Jul 7, 2013, at 8:57 PM, Jeremy Lee <jerem...@jjlee.com> wrote:
>> Is this whole thing because Medialon doesn't speak OSC, and he's trying to force the protocol into it?
> More or less, yes.
>
> It's fair to say that if his tool doesn't speak OSC he's forced into the position of trying to do it this way.

And I've been in this situation before--back in the day, many
sequencers, etc, did not support MIDI Show Control, so we had to type in
raw hex strings back then (although MSC is a LOT simpler than OSC, and,
therefore, less powerful).

The more things change, the more they...
John

--
--
www.controlgeek.net

[Charlie Richmond]

On Sun, Jul 7, 2013 at 8:31 PM, John Huntington <jch3ny...@gmail.com> wrote:

(although MSC is a LOT simpler than OSC, and, therefore, less powerful).

You know I will disagree with this.  MSC is deceptively simple but ultimately powerful.  The problem was simply that manufacturers did not take advantage of all of MSC's possibilities and therefore missed many opportunities for finesse and detail.

But that's off topic for this list ;-)

C-)

[John Huntington]

Geez, I meant "simple" as a compliment! :-)  In my design principles, "Simpler is always better" is #2.

OSC has made my head hurt since the first time I read the spec years ago.  Honestly I didn't even see the point of it at all until I saw the QLab remote software, where things like cue names, etc, are drawn back into the app.

MSC (and MIDI for that matter) was great for its time, but shoehorning it into a modern IP transport just doesn't make sense to me, nor does being stuck with current loop DIN connectors... 

John

--
--
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.
 
 

-- 
--
www.controlgeek.net

[Stew Ives]

John,

   I don't think you are the only one here. I would +1 an accepting of raw ascii strings solely for easing communication with ETC consoles that currently only can do raw ascii over UDP. The current workaround of using node.js to translate to OSC is seen here http://www.etcconnect.com/Community/forums/p/9316/45490.aspx#45490 but I've not tried it. 

-Stew

[John Huntington]

Interesting, thanks!

John

On 7/8/2013 11:05, Stew Ives wrote:
> John,
> I don't think you are the only one here. I would +1 an accepting of
> raw ascii strings solely for easing communication with ETC consoles
> that currently only can do raw ascii over UDP. The current workaround
> of using node.js to translate to OSC is seen
> here http://www.etcconnect.com/Community/forums/p/9316/45490.aspx#45490 but
> I've not tried it.
>
> -Stew
>
>

--
--
www.controlgeek.net

[Jeremy Lee]

So, in this scenario, using OSC in QLab would be very similar to using MSC except that it would be over the network instead of MIDI cables? Does this extend to some sort of embedded OSC hardware GO box? Plug it into a network switch and it fires all redundant machines at once? And I wouldn't have to use MIDI thrus and such?

That could be a very useful and simple scenario. But then would I need to have some sort of redundant network switch in case the SWITCH failed?? I've never had to do that before- if a switch or router went down, it was a major annoyance, but not a show-stopper.

Ah, technology...

> --
> --
> 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.
>
>

--
Jeremy Lee
Sound Designer, NYC - USA 829
http://www.jjlee.com

[Andy Leviss]

On Mon, Jul 8, 2013 at 1:11 PM, Jeremy Lee <jer...@jjlee.com> wrote:

Does this extend to some sort of embedded OSC hardware GO box?  Plug it into a network switch and it fires all redundant machines at once? And I wouldn't have to use MIDI thrus and such?

<shameless plug>

Yes, and with many more useful features than that, like PoE ability for making powering it super easy, and some other goodies I won't spill just yet. Duck's Echo has one line of OSC products in final stages of pre-production, and another "premium sportster" line later in the year, some of which we previewed to folks at USITT this winter. I will be reaching out for beta testers for the first line as soon as I settle back down from the last two weeks of personal life hecticness :-)

(Had planned to have beta units in testers' hands already, but ran into a small issue with one supplier's part being converted from mm to inch on their drawings just imprecisely enough to cause a problem. D'oh.)

</shameless plug>

That could be a very useful and simple scenario.  But then would I need to have some sort of redundant network switch in case the SWITCH failed??  I've never had to do that before- if a switch or router went down, it was a major annoyance, but not a show-stopper.

Would you? Do you currently have a redundant MIDI Thru? Or MIDI I/O? There will always be some single point of failure, the best you can do is minimize that point of failure.  

My few cents,

Andy

[Christopher Ashworth]

On Jul 8, 2013, at 1:11 PM, Jeremy Lee <jer...@jjlee.com> wrote:

> So, in this scenario, using OSC in QLab would be very similar to using MSC except that it would be over the network instead of MIDI cables?

Correct.

> Does this extend to some sort of embedded OSC hardware GO box?

Yes.

[Christopher Ashworth]

Hi John,

On Jul 4, 2013, at 9:11 AM, John Huntington <jch3ny...@gmail.com> wrote:
>

> Cool, do you see any problems with my syntax of:
> /cue!00/9!00!00!00/start!00!00!00,!0A!0D
>
> It wasn't firing cue 9, although if I recall correctly, I was getting a "/cue" acknowledgement in the QLab logging.

Ah, should have spotted the problem right away, but I wasn't thinking straight. This sequence of bytes treats each component of the address as a separate string, whereas an OSC message actually has the entire address as one OSC string.

On a UDP port, the outgoing bytes for the /cue/9/start message should be:

/cue/9/start!00!00!00!00,!00!00!00

(The address and the type tag are two separate OSC strings.)

Chris

[John Huntington]

Aha, that did it, thanks!

So, just to try and wrap this up, I wrote a little Medialon Manager program to fire generic cues out.  Unfortunately, I couldn't find any way to have Medialon automatically handle the byte padding (I could write it in their compiled environment that couples with their API but I'd rather they do that :-)  So for my simple (not ready for prime time!) test thing I made four buttons that run four "user commands", one with string padding appropriate for for a 1-character cue, another appropriate for a 2-character cue, etc. Here's a screen capture (my previous test buttons--Version and Workspace Go--are there too), and the box on top shows the response from QLab, the last response I got in this case was from pressing the version button which is my little test "ping":

I enter the cue number in the little white box, and then press the appropriate button depending on the length of the cue number string, and that should handle the padding.  Here's the syntax of the commands fired by those four buttons (pasted from Manager, showing their user-enterable command variable; ! in this context is like 0x in C to indicate the hex value for non printable ASCII octets):

/cue/[Q-1 Char,string,literal,0]/start!00!00!00!00,!00!00!00!0A!0D

/cue/[Q-2 Char,string,literal,0]/start!00!00!00,!00!00!00!0A!0D

/cue/[Q-3 Char,string,literal,0]/start!00!00,!00!00!00!0A!0D

/cue/[Q-4 Char,string,literal,0]/start!00,!00!00!00!0A!0D

The amount of padding goes down, of course, as the length of the cue goes up.  I tried a one character cue, and that worked fine.  Two character would not work, though, and QLab kept logging it as Q0.  Three character (Q 123) worked, and four character worked (Q 12.3).

Then here's where it got interesting.  I tried a three character cue firing with the one-character command padding, and it worked.  I tried a two character cue, and it worked.  I named a cue "cat" and that worked fine with the byte padding for one character.  My little test workspace has cues 1, 2, 6, 7 9, 10, 11, 123, 12.3, 1.3, and "cat" and they all worked with the same byte padding appropriate for a one character cue number.  

So maybe the magical 0x00 0x00 0x00 0x00 byte padding before the argument comma will cover any input?

If so, this is actually good for me, since I wouldn't need to do the variable byte padding and can just write one "user command" to fire any cue, but maybe I'm missing something?

Thanks!

John

www.controlgeek.net

--
--
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.

--
http://www.controlgeek.net/blog

[Eric Cantrell]

Hi John,

You could automate appending the null bytes by using the Length() function in an expression and then sending the resultant string as a command to the LLC device.

For instance, the task would look like this:

Manager (OSC_String_to_Send = "/cue/" + QNumberString + "/start" + ("!00" * (4-Length(QNumberString))) + ",!00!00!00!0A!0D")

LLC Send Message (OSC_String_to_Send)

What this does is takes the variable QNumberString, counts the number of characters (with the Length() function), subtracts this number from the constant 4, then multiplies the result times the string "!00", which will give you the null byte padding (it will repeat the string the number of times it is multiplied).  Finally, it concatenates the null padding and QNumberString into the final resultant OSC_String_to_Send string variable.  Then, you just send that string to the LLC.

I hope this helps.

Regards,

Eric J. Cantrell

Medialon

[Jeremy Lee]

On Jul 8, 2013, at 1:24 PM, Andy Leviss <an...@ducksecho.com> wrote:

On Mon, Jul 8, 2013 at 1:11 PM, Jeremy Lee <jer...@jjlee.com> wrote:

Does this extend to some sort of embedded OSC hardware GO box?  Plug it into a network switch and it fires all redundant machines at once? And I wouldn't have to use MIDI thrus and such?

<shameless plug>

Yes, and with many more useful features than that, like PoE ability for making powering it super easy, and some other goodies I won't spill just yet. Duck's Echo has one line of OSC products in final stages of pre-production, and another "premium sportster" line later in the year, some of which we previewed to folks at USITT this winter. I will be reaching out for beta testers for the first line as soon as I settle back down from the last two weeks of personal life hecticness :-)

(Had planned to have beta units in testers' hands already, but ran into a small issue with one supplier's part being converted from mm to inch on their drawings just imprecisely enough to cause a problem. D'oh.)

</shameless plug>

The only shameful plugs are on Donald Trump's head.  Looking forward to seeing them!

That could be a very useful and simple scenario.  But then would I need to have some sort of redundant network switch in case the SWITCH failed??  I've never had to do that before- if a switch or router went down, it was a major annoyance, but not a show-stopper.

Would you? Do you currently have a redundant MIDI Thru? Or MIDI I/O? There will always be some single point of failure, the best you can do is minimize that point of failure.  

I don't know.  But I've (touch wood) never had a simple MIDI thru box or similar go out on me, but have had routers/ switches die on me from time to time.  Or forget their settings or similar.  Not often, but it happens.  It's just a new piece of semi-complex equipment taking the place of something that's mostly simple, and it gives me pause.

[Eric Cantrell]

My bad, I was off by one on my byte count.  Use 5 instead of 4.

Should be:

Manager (OSC_String_to_Send = "/cue/" + QNumberString + "/start" + ("!00" * (5-Length(QNumberString))) + ",!00!00!00!0A!0D")

Eric

[John Huntington]

Aha, very cool, I didn't know you could multiply strings! I thought I
would have to do this through some crazy if/then statements.

Learn something every day!

John

On 7/9/2013 10:43, Eric Cantrell wrote:
> My bad, I was off by one on my byte count. Use 5 instead of 4.
>
> Should be:
>
> Manager (OSC_String_to_Send = "/cue/" + QNumberString + "/start" +
> ("!00" * (5-Length(QNumberString))) + ",!00!00!00!0A!0D")
>
> Eric
>

--
--
www.controlgeek.net

[Andy Leviss]

On Tue, Jul 9, 2013 at 10:41 AM, Jeremy Lee <jer...@jjlee.com> wrote:

I don't know.  But I've (touch wood) never had a simple MIDI thru box or similar go out on me, but have had routers/ switches die on me from time to time.  Or forget their settings or similar.  Not often, but it happens.  It's just a new piece of semi-complex equipment taking the place of something that's mostly simple, and it gives me pause.

On the other hand, I've seen MIDI Solutions boxes corrupt data, other MIDI devices have a resistor or diode fail and cause all sorts of wacky data, with the same or higher frequency as the (very rare) failure of a *good quality* Ethernet switch. If you're only using OSC, you just need a robust SOHO level unmanaged switch. Very little to fail, no settings. You only need to go up to a managed switch if you're using Dante or AVB, in which case you should definitely be using a quality, reliable SOHO switch, and not just whatever you can buy from Staples. 

The entire world runs on ethernet hardware, configured properly for your use, and not buying home-grade gear, it's reliable enough to do a lot more than what our industry requires of it. And it's way more standardized, as opposed to MIDI, where so many manufacturers play fast-and-loose with the spec, taking wayyyyyy too much liberty on the "functionally equivalent" concept. 

(Just one example, look at the whole parasitic powering thing that MIDI Solutions uses. Pretty much everybody's wrong in that situation. MIDI Solutions devices are using a semantical loophole to justify the fact that, in order to power off the previous device's output, they are in 100% violation of the MIDI spec. In turn, however, devices that "don't work" with MIDI Solutions gear don't because they, too, aren't following the spec properly, and either aren't connecting output ground, or aren't supplying very much power at all for the current loop, and nowhere near the 5V the spec actually asks for.)

Anyway, way tangential rant, so back to prepping rigs for upcoming tours, so I can go home from the day job and work on finalizing that OSC hardware when I get home. Mmm, two jobs ;-)

-Andy