FeatureRequest: Granular delays

[AlexWHughes]

It would be great to allow people to pick parameters that are then triggered during the next "drop" or tempo change. All of the triggering can be done within MA what twitch2MA needs to do is allow messages to be either queued or discarded once the first command has been selected.

For example, if someone says !red they have to wait till either a telnet message is sent back or they have to wait 30 seconds, etc to prevent choices being overwritten.

If you could set parameter based group ones for colour, video, gobo, etc then multiple people could contribute to the "look"

[schw4rzlicht]

All of the triggering can be done within MA what twitch2MA needs to do is allow messages to be either queued or discarded once the first command has been selected.

For example, if someone says !red they have to wait till either a telnet message is sent back or they have to wait 30 seconds, etc to prevent choices being overwritten.

That's kind of unclear to me since Telnet is unidirectional (EDIT Unidirectional in a sense that we cannot affect messages received from the MA). The challenge would be to tell twitch2ma when to accept commands again.

When you speak about queing: Do you just want to queue twitch commands and let the desk "get" the next command when needed (via whatever mechanism)?

When using timeouts configured in config.json how would you go about synchronizing?

If you could set parameter based group ones for colour, video, gobo, etc then multiple people could contribute to the "look"

This could easily be done using something like parameters for commands. So you could define a !color command and add parameters like blue, red etc. That should be relatively easy to implement and wouldn't break older configurations.

[schw4rzlicht]

I already implemented that part:

This could easily be done using something like parameters for commands. So you could define a !color command and add parameters like blue, red etc. That should be relatively easy to implement and wouldn't break older configurations.

It's not a stable release yet but you can test it when installing 1.6.0-rc1 like this:

npm i -g twitch2ma@1.6.0-rc1

[AlexWHughes]

The telnet back was just more of a brain dump. I don't think its a requirement or has much value.

MA would have to talk back on a different port and while it is possible just allowing delays for parameters is a great step forward. The only value is two way communication is you can send an message back to twitch2MA to say "hey I am ready to take another command"

[schw4rzlicht]

Implementation details:

• add optional configuration for each command/parameter which defines a sACN universe and channel
• when configured, ignore timeout and only accept new commands when the configured channel is at 100%
• send a message to Twitch chat when somebody tries to execute something that is currently blocked by sACN

Does that match the feature request?

[AlexWHughes]

That does only addition I would make would be
send a message to Twitch chat that can be customised when somebody tries to execute something that is currently blocked by sACN

[schw4rzlicht]

sACN locks are available in 1.13.0-rc.1. Feedback appreciated :)

[schw4rzlicht]

Fixed in 1.13.0