View Single Post
Old 03-03-2012, 10:33 AM   #354
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Default

After reading the updated notes in the default OSC configuration file, I have a few comments:

The notes about TRACK_FOLLOWS and BANK_FOLLOWS do not mention that REAPER should follow the track/bank selected in the device. Without explanation, new users will likely be confused by the term "track follows" because they will see REAPER's track selection following the device and wrongly assume it's related to the TRACK_FOLLOWS setting (also see my earlier remarks here). Thus, it probably shouldn't do so by default (i.e. unless specifically told to do so, which we haven't yet). More so because it can't be disabled. Currently, even if all three TRACK_FOLLOWS, BANK_FOLLOWS, FX_FOLLOWS are set to DEVICE, REAPER is still following the control surface. Which makes it practically impossible to use a control surface in parallel with REAPER's GUI. When one uses multiple control surfaces, the skies will fall on our heads.

---

'Actions' should not be defined or categorized with direct reference to particular types of control elements. They may serve well as illustrative examples, but we have to be careful not to be more confusing than helpful. For example:
Quote:
Originally Posted by Default.ReaperOSC
# Actions that emulate buttons that do not latch, but have a light to indicate on/off.
It is not the action which emulates the behavior of a button (what does a button do then? A button can do anything...), but the control of that action. And for our purposes, there is no difference between a button and e.g. a switch. It should be described as a binary state, e.g. on/off, 0/1. Then you can mention that these are commonly controlled with buttons, switches, latches etc., but that should not be the definition. And since when does it matter whether a button has a light or not? Should users now go look at REAPER's GUI (default skin, of course) and check for functions that are represented by 'photorealistic' LEDs to know what is supported by OSC in which manner?

Quote:
Originally Posted by Default.ReaperOSC
# Actions that emulate faders or knobs.
Bad, not only because "fader" implies a certain function, in contrast to the more generic term "slider", but also because of the same reasons as above. An XY-pad or accelerometer also has a continuous range, but isn't a fader or knob. The typical targets of all these type of controls should rather be defined by their continuous range between fixed end points. And then we can give examples.

Quote:
Originally Posted by Default.ReaperOSC
# Actions that emulate endless rotary controls.
Again, the description is overly specific to irrelevant aspects. One can just as well achieve the same messages with two buttons as with one endless rotary knob. The unique bit is "endless", not "rotary" as in
Quote:
Originally Posted by Default.ReaperOSC
SCRUB_ROTARY /scrub/rotary
So, apparently, some actions are categorized by the ways in which they can be controlled. I think this is a really bad idea, because (1) the ways they can be controlled should not be fixed but configurable (see below), and (2) they should rather be grouped by functionality. If you have a multimode filter with one control for the cut-off frequency and another to switch between low pass / high pass filters, you don't want them ending up in completely different places because one has a knob and the other a button - and neither because has a binary state and the other a continuous range between fixed end points. They should remain close together because their functionality is highly complementary.

Some other actions have now apparently been grouped by directionality: send only, receive only, or bidirectional. This is also a bad idea imho. For many actions imho the user should be able to configure the direction of actions. We should be able to have REAPER send out a message every time it performs /action/12345 but *not* respond to such an OSC message. We should also be able to have REAPER send messages when FX_PREV_PRESET / FX_NEXT_PRESET are selected. Conversely, we should be able to set TRACK_NUMBER, TRACK_BANK_EDIT (which should be renamed "TRACK_BANK_NUMBER", FX_NUMBER, FX_PARAM_PAGE_NUMBER, FX_PRESET *directly*, i.e. have REAPER listen to them and not just send them. If any such changes would be implemented, it would imply that their definitions should be rearranged as well; that doesn't make much sense to me.

---

I think all the 'toggle' actions are an example of poor configurability. What we should do, is make the configuration smarter, not necessarily bigger. In this case, big is bad. Even by adding one simple -toggle flag, we could delete the entire *_TOGGLE section.

We currently have 2 sets of actions to achieve the exact same purpose, and there is not a single case where the feedback between both sets is different. The *only* difference is that we want the action to respond slightly differently to incoming messages, in this case whether we want to 'toggle' or not. We should do something slightly more sophisticated, like:

Code:
TRACK_MUTE -toggle /track/mute /track/@/mute
vs.
TRACK_MUTE -momentary /track/mute /track/@/mute
... where -toggle and -momentary are flags for predefined behavior (one of them could be left out if it is already clear what default behavior can be expected), and/or even more sophisticated, and allow the user to configure to what arguments the action should respond. We could do things like:
Code:
TRACK_MUTE {SEND} -ON 1 -OFF 0 {RECEIVE} -ON 1 -OFF 0 /track/mute /track/@/mute
vs.
TRACK_MUTE {SEND} -ON 1 -OFF 0 {RECEIVE} -ON * -OFF * /track/mute /track/@/mute
(of course the particular syntax is not really important, as long as its unambiguous)

I can think of many more interesting things we could do with configuration flags, e.g. set limits, rescale by applying breakpoint curves (e.g. -{1.0,0.0 0.0,1.0} to invert), set directions (e.g. use -receiveonly to limit feedback), etc.

Since OSC messages need to begin with a /, there's plenty opportunity to designate other characters between the action description and the message pattern. Let's use it.
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote