----- Original Message -----From: rpcfenderSent: Sunday, December 02, 2007 7:06 AMSubject: [bc2000] Re: BCR Sysex from DAWArt
--- In bc2000@yahoogroups.com, "Art Hunkins" wrote:
>
> After spending much time working in Royce's editor, especially with encoders and .easypar/.tx, I've the following observations:
>
> (Please note: the following apply to *encoders* - I'm not sure to what else.)
>
> 1) To use .tx, both .minmax *and .resolution* are required.
True, as the init defaults set these to 0
> 2) With .tx, the framing $F0 and $F7 should not be used. If you do, a spurious additional message is added (in my case the .tx sends a note, and the additional note 247 ($F7!) is sent - with the weirdest looking timestamp you've ever seen).
>
> Example:
>
> $rev R1
> $encoder 1
> .minmax 0 10
> .resolution 96
> .tx $F0 144 46 127 $F7
Sorry Art, I missed another error in your sysex, as I was rushing out the door for a weekend away.
144 > 127 and 127 is the max MIDI data value
144 = $90 which is note on channel 1
You do, in fact, need the sysex to be wrapped in $F0 and $F7
> 3) .easypar and .tx can only be used in the same encoder *if .easypar comes first*. The following example does not work (only .easypar executes), but if you switch the order, the example works fine. Unfortunately, I need the order below; so my solution is to put everything inside .tx. (Again, unfortunately - as doing so rules out the possibility of .easypar responding to LED change messages from a DAW.)
Sadly true
The BC script works on "the last command in is the one we go with" basis
eg
$encoder 1
.easypar CC 1 7 0 127 absolute
.easypar CC 1 8 0 127 absolute
.easypar CC 1 9 0 127 absolute
.easypar CC 1 10 0 127 absolute
The BC is OK with this, it just keeps resetting to the last message ($B0 $0A v al is output)
That is why it is so surprising that you can have easypar and tx in the one control.
easypar and tx seem to have separate areas in preset memory.
Unlike .minmax.
$encoder 1
.easypar CC 1 7 0 127 absolute
.minmax 10 20
this resets the minmax value in the easypar (0 to 127) to the .minmax statement (10 to 20) but
$encoder 1
.minmax 10 20
.easypar CC 1 7 0 127 absolute
minmax value is set to the values in easypar (0 127)
>
> Example:
>
> $rev R1
> $encoder 1
> .minmax 0 10 note that minmax will be overwritten by the easypar following
> .resolution 96
> .tx 144 44 127
> .easypar CC 1 16 0 10 relative-3 as soon as you put easypar in everything else is canceled
& nbsp; easypar must go first
> $end
>
> 4) A general comment: It is unclear from documentation (including Royce's superb Secrets .pdf) what the defaults are, and how they relate to .init. I'm particularly talking about absent parameters within specified encoders, buttons, etc. To "play it safe", must you always declare all parameters within any button, encoder, etc., you program? This info could save a lot of potential typing. A clear statement on defaults as they relate to .init, and carried-over values when .init is lacking, would be most helpful.
if you send
$encoder 1
.showvalue off
you get back
$encoder 1
.showvalue off
.mode off
.resolution 0 0 0 0
.minmax 0 0
If you send
$encoder 1
&nb sp;.mode 1dot
we get back
$encoder 1
.showvalue off
.mode 1dot
.resolution 0 0 0 0
.minmax 0 0
so the defaults for encoder init seem to be
.showvalue off
.mode off
.resolution 0 0 0 0
.minmax 0 0
No message, so nothing is sent when you turn the control and the display is off.
curiously if you send this message back you get an error. It doesn't like
.resolution 0 0 0 0
What happens when you send easypar?
.easypar CC 1 7 0 127 absolute
sets
resolution 96
.default the min value, 0 in this case
.mode off
.showvalue off
We already know about minmax and like minmax, if you put, for example,
$encoder 1
.minmax 10 20
.resolution 10 20 30 40
.mode 1dot
.showvalue on
.easypar CC 1 7 0 127 absolute
it is the same as
$encoder 1
.easypar CC 1 7 0 127 absolute
is effectively the same as
$encoder 1
.minmax 0 127
.resolution 96 96 96 96
.mode off
.showvalue off
.tx $B0 $07 val
clearly not what you wanted at all !
Except for the display settings (and I don't know for sure about .local), everything can be set in easypar
$encoder 1
.easypar CC 1 7 0 127 absolute
.mode 1dot
.showvalue on
Order is important when dealing with easypar as it resets so many things including whether or not to use .tx values
Note there is no restriction to 7 bit numbers in easypar (except from the BC front panel)
$encoder 1
.easypar CC 1 7 254 260 absolute
.default 256
.mode 1dot
.showvalue on
use default to override default = min in easypar
All the best
Royce
Message
Re: [bc2000] Re: BCR Sysex from DAW
2007-12-03 by Art Hunkins
Thanks, Royce, for all the excellent, detailed info
regarding .easypar and .tx. I do hope you'll find time to incorporate it into
your BCSecrets.pdf, and perhaps also into your BCRSeditor help. I'd particular
recommend three groupings: 1) default values and when they are invoked; 2)
.easypar - its placement and effect on other variables; 3) the interaction
between .easypar and .tx.
With regard to wrapping .tx with $F0 and $F7. I'm
still going with my observation that if included they lead to a spurious MIDI
message error. Without $F0/$F7, my script does as I expect - which is to send a
MIDI note 46 message at 127 velocity. (This is an Ableton Live MCU emulation
command that = page minus.) So this is indeed a valid MIDI message, and is shown
in MIDIOx as being sent properly when encoder 1 is turned.
I'd ask you to actually run this on your BCR, both
with and without $F0/$F7, and see what you get. Incidentally, I obtain the
same result with multi-message .tx's, including those concluding with an ifn/ifp
sequence (again requiring no F7's at all).
One other thing: documentation seems to vacillate
between including $F0/$F7 in .tx, and not including it. This is confusing. An
example of its not being included is the final example in your mail
(below).
Take care, and again thanks for all your help
-
Art Hunkins