WhiteMagic

It depends on what your response curve looks like, if it sends a non-zero value at rest then it is expected that the value will change, as Gremlin won't see...

It's a bit odd that this should cause a hang. For one, that function won't do anything meaningful unless there is significant movement in an axis, i.e. +/- 25% by...

I suspect this isn't so much the actions not triggering, as there is actually code to ensure this doesn't happen, but rather the actions being executed in an "incorrect" order....

There is definitely no way to react to a script being unloaded, as that is actually not something that ever happens. There are also no events defined for starting/stopping Gremlin...

The sequence of the different macros is what is likely not happening in the expected sequence. The actions inside the macro are guaranteed to be executed in order. The reason...

Yeah that kind of event stuff has been on the list of things to add at some point for a while now, see #140. I'll see if I can figure...

This isn't so much of a bug but rather simply something that hasn't been implemented for the button controlled mouse movements. Hat and axis inputs handle this properly.

Actually, that will work. You need to add a macro to each arrow direction which sends a physical joystick event on press and a second event on release to reset...

You probably could work around this by having the macro that sets the axis back to 0.0 only trigger if the "opposite" direction input is not pressed, but that is...

The problem isn't with the tempo container but rather with the macro operation mode you are using. These modes are quirky and depending on how exactly containers implement their actions...