--- In
bc2000@yahoogroups.com, Alex wrote:
> I would like to configure the Slim Phatty Arpeggiator Clock Rate to one of
> my BCR2000 encoders but I get a strange behavior and I need your help again.
> Thanks in advance.
>
> First of all this is what manual says:
>
> *"**The Arpeggiator Clock Rate is set by two MIDI CC messages that
> correspond to coarse and fine clock rates. The coarse rate is set by CC#04
> in increments of 3 BPM over a range of 21-320 BPM, and the fine rate is set
> by CC#36 in increments of 0.1 BPM. To set the clock rate, first set the
> coarse rate by dividing the target BPM by three; the integer result (the
> whole number) will be the CC#04 value. Then set the fine clock rate by
> subtracting the coarse BPM value from the target value and multiplying the
> result by 10. This will be the CC#36 value.**
> *
> *
> **For example, to set the Arpeggiator Clock Rate to 121.7 BPM:**
> **
> **Determine the MIDI CC coarse value by dividing the target BPM by 3:**
> **
> **121.7/3 = 40.566**
> **
> **The CC#04 value is `40' (=120 BPM)**
> **
> **Determine the MIDI CC fine value by subtracting the coarse BPM value from
> the target value:**
> **
> **121.7 - 120 = 1.7**
> **
> **Then multiply the result by 10:**
> **
> **1.7 * 10 = 17**
> **
> **The CC#36 value is `17'**
> **
> *
> *For CC#04 = 40 and CC#36 = 17, the Slim Phatty's display will show `121.7
> BPM'."*
>
> After assigning the CC#04 in absolute (14-bits) mode and with a resolution
> of 96 for testing every value, this is what I get: (I only tested the first
> 640 values)
>
> Values BPM
>
> 0-494 ---> 20.0
> 495 ---> 20.1
> .
> .
> 511 ---> 21.7
> 512-592 ---> 20.0
> 593 ---> 20.1
> .
> .
> 639 ---> 24.7
> 640 ---> 20.0
>
> Could somebody tell me how should I set this encoder in BC Manager to get
> the full range, from 20.0 to 320.0 BPM, without these jumps and gaps?
You're using absolute-14 mode, so the encoder's Value is split between CC4 and CC36 as follows:
CC4 output = Value div 128 (i.e. the integer part of Value/128)
CC36 output = Value mod 128 (i.e. the remainder, i.e. Value - Value div 128)
I don't fully understand the pattern behind the strange BPMs in your table, but in any case your test range of encoder values seems to be below the legal range specified in the Slim Phatty manual:
The manual says that the lowest acceptable BPM value is 21. (Actually the Slim Phatty appears to be capable of 20 BPM, as your table shows, but let's forget about that for the moment.)
According to the manual, a BPM value of 21 requires the CC4 output to be 21/3 = 7.
To achieve this, the encoder's Value must be 7*128 = 896 (remember that CC4 sends the "multiples of 128" part of the encoder's Value).
And since 21 BPM is the "officially" lowest value, the "legal" encoder Value's range starts at 896.
If this is so, you should ultimately set the encoder's minimum value ("Value 1") to 896. (Actually you might also check what happens to the range from 768 to 895.)
I suppose that lower values may lead to "undefined behavior" - which is indeed what you've found.
But even so, if I understand the Slim Phatty manual correctly, only the first 30 values of each "cycle" starting at a multiple of 128 are "legal", because CC36 ranges from 0 to 29:
896 -> 21.0
897 -> 21.1
...
925 -> 23.9
926 -> 24.0 ? (may or may not work)
927 -> ????
... -> ????
1024 (i.e. 896+128) -> 24.0
1025 -> 24.1
Etc.
So depending on how the Slim Phatty actually interprets the gaps between the legal ranges, you might indeed get strange jumps.
And if that is the case, it may be better to use TWO encoders, one sending only CC4, the other only CC36:
Both should use mode "absolute" (i.e. 7 bits).
The encoder sending CC4:
Value 1 = 21 div 3 = 7 (you might try 6)
Value 2 = 320 div 3 = 106 (you might try 107)
The encoder sending CC36:
Value 1 = 0
Value 2 = 29 (possibly 30; or maybe even 127, depending on the Slim Phatty's treatment of these "out of range" values)
One advantage of this setup with two encoders is that the values shown in the BCR's display correspond much more directly with the resulting BPMs than those horribly high numbers you get in absolute-14 mode.
Hope this helps (and that I haven't made any arithmetical mistakes...!)
Mark.
