Bc2000 (for the BCF2000 & BCR2000)

--- In bc2000@yahoogroups.com, sghookings@... wrote:
> the green triangle (on BCL editor) is a "set noexec on" type command,

The green triangle ("Execute") indeed doesn't send the script to the BCF/BCR, but it does "send" the script to the BCF/BCR's "context" within BC Manager. So in that respect "Execute" does have an effect - it's not only a "syntax check". Come to think of it, it might be a good idea to implement such a syntax check; can't be too difficult...

> when I pressed the green left
> hand midi symbol, and then pressed the appropriate button on BCR (having
> first selected Record from your MIDI input) meant I could see why I had
> written a buggy scripts.

"Never change a winning team" - but couldn't you just have pressed the green "Execute" triangle, at least to see any syntax errors? Then you get a list of any syntax errors in the "BCL errors" window (it should pop up automatically when an error is found).

But of course for debugging the "meaning" of a script (i.e. the BCF/R's MIDI output), your method (with the "MIDI input messages" window) is absolutely right - at least it's exactly how I always test scripts!

> Sorry for the noob questions; I guess we all gotta start somewhere :-).

I think you've been doing quite well... In tackling button increment mode, you've jumped in at the very deepest end of BCL! It's just horrendously complicated.

> I dont doubt there are
> more optimal ways to achieve this, but I am still reading the manual.
> $rev R1 ; Firmware 1.10; BC Manager 2.3.1
> $button 39
> .easypar NRPN 1 43 20 1 increment 1
> .mode incval 1
> .minmax 0 20
> .showvalue on
> .tx $B0 99 0
> .tx $B0 98 43
> .tx $B0 6 0
> .tx $B0 38 val
> $end

> $rev R1 ; Firmware 1.10; BC Manager 2.3.1
> $button 47
> .easypar NRPN 1 43 1 20 increment 1
> .mode incval -1
> .minmax 0 20
> .showvalue on
> .tx $B0 99 0
> .tx $B0 98 43
> .tx $B0 6 0
> .tx $B0 38 val
> $end

> I suspect I probably should have done an easypar of 20 1 increment -1
> and then I can ignore the .incvalOr even 20 0 increment -1. Lots of
> playing for me here :-).
> NOTE: the essence of this button mapping it to associate the 7 bit MSB
> NPRN value, with the 7bit LSB NRPN value.

First of all: in your definition for button 47, the easypar statement's Value 1 (1) is lower than Value 2 (20).

In itself, this will never work, because:

"Value1 must always be higher than Value2, otherwise Value will immediately stick at Value1 if Increment is negative, and at Value2 if Increment is positive." (BCMI, section 15.10.)

Actually, this easypar statement is "saved" by the subsequent "mode incval" statement, because it overrides easypar's invalid value range with a correct range. (In a "mode incval" statement, Value1 has to be LOWER than Value2.)

But in general I think it is pointless to have both "easypar NRPN increment" and "mode incval"/"minmax", since they affect the same internal parameters.

Each of your definitions triggers 7 CC messages each time you press the button.
In principle the first 3 messages (triggered by easypar) are superfluous in each case, since they are overridden by the last 4 (triggered by tx statements).
So if the easypar statements weren't necessary to keep the values of the two buttons synchronized, you could have left out the easypar statements altogether:

$rev R1 ; Firmware 1.10; BC Manager 2.3.1
$button 39
  .showvalue on
  .default 0
  .mode incval 1
  .minmax 0 20
  .tx $B0 $63 $00
  .tx $B0 $62 $2B
  .tx $B0 $06 $00
  .tx $B0 $26 val
$button 47
  .showvalue on
  .default 0
  .mode incval -1
  .minmax 0 20
  .tx $B0 $63 $00
  .tx $B0 $62 $2B
  .tx $B0 $06 $00
  .tx $B0 $26 val
$end

(The default value of 0 used for both buttons here means that if you press button 39 first, "val" is output as 1, whereas if you press 47 first, "val" is output as 20. You can of course tweak this to your liking.)

However, since you want to keep the two button values synchronized, you do need easypar statements.
But this means that you don't need any "mode incval" and "minmax" statements, provided you use the appropriate values in the "easypar" statement:

$rev R1 ; Firmware 1.10; BC Manager 2.3.1
$button 39
  .easypar NRPN 1 43 20 0 increment 1
  .showvalue on
  .default 0
  .tx $B0 $63 $00
  .tx $B0 $62 $2B
  .tx $B0 $06 $00
  .tx $B0 $26 val
$button 47
  .easypar NRPN 1 43 20 0 increment -1
  .showvalue on
  .default 0
  .tx $B0 $63 $00
  .tx $B0 $62 $2B
  .tx $B0 $06 $00
  .tx $B0 $26 val
$end

In fact, if I remember the NRPN protocol correctly, you can leave out the first two ".tx" statements: the NRPN number selected by the $63 and $62 messages generated by the easypar statement should still be valid (although you'd have to check if your receiving device actually supports this):

$rev R1 ; Firmware 1.10; BC Manager 2.3.1
$button 39
  .easypar NRPN 1 43 20 0 increment 1
  .showvalue on
  .default 0
  .tx $B0 $06 $00
  .tx $B0 $26 val
$button 47
  .easypar NRPN 1 43 20 0 increment -1
  .showvalue on
  .default 0
  .tx $B0 $06 $00
  .tx $B0 $26 val
$end

One thing that still bothers me is that the easypar statement causes the BCR to first send the button value as the MSB, so in theory the parameter on the receiving device jumps to an undesired value for a short time. (Actually this is another argument in favor of leaving out the first two tx statements, provided they are indeed superfluous.)

One way out of this problem might be to assign a completely unrelated NRPN number to the easypar statement - you'd only have to make sure that this number isn't picked up by the receiving device in any way. So you could put this message on a different (silent) MIDI channel. In fact, to bring down the number of superfluous messages you might be able to use a CC (or AT?!) definition instead of NRPN; I haven't checked whether this actually works, though.

> PS liked your PhD thesis. Now that I will have to re-read a few times
> because you put the math and music together and I get excited :-)

Thanks for the compliment!
At the time (1996) not everybody in the music-scientific world liked it, although for varying, contradictory reasons:
- "we already know all this [i.e. the tonal theory as presented in my dissertation], so it's pointless to formalize it"
- "the author [i.e. me] doesn't know what he's talking about"
- "this isn't scientific: it's all speculation"
Clearly, formalization of music (cognition) didn't/doesn't go down well with many people...

By the way, as stated on the Plans page of my web site, I'm currently working hard on a publishable new implementation of the computer program used in my dissertation. This will also allow me to correct some of the mis-aligned graphics in the dissertation's pdf version.

Anyway, back to BCF/BCR2000 matters...

Mark.