Concurrent Macros?

Reading though this list of posts it seems like you are trying to use/create external software to control eos to not use the built in effects package but control channels independently but also record that back into the eos somehow.......

Not really sure why you would want to do this other than curiosity.

You are coming at this from a coding background but console programming comes from a design background and historic theater.  You may be able to do more of what you are looking for using OSC but it seems like you are hung up on using macros.  Eos does not have a very advanced macro language yet.  It has been discussed and considered over the years but there are many other priorities in the development of this console line.

The effects in the video you posted can be achieved with the features already in the console without macrotizing.  

If you can give a good explanation of what result you are looking for rather than the actions you want to take to get the result we can help you with the current software that is available to achieve those results. 

If you just want to code and ignore what the software is built to do you may want to look at the MA line of consoles as they are more open to 3rd party enhancement through LUA scripts and have a more advanced macro engine in them.  

Lighting consoles are tools and finding the right tool for you and your job is important.  

I love programming on Eos consoles but have also learned how to program other systems and use that knowledge to expand my use of Eos.

This is not meant to offend just trying to help and understand what you are trying to achieve.

Andrew Webberley

Yea I have also been following the past few post wondering when the reason for all the needs for work arounds was coming as well. Just trying to make his software do what he wants instead of learning how to use the console to get what he wants.

This sweep forward and backward is so simple if you use the console how it is intended to be used.

chan X thru chan Y at # delay 0 thru timeA, record cue #

select last offset reverse at 0 delay 0 thru timeB, record cue next.

Set timecode events to trigger cues (my favorite method is export markers from video editor, import csv list)

Sure, if you like geeky techno syntax. But not if you prefer organic artistic flow.

Cameron, you hit the nail on the head... basically Eos doesn't use a Bender like workflow (that he is accustomed to), and doesn't want to wrap his head around conventional theatrical cue stacks. No problem, there are more than one way to program lights and many vendors take different approaches.

I know several people who have written their own lighting software, some that do a timeline like his approach. I did a bunch of code maintenance, patching and feature development for one of them that was commercially available and even deployed at a major show in Vegas. But its largest weakness was the fade engine, didn't scale as necessary and had to be virtually re-written, and they're complex beasts, especially to be performant. 

However, no other system that I know of has gone to the point of basically creating a whole new software that makes two other systems (Blender and Eos) do things they were not intended to do, simply because he doesn't want to go the extra step to make a fade engine and have his own actual lighting software... Its one thing to have software that adds functionality to what Eos is doing at its core, but its another to expect Eos to change fundamentally how things work so that you can work around half of the system because you don't understand how it is supposed to work. 

This is evident by his initial post here, in the Eos syntax you'd never use delay in that sort of way. There are a handful of ways, but I think many of us would simply use a follow cue, and be done with it. A very conventional way, instead of trying to send two macros simultaneously, which have commands that contraction one another. Instead of putting the timing onus on his software to simply send the command when he wants them to execute.

The reason it's not DMX software is because why would you want to delete the strengths of Eos? It's a team effort. It allows Eos to only do what Eos is the very best at, it allows Blender to do what Blender is really good at, and it allows Sorcerer, my software, to combine them seamlessly with automation and a user-centric UX designed for middle school theatre.

This is not designed for professional lighting console programmers. It's designed for nontechnical people with ADHD who suffer at the hand of Eos's gaping weaknesses, who have to use Eos anyway because of its strengths. It's for people who want to be able to just focus on art without all the technicals, without having to delete the theater's console. 

Why would I design yet another free dmx sequence based software when I can't compete against what Eos does best? I can't compete against its industry proliferation and with its FOH reliability and hardware. So I'm not. I'm adding to it.

And my complaint above was an honest question about a problem that only someone working on the type of project I'm working on would ever have. Yes, I now understand why the limitation is there. I do think a more OOP approach would ultimately be more powerful for Eos, but whatever. It's no big deal. I've already solved this problem on my end.

The reason it's not DMX software is because why would you want to delete the strengths of Eos? It's a team effort. It allows Eos to only do what Eos is the very best at, it allows Blender to do what Blender is really good at, and it allows Sorcerer, my software, to combine them seamlessly with automation and a user-centric UX designed for middle school theatre.

This is not designed for professional lighting console programmers. It's designed for nontechnical people with ADHD who suffer at the hand of Eos's gaping weaknesses, who have to use Eos anyway because of its strengths. It's for people who want to be able to just focus on art without all the technicals, without having to delete the theater's console. 

Why would I design yet another free dmx sequence based software when I can't compete against what Eos does best? I can't compete against its industry proliferation and with its FOH reliability and hardware. So I'm not. I'm adding to it.

And my complaint above was an honest question about a problem that only someone working on the type of project I'm working on would ever have. Yes, I now understand why the limitation is there. I do think a more OOP approach would ultimately be more powerful for Eos, but whatever. It's no big deal. I've already solved this problem on my end.