Macro Editor

Hi there,

1. Key presses that don't go to the command line typically are not captured. More SK, arrows, and the like are all not captured. EDIT: After further digging -- Some commands are very context sensitive (what screen is open, where something is highlighted, etc...). Currently, we don't capture these because of the required context.

2. I'll need to check on this. EDIT: This command isn't supported yet, but it is planned to add support for it.

3. This is the difference between a command recognized by the console, and a keyboard entry that will get turned into a command when played back. Categorically, you'll want to have commands in the macro editor unless you're doing things like labelling. There isn't a way to convert it - it's best to start with the needed commands and work from there. Sometimes, I'll learn a macro with all the commands I need, then go into the macro editor to clean any extraneous items up afterwards.

UDP commands are the same as the serial commands, which can be found in the Eos Family Show Control User Guide that's posted on the product pages for the consoles. (Convenience link here: http://www.etcconnect.com/product.downloads.aspx?ID=22125)

Thanks!

Hans

Thanks for getting back to me Hans...I guess I was imagining that all commands would go through a central 'command processor' if you will, so the console should respond the same way to (for example) a '_Clear_Command' or 'Beam_Palette' (basically what you see as 'last command' when on the diagnostic screen), however it comes in, be that through the face panel, macro, UDP string etc etc.

With regards to the link you posted, I have already found that documentation, and through my own trial and error, I know that there are more commands supported than listed- (_Clear_Command, Sneak, Block to name a few).

Oddly, sending a

<U1> $ Beam_Palette #, or <U1> $ Color_Palette # etc seems to default to posting:

'Beam Palette 1' or Color Palette 1' etc to the command line. (If I put a number following the command, it will run that particular palette number).

Basically, it all seems very inconsistent with regards to commands that are/are not/are a little bit supported, with very little documentation! I suppose what I'm looking for is something similar to what Strand produced for Genius Pro (manual extract attached) with relation to their MIDI messages and key codes! (see about halfway down the attached document) By using these reference codes, you are able to send pretty much any command the desk could respond to via the serial port.

Thanks,

Ian

Thanks for getting back to me Hans...I guess I was imagining that all commands would go through a central 'command processor' if you will, so the console should respond the same way to (for example) a '_Clear_Command' or 'Beam_Palette' (basically what you see as 'last command' when on the diagnostic screen), however it comes in, be that through the face panel, macro, UDP string etc etc.

With regards to the link you posted, I have already found that documentation, and through my own trial and error, I know that there are more commands supported than listed- (_Clear_Command, Sneak, Block to name a few).

Oddly, sending a

<U1> $ Beam_Palette #, or <U1> $ Color_Palette # etc seems to default to posting:

'Beam Palette 1' or Color Palette 1' etc to the command line. (If I put a number following the command, it will run that particular palette number).

Basically, it all seems very inconsistent with regards to commands that are/are not/are a little bit supported, with very little documentation! I suppose what I'm looking for is something similar to what Strand produced for Genius Pro (manual extract attached) with relation to their MIDI messages and key codes! (see about halfway down the attached document) By using these reference codes, you are able to send pretty much any command the desk could respond to via the serial port.

Thanks,

Ian

irw said:

Thanks for getting back to me Hans...I guess I was imagining that all commands would go through a central 'command processor' if you will, so the console should respond the same way to (for example) a '_Clear_Command' or 'Beam_Palette' (basically what you see as 'last command' when on the diagnostic screen), however it comes in, be that through the face panel, macro, UDP string etc etc.

Commands are interpreted as the local user of the console and are processed by the same logic as a user pressed button.

irw said:

With regards to the link you posted, I have already found that documentation, and through my own trial and error, I know that there are more commands supported than listed- (_Clear_Command, Sneak, Block to name a few).

Every command is supported! If you can press the button or add it to a macro, then you can send it via UDP. It would be a very big manual if it listed every command.

irw said:

Oddly, sending a

<U1> $ Beam_Palette #, or <U1> $ Color_Palette # etc seems to default to posting:

'Beam Palette 1' or Color Palette 1' etc to the command line. (If I put a number following the command, it will run that particular palette number).

You are sending a CR (&h0D) after the command. This is the same as pressing [Beam Palette] [1] [Enter].

To layer commands don't send a CR until your command line is finished.

irw said:

Basically, it all seems very inconsistent with regards to commands that are/are not/are a little bit supported, with very little documentation!

 

A little unfair, the document doesn't detail every single possible button press (but does say every button is possiable) as it would go out of date the moment a new version of software is released.

irw said:

I suppose what I'm looking for is something similar to what Strand produced for Genius Pro (manual extract attached) with relation to their MIDI messages and key codes! (see about halfway down the attached document) By using these reference codes, you are able to send pretty much any command the desk could respond to via the serial port.

 

Keycodes makes for a difficult for human to read command line, but does allow it tobe sent faster. Modern serial speeds mean we can send human readable commands with out experiencing lag. Again you can send and command via serial/UDP to the EOS. MSC is also fully implemented.

The only difference between EOS and Genius Pro with CommuniquéPro is the fact that CommuniquéPro assigned every action to a midi note/sys ex command.

On a cue stack based desk (like the EOS, and Strand 300/500) it seems folly to have every action pump out a midi command.

On a "busking" based desk (like the Cobalt/Congo) it makes more sense.

Hi Marcus.

Terribly sorry, I completely forgot about this thread until I've just started looking at my little project again!

Thanks for the comment about sending the CR after the command- I've tried leaving this off and suddenly things are behaving as I would expect them to.

I understand what you are saying about a list of supported commands going out of date with new software releases, but it would be nice to have something as a basis to work from, instead of doing everything by trial and error!

Going back to the subject of the Macro Editor- when programming softkeys into the macro editor, it looks to me like when you scroll through the list you are seeing all the various 'pages' of softkeys, resulting in many, many duplicates- I'm sure I've seen somewhere on this forum (a while ago) that there were plans in the pipeline to tidy this up? It would be incredibly helpful if it could display commands in alphabetical order, for example!

Thanks,

Ian

you'll get your wish for alphabetized softkeys in the macro editor in less than two weeks ;)