Bc2000 (for the BCF2000 & BCR2000)

Royce -

Could you possibly try the following BCR script for me? (I'm going a 
bit batty.)

$rev R1
$preset
  .name '32 MCU VPots            '
  .snapshot off
  .request off
  .egroups 4
  .fkeys on
  .lock off
  .init
 
$encoder 1
  .minmax 0 127
  .default 0
  .tx $F0 144 46 127 144 46 127 144 46 127 $B0 16 ifp 1 ifn 65 $F7
  .resolution 96 96 96 96
  .showvalue off
  .mode 1-dot

$end


Of course it uses only encoder 1 and initializes all the others. 
(Very interesting point: if you *omit* the .init above, it does *not* 
initialize any other controller. Please verify this.)

If encoder 1 is turned positive, the expected result occurs: 3 
identical CC messages plus a 1 from the encoder. If turned negative, 
the same except a 65 from the encoder - *but* then comes an extra 
spurious message, with an absolutely wacko timestamp (the same each 
time, suggesting an erroneous code origin).

Multiple encoders of the same ilk give similar results.

One hint: when loading, the BCR signals a brief Error 12 before 
ending. This error is repeated for each encoder transferred.

Incidentally, it gets even wilder if I split this up into a .tx (for 
the three controller messages) and an .easypar. Then I get both an 
Error 14 and an Error 12 for each encoder. (But we'll leave that for 
another time.)

Any idea as to what could be causing the error? And does the script 
behave the same way for you?

Thanks for your help -

Art Hunkins

--- In bc2000@yahoogroups.com, "rpcfender" <rpcfender@...> wrote:
>
> Art
> 
> > Attached are script and sysex followup files to my previous post.
> 
> I can't seem to access them.
> 
> >They separate out the encoder code into .easypar statements 
followed by
> the required bank +/- data in .tx. Seems to me that
> >Royce mentioned you could include *both* .tx and .easypar in an
> encoder; if I'm wrong, obviously this will not work (and
> >the possibility of receiving return MIDI code adjusting the LED's 
seems
> out of the question).
> 
> It works well, Art.
> .easypar and .tx seem to be stored in separate areas. That's 
probably
> why the LED feedback only works with one of them.
> 
> >
> > 32VPotsOverlay2 specifies .default 0; Overlay3 has all .default = 
1;
> Overlay4, .default = 3.
> >
> > Please let me know if any of these work. Royce, how do you see 
it? Do
> we need to give up on LED feedback? (Maybe better to have no 
display at
> all, and just track the values in the DAW?)
> 
> Personally I could get use to the .mode spread It reminds me of the
> green fluro displays on the early tape recorders
> 
> >
> > Royce, I'd also like to know whether all these parameters are
> necessary - especially .minmax when .easypar is present. Also, 
should
> .resolution be changed with relative-3 encoders? Should they be 
maybe
> .resolution 24 24 24 24 to ensure one "click" per 
increment/decrement
> (doesn't the BCF/R have 24 [or 32?] stops per rotation)?
> 
> As it is usual to have .minmax with a .tx control, be aware 
that .minmax
> takes precedence over the .easypar range
> 
> $encoder 1
> .easypar CC 01 07 0 127 absolute
> .minmax  20 40
> 
> Gives a range of 20 to 40.
> You don't have to have .minmax as the range can come from 
the .easypar.
> 
> Also be aware that .resolution is required if you have .tx by 
itself.
> Where there are the both easypar and .tx then you don't ned it . 
Don't
> know why.
> 
> 
> The mechanical resolution of the encoders is 96 'clicks' per 360
> degrees, hence the default value of .resolution
> The mechanical resolution gives the max number of times the BC can
> output a MIDI message per turn
> The .resolution just gives the range of the MIDI message value per 
360
> degrees
> 
>   .resolution x is equal to  .resolution x x x x
> 
>   So .resolution 96  gives 1 2 3 4 5 6 etc
>     .resolution 192  gives 1  3  5 7 9 etc
>     .resolution 288  gives 1  4  7 10 etc
> 
> Jump in MIDI value per click = ( resolution  value / 96)
> 
>   So the short answer [:)]   anything at or above  .resolution 96 
gives
> the max number of 'clicks' per revolution.
> If the value range is shorter than the resolution the BC doesn't 
output
> duplicate MIDI messages.
> 
> All the best
> 
> Royce
>