I am trying to make macros to increment and decrement the level of a sub by 1%, but the syntax that you would use to do so for a channel does not work. For example:[Sub]    [At] [+]   [Enter] or [Sub]    [At] [-]   [Enter]
When you type the above examples into the command line, there is a syntax error as soon as you press [+] or [-]. If you make a macro with it, the [+] or [-] is just left out when it executes and it sets the submaster to a level of 01. Targeting the fader instead of the sub behaves the same.
I have tried this on Eos versions 18.104.22.168, 22.214.171.124, and 126.96.36.199.
I have the same problem trying to send the console an OSC and or MIDI command to increment +- a fader (this would make midi controllers that have rotary encoders a good deal easier to synchronize across pages...) The OSC library has contained references to manipulating a sub or fader in this fashion since the inclusion of OSC in EOS, it just throws a red error.
Nomad, GIO @5 and ION
MIDI controller Arturia Beatstep, Continuous Control in Increment +- mode where a Knob + sends a CC on N channel at Value 65, and Knob - Sends value 63. This reduces the need to poll for the Current fader position and simply increases it or decreases it.
OSC use would be similar but using an Arduino to generate OSC when a rotary knob is moved. I know i can poll for a fader page, but this method may reduce programming overhead and time for this type of control (no need for scribbles/feedback but also no need for hardware takeover, all while still having paging)
I think that this is by design, as seen in this forum post from long ago:
It's not what you want, but you can record fader movements into macros by hitting the learn button and moving them around, and you can edit those macros. A fader movement is a console event, so the commands will appear in blue, and if any of your edits appear in a color other than blue, then they won't take when you play the macro back.
Also, in the context of a console event macro, the faders index from 0 and don't reference the fader page. So what we think of as faders 1/1 through 1/10 are faders 0 through 9 in the board, and 2/1 through 2/10 are 10 through 19, etc. They also take single-digit values, eg "5" instead of "05." So for example, if you move fader 1/3 to 10%, then (depending on how quickly you do it) it would record a macro like this:
FaderMove 2 1 Enter
FaderMove 2 2 Enter
FaderMove 2 3 Enter
FaderMove 2 4 Enter
FaderMove 2 5 Enter
FaderMove 2 6 Enter
FaderMove 2 7 Enter
FaderMove 2 8 Enter
FaderMove 2 9 Enter
FaderMove 2 10 Enter
I too wish that you could build a macro to increment/decrement a sub or a fader. It would be so much fun.
Thanks Cody Whitfield. I did see that you can track fader movements in macros and also how they reference sequentially rather than using a fader page offset. However, if you want to use a macro to tell a specific fader to go to a value (rather than referencing a sub), using the offset syntax, such as Fader 5/1, does work. I haven't tried using the sequential fader number.
The post that you linked is sort of related, but that user was asking about the fader movement snapping even if a fade time was specified. I have a suspicion that the behavior that caused me to post may be a bug or something that was just overlooked.
The part of the post that I wanted to draw attention to was Anne's second reply, in which she says that faders never track fade progression. There's probably a better example somewhere in the archives, but I'm pretty sure that that's the justification for submasters and faders being harder to control than channels in increments/decrements, and faders not being able to sneak or move in time (Except through bumping or sending it home), etc. But hopefully I'm wrong or I've misinterpreted it, and it's a bug, and there will be a fix!
Ah, gotcha. My thought process is that if you can direct a sub or fader to go to a specific value then you should be able to increment/decrement it.