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?

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.

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?

Mathilda, from what I've gathered from various interactions, is that he is trying to "build a better mousetrap" by creating a completely outside of EOS playback system. He is using a custom plug-in, riding on top of Blender, so in order for his playback system to work he is hacking in playback command via OSC and other network-based commands. Thereby using Eos primarily for it's fade engine. And adding two layers of abstraction from the fade engine.