Concurrent Macros?

Is it possible to referenz them internaly?
So that one Macro is triggering an other?

What are your Macros doing and what are you like to achieve?

Not possible to reference internally. 

One macro says things like "1 at full delay 3 enter" while the other says something like "1 at 0 delay 5 enter". I cannot get both those macros to execute simultaneously so that I fire both at the same time such that channel 1 goes to full at 3 seconds and goes out at 5 seconds. There's a very good reason why I need to do this that I can't adequately get into here.

I think it's not actually a macro limitation but a "delay" command limitation. Can't send multiple delay commands to same fixture. The old one will just get overwritten. Super frustrating because if this was open source I could actually look and see why exactly this is happening and see how easy it would be to fix—whether 5 minutes or 5 hours.

It's probably something like.. I mean if I were coding a command line, which I will be soon, I would (probably) make each command line execution be a separate controller that can make its own change requests. That way there's no limit to how many can be running simultaneously. So that way you're setting yourself up for success, not failure. But if it's set up instead where these controllers are set up on the parameter and they are just commandeered by command line, then it's like, well why?

Just like when you actually type commands in the command line, changes to manual values don't "stack", they are immediately executed.

This is expected behavior.

I think your issue is you are coming at this with a different mental model to how its designed to work.  Fundamentally the delay in the command line is not an instruction to the command line processor, but is setting an attribute on the channel you are addressing.    So the command is executing immediately and setting the target value for the channel and the delay time for when you want it to go to that value. 

You are kind of re inventing what the desk will do for you without creating the macro in that way.  its just a cue list with a follow that says turn it on after 3 and then off after another 2 seconds.  You can have multiple cue lists.

this might work (but not sure about the delay on the up):

record a sub:  1 @ full.  Sub properties:  time 1 up, dwell 3, down time 3 (or whatever)

write your macro to execute the submaster (same as pressing the bump button).

maybe the up dwell could be a pause in the macro before it triggers the sub. . . . .

Andrew

I just recorded a video showing exactly what I'm trying to do, but the lag was so insane that you can't even see what it's doing because the Eos screen was only recorded at 1 frame every 5 seconds, but here it is anyway: www.youtube.com/watch

Can't use the submaster method because they need to be on multiple independent strips and each individual offset fixture needs its own unique delay time (you'll see what I mean in the video, it's basically creating a super intuitive chase/wipe effect without an effects engine.)

Mike A said:

but is setting an attribute on the channel you are addressing

I was afraid of that, that's what it seems like. 

I may be able to get cue lists to do what I need, but that will be a ton of extra coding to get that to work, plus it's way more annoying for my end user to have to assign each strip not just a macro, but a cue list as well, one for each unique strip.

It would be amazing if the show control system was able to do command line events. That would delete a lot of steps.

i don't realy get what you try to do?
Is it just a swoop from left to right over some striplights in a row?

Well this is an earlier version of it at around 38:11: https://youtu.be/9oKZKP3hfjc?si=qP0Swl9VofJ-mOpN&t=2291

This is the last thing I need to get these stupid things stored onto the console. I finally figured out how to macrotize it, but now the issue is that they can't overlap. Everything else in Sequncer is macrotized, except this. So it's really dumb. And I really want it to be macrotized. Right now to get it to work properly with overlaps, you still have to have Sequencer running during the show. So basically, you can't truly use this for real-world. Yet. But this is one feature out of dozens and all the other features are fully macrotized, meaning you can shut down Sequencer and everything works perfectly fine just with Eos running it. Except these stupid things. Because "Delay" is a  parameter attribute, not a controller, which is really annoying because it means it can only be used for exactly what it was meant to be used for, which is really annoying. Better software in my opinion can be used a million different ways that are not the original intended use case.

If Delay were a controller, not a parameter attribute, it's just way more robust. By controller I mean, "Hello, my name is delay. I am a class instance created by user at time [whatever] and in 5 seconds from now I'm going to do a thing. The user can make as many different instances of me as they want for any purpose." So basically OOP. As a parameter attribute, as it's seemingly written, it's more like, "Hello, my name is Delay. I am an inherent property of this parameter and I can only do one thing at a time, and each parameter can only have one of me."

OK, so it looks like you like to have an FX on a group. Why not use an FX for it and don't code something with macros and delays?

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

Oh, it's a remote control software that makes effects on Eos super stupid simple and intuitive. After trying to timecode with limited equipment on Eos for a while, I just about went insane. I fixed it with super cool software that I released almost a year ago. Key thing is that it's not DMX software, it's OSC remote control software, so you don't have to give up the pro console to have sequence-based timecode editing. You have that now.

The issue in this post was getting one specific type of effect strip to go from streaming OSC to stored onto the console (for reliability). It works just fine, I just want to be able to store the data on the console.

I think I will ultimately have to teach my Orb how to build effects, since macros just aren't cutting it. I wanted to use macros/command line to do it instead of effects because it's way easier to teach a robot how to autonomously do that on Eos than to teach a robot how to autonomously build an effect on Eos. But my Orb is already super smart, so it will probably only take a day or two to get it making its own effects.

Why program an Orb to build what you can manually build on the console? Because it makes the art 3x faster for experienced users and about 10x faster for inexperienced users.