03-20-2021, 01:18 PM
I spent some time with the CC Scale MODS today, as manipulating CC data is one of my favorite pastimes. I must say that I really like the graphical depiction of input range of data and how that becomes the output range of data. It makes visualizing some tasks easier. But, for some simple functions I found it actually getting in the way, and a bit cumbersome. Call me 'old school,' but I'd really appreciate some way of entering 'straight line equation' data. It would just be more straight forward for the way I think. For example, to do a simple "add 3" to the data I have to subtract 3 from Source Hi (124) and add 3 to Destination Lo (3). I'll document that as:
Source Hi: 124, Source Lo: 0, Destination Hi: 127, Destination Lo: 3
Then, to subtract 3 from CC data:
Source Hi: 127, Source Lo: 3, Destination Hi: 124, Destination Lo: 0
To multiply by 2:
Source Hi: 63, Source Lo: 0, Destination Hi: 127, Destination Lo: 0
To divide by 2:
Source Hi: 127, Source Lo: 0, Destination Hi: 64, Destination Lo: 1
Although all that seems obvious, it forced me to think about representing simple concepts more than I liked.
To that end, I propose a simple modification to this screen. The bottom portion of the screen dedicated to to graphical representation of source and destination data appears to take up the equivalent of three lines of text. I would like when the encoder is twisted clockwise from the last data entry location of the current screen, the the bottom three lines be replaced with these three lines:
Y=mX+b
m: 1.0000
b: 0
The user could supply values for m and b. Of course, if any values were modified in the graphical screen, they would be reflected here in the equation screen. Likewise, any changes here would be reflected in the graphical depiction when the encoder is twisted counterclockwise returning us to that screen. The point being, you can enter your CC Scale MODS in either of two ways. These two entry methods don't fight or conflict with each other, but rather express the same data in two different ways.
Now, I do realize that setting m values with an encoder knob could pose quite a challenge. After all, it has to be a real number, not an integer. Perhaps limit it to five significant digits and allow the placement of the cursor under specific digits will allow faster value entry by the user. That way, divide by 2 (0.5) or divide by 5 (0.2) are easy, divide by 4 (0.25) not so bad, and divide by 3 (0.3333) would be manageable.
This change would really make working with CC# manipulations much easier - for those that think like me.
HdK
Source Hi: 124, Source Lo: 0, Destination Hi: 127, Destination Lo: 3
Then, to subtract 3 from CC data:
Source Hi: 127, Source Lo: 3, Destination Hi: 124, Destination Lo: 0
To multiply by 2:
Source Hi: 63, Source Lo: 0, Destination Hi: 127, Destination Lo: 0
To divide by 2:
Source Hi: 127, Source Lo: 0, Destination Hi: 64, Destination Lo: 1
Although all that seems obvious, it forced me to think about representing simple concepts more than I liked.
To that end, I propose a simple modification to this screen. The bottom portion of the screen dedicated to to graphical representation of source and destination data appears to take up the equivalent of three lines of text. I would like when the encoder is twisted clockwise from the last data entry location of the current screen, the the bottom three lines be replaced with these three lines:
Y=mX+b
m: 1.0000
b: 0
The user could supply values for m and b. Of course, if any values were modified in the graphical screen, they would be reflected here in the equation screen. Likewise, any changes here would be reflected in the graphical depiction when the encoder is twisted counterclockwise returning us to that screen. The point being, you can enter your CC Scale MODS in either of two ways. These two entry methods don't fight or conflict with each other, but rather express the same data in two different ways.
Now, I do realize that setting m values with an encoder knob could pose quite a challenge. After all, it has to be a real number, not an integer. Perhaps limit it to five significant digits and allow the placement of the cursor under specific digits will allow faster value entry by the user. That way, divide by 2 (0.5) or divide by 5 (0.2) are easy, divide by 4 (0.25) not so bad, and divide by 3 (0.3333) would be manageable.
This change would really make working with CC# manipulations much easier - for those that think like me.
HdK
