Bc2000 (for the BCF2000 & BCR2000) group photo

Yahoo Groups archive

Bc2000 (for the BCF2000 & BCR2000)

Index last updated: 2026-04-28 23:16 UTC

Thread

BCR Sysex from DAW

BCR Sysex from DAW

2007-11-27 by rpcfender

Art, just starting a new thread.

>Royce,

>Just curious: on the Mac, how would you convert back to sysex from
>text format, in order to load back into the computer?

themaker4 is using BC convert so I assume there is a port to Mac.

Anyone know if this is correct?


I believe that there is a good PC emulator for the Mac, so you could run my editor.

Of course you could write a Mac program. The BC sysex format is in my editor info section as well as Mark's document.

Should I write a port to Java so everyone can use the editor?

Anyone non PC interested?


>On a completely different subject, do you know anything about how the
>BCR/BCF responds to incoming sysex messages from a DAW - such as
>changing the value of a dot display on an encoder?

The BC listens to incoming Midi message, but it seems only of the types that are found in the .easypar command CC PB etc (but this can be in a .tx command) , looks at the buttons and encoders and faders (I assume) to see if it can find a match in message type and channel and sets them to the incoming value.

It also does this internally thereby ganging the controls together.

Does this join 2 faders on the BCF?

$fader 1

.easypar CC 1 100 127 0 absolute

.showvalue off

.motor on

.override move

.keyoverride off

$fader 3

.easypar CC 1 100 127 0 absolute

.showvalue off

.motor on

.override move

.keyoverride off

As far as sysex messages, I am unaware of any BC sysex messages to control the encoders etc.

$encoder 1

.showvalue on

.minmax 0 127

.tx $F0 $43 $12 $00 val $F7

.default ; whatever you want to set the encoder

This repositions the encoder, but you have to send the whole list of commands otherwise the BC restores the default values.

It would be great if there was a sysex message to reposition the controls, but Live, Sonar and Cubase use CC as far as I know.

What sysex messages are you seeing from the DAW that is sent to the BC?

What is the DAW application?


All the best

Royce

Re: BCR Sysex from DAW

2007-11-27 by goyya76

> What sysex messages are you seeing from the DAW that is sent to the 
BC?
> 
> What is the DAW application?

hi Royce, getting into the thread (i asked some questions to Art who 
consequently started it!)

I'm using Cubase SX3 - when running Mackie Emulation, the DAW sends out 
CC48 to CC55, on channel 1, with a range of value depending on the 
led "graphical" behaviour: 1-11 single dot, 17-27 pan type (i'm at 
work, i'll post the other one when i'm back home, i don't remember). 
BTW, the BCR has 15 leds (MCU has 11), and i noticed that giving the 1-
11range on the bcr lights up the leds from 1 to 11 (clockwise), so the 
visual feedback is "asimmetrical" - the MCU emu implemented by 
Behringer instead lights up the leds from 3 to 13, with the correct 
visualization.

maybe it's possible to use the .easypar to implement the Mackie control 
and the .tx field to set up the feedback CC (or viceversa)? 
i'm going to try this evening, though i still have to learn about MIDI 
syntax and BC scripts, so results are not guaranteed...

las

Re: BCR Sysex from DAW

2007-11-27 by goyya76

Hi Royce,

as you were saying the BCR seems to respond only to CC set up 
in .easypar - i could put the relative Vpot message (eg for Vpot1 CC 16 
ch 1, range 0-127, relative-3) but i don't know how to writethe .tx 
string inserting a relative value (if it's possible, of course)...

ciao,

Francesco

Re: BCR Sysex from DAW

2007-11-27 by rpcfender

Hi Las

> I'm using Cubase SX3 - when running Mackie Emulation, the DAW sends out
> CC48 to CC55, on channel 1, with a range of value depending on the
> led "graphical" behaviour: 1-11 single dot, 17-27 pan type (i'm at
> work, i'll post the other one when i'm back home, i don't remember).

So no sysex then?

> BTW, the BCR has 15 leds (MCU has 11), and i noticed that giving the 1-
> 11range on the bcr lights up the leds from 1 to 11 (clockwise), so the
> visual feedback is "asimmetrical" - the MCU emu implemented by
> Behringer instead lights up the leds from 3 to 13, with the correct
> visualization.


You could use
.mode spread
At 1 the middle LED is on. As you turn the encoder the leds on either side light up and at 11 the whole thing is lit up
.mode qual
does the reverse

$encoder 1
.easypar CC 1 48 1 11 absolute
.mode spread
.showvalue on
.default 1

Not the best, but at least it is symmetric.

> maybe it's possible to use the .easypar to implement the Mackie control
> and the .tx field to set up the feedback CC (or viceversa)?

Check with midiox that the CC message is coming out of Cuebase
Check that the MIDI output device is set to the BCR


$encoder 1
.easypar CC 1 48 1 11 absolute
.mode spread
.showvalue on
.default 1

$encoder 2
.easypar CC 1 48 1 11 absolute
.mode spread
.showvalue on
.default 1

will run together so the feedback works internally
Curiously,

$encoder 3
.resolution 96 96 96 96
.mode spread
.showvalue on
.default 1
.minmax 1 11
.tx $B0 7 val

doesn't join them, and adding

$encoder 4
.resolution 96 96 96 96
.mode spread
.showvalue on
.default 1
.minmax 1 11
.tx $B0 7 val

3 and 4 are not linked. So perhaps the feed back only works for easypar.

All the best
Royce

Re: BCR Sysex from DAW

2007-11-28 by abhunkin

Francesco,

As Royce stated (way back on August 18 - message 533),

Art's
.easypar CC 1 16 0 127 relative-3
can be had with
.tx $B0 16 ifp 1 ifn $41

This is the.tx code I'm working with for your multiple VPot sysex - 
but incorporating multiple page/bank -/+ messages at the beginning of 
the .tx. The ifp/ifn options are wonderful with encoders.

Art Hunkins

--- In bc2000@yahoogroups.com, "goyya76" <goyya76@...> wrote:
>
> Hi Royce,
> 
> as you were saying the BCR seems to respond only to CC set up 
> in .easypar - i could put the relative Vpot message (eg for Vpot1 
CC 16
Show quoted textHide quoted text
> ch 1, range 0-127, relative-3) but i don't know how to writethe .tx 
> string inserting a relative value (if it's possible, of course)...
> 
> ciao,
> 
> Francesco
>

Re: [bc2000] Re: BCR Sysex from DAW

2007-11-28 by Francesco Cecconi

Hey i thought you were on holiday! thanks for your work - i thought the rel2s, reloffs etc should have been used to produce a relative controller - in the meantime:

-i noticed that the feedback messages for the Vpots are cc48-55, on channel 1, with the following values (linked to the graphical behaviour): 1-11 dot, 17-27 pan, 33-43 bar, 49-54 Q-style
- i tried too to add notes in the .tx field to route the messages to the correct pages and it works
- i'm having a look inside bcr 1.1firmware sysex...just to see if it's possible to recognize the strings related to MCU emulation (i'm not very optimistic) and especially the led beahviour (MCU has 11 leds, corrsponding to led 3-13 of the BCR) 

Take care, 
Francesco


----- Messaggio originale -----
Da: abhunkin <abhunkin@...>
A: bc2000@yahoogroups.com
Inviato: Mercoledì 28 novembre 2007, 18:37:25
Oggetto: [bc2000] Re: BCR Sysex from DAW

Francesco,

As Royce stated (way back on August 18 - message 533),

Art's
.easypar CC 1 16 0 127 relative-3
can be had with
.tx $B0 16 ifp 1 ifn $41

This is the.tx code I'm working with for your multiple VPot sysex - 
but incorporating multiple page/bank -/+ messages at the beginning of 
the .tx. The ifp/ifn options are wonderful with encoders.

Art Hunkins

--- In bc2000@yahoogroups. com, "goyya76" <goyya76@... > wrote:
>
> Hi Royce,
> 
> as you were saying the BCR seems to respond only to CC set up 
> in .easypar - i could put the relative Vpot message (eg for Vpot1 
CC 16 
> ch 1, range 0-127, relative-3) but i don't know how to writethe .tx 
> string inserting a relative value (if it's possible, of course)...
> 
> ciao,
> 
> Francesco
>





      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html

Re: [bc2000] Re: BCR Sysex from DAW

2007-11-29 by Art Hunkins

Francesco,

Please try the attached and see if it works. It is an "overlay" preset (MCU emulation) that doesn't initialize (change) anything except the 4 banks of VPot encoders. I've attached both sysex and script. I'm also trying a version that includes .tx for the bank change messages as well as .easypar for the encoder itself - so as hopefully to be able to handle LED feedback from the DAW.

In that regard, I wonder whether setting the .default encoder setting to 3 would work to get appropriate LED display, or would the action be more complicated or not possible at all? (Royce, any ideas on this?)

Art Hunkins
Show quoted textHide quoted text
  ----- Original Message ----- 
  From: Francesco Cecconi 
  To: bc2000@yahoogroups.com 
  Sent: Wednesday, November 28, 2007 1:42 PM
  Subject: Re: [bc2000] Re: BCR Sysex from DAW



  Hey i thought you were on holiday! thanks for your work - i thought the rel2s, reloffs etc should have been used to produce a relative controller - in the meantime:

  -i noticed that the feedback messages for the Vpots are cc48-55, on channel 1, with the following values (linked to the graphical behaviour): 1-11 dot, 17-27 pan, 33-43 bar, 49-54 Q-style
  - i tried too to add notes in the .tx field to route the messages to the correct pages and it works
  - i'm having a look inside bcr 1.1firmware sysex...just to see if it's possible to recognize the strings related to MCU emulation (i'm not very optimistic) and especially the led beahviour (MCU has 11 leds, corrsponding to led 3-13 of the BCR) 

  Take care, 
  Francesco


  ----- Messaggio originale -----
  Da: abhunkin <abhunkin@...>
  A: bc2000@yahoogroups.com
  Inviato: Mercoledì 28 novembre 2007, 18:37:25
  Oggetto: [bc2000] Re: BCR Sysex from DAW


  Francesco,

  As Royce stated (way back on August 18 - message 533),

  Art's
  .easypar CC 1 16 0 127 relative-3
  can be had with
  .tx $B0 16 ifp 1 ifn $41

  This is the.tx code I'm working with for your multiple VPot sysex - 
  but incorporating multiple page/bank -/+ messages at the beginning of 
  the .tx. The ifp/ifn options are wonderful with encoders.

  Art Hunkins

  --- In bc2000@yahoogroups. com, "goyya76" <goyya76@... > wrote:
  >
  > Hi Royce,
  > 
  > as you were saying the BCR seems to respond only to CC set up 
  > in ..easypar - i could put the relative Vpot message (eg for Vpot1 
  CC 16 
  > ch 1, range 0-127, relative-3) but i don't know how to writethe .tx 
  > string inserting a relative value (if it's possible, of course)...
  > 
  > ciao,
  > 
  > Francesco
  >







------------------------------------------------------------------------------

------------------------------------------------------------------------------
  L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail

Re: [bc2000] Re: BCR Sysex from DAW

2007-11-29 by Art Hunkins

Francesco (and Royce) -

Attached are script and sysex followup files to my previous post. (Incidentally these presets are designed to make 4 banks of VPots on the BCR with *any* DAW that implements the MCU as a control surface.) 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).

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?)

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)? 

Thanks to both of you -

Art Hunkins

--- In bc2000@yahoogroups.com, Francesco Cecconi <goyya76@...> wrote:
>
> Hey i thought you were on holiday! thanks for your work - i thought the rel2s, reloffs etc should have been used to produce a relative controller - in the meantime:
> 
> -i noticed that the feedback messages for the Vpots are cc48-55, on channel 1, with the following values (linked to the graphical behaviour): 1-11 dot, 17-27 pan, 33-43 bar, 49-54 Q-style
> - i tried too to add notes in the .tx field to route the messages to the correct pages and it works
> - i'm having a look inside bcr 1.1firmware sysex...just to see if it's possible to recognize the strings related to MCU emulation (i'm not very optimistic) and especially the led beahviour (MCU has 11 leds, corrsponding to led 3-13 of the BCR) 
> 
> Take care, 
> Francesco
> 
> 
> ----- Messaggio originale -----
> Da: abhunkin <abhunkin@...>
> A: bc2000@yahoogroups.com
> Inviato: Mercoledì 28 novembre 2007, 18:37:25
> Oggetto: [bc2000] Re: BCR Sysex from DAW
> 
> Francesco,
> 
> As Royce stated (way back on August 18 - message 533),
> 
> Art's
> .easypar CC 1 16 0 127 relative-3
> can be had with
> .tx $B0 16 ifp 1 ifn $41
> 
> This is the.tx code I'm working with for your multiple VPot sysex - 
> but incorporating multiple page/bank -/+ messages at the beginning of 
> the .tx. The ifp/ifn options are wonderful with encoders.
> 
> Art Hunkins
> 
> --- In bc2000@yahoogroups. com, "goyya76" <goyya76@ > wrote:
> >
> > Hi Royce,
> > 
> > as you were saying the BCR seems to respond only to CC set up 
> > in .easypar - i could put the relative Vpot message (eg for Vpot1 
> CC 16 
> > ch 1, range 0-127, relative-3) but i don't know how to writethe .tx 
> > string inserting a relative value (if it's possible, of course)...
> > 
> > ciao,
> > 
> > Francesco
> >
> 
> 
> 
> 
> 
>       ___________________________________ 
> L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html
>
Show quoted textHide quoted text
  ----- Original Message ----- 
  From: Francesco Cecconi 
  To: bc2000@yahoogroups.com 
  Sent: Wednesday, November 28, 2007 1:42 PM
  Subject: Re: [bc2000] Re: BCR Sysex from DAW



  Hey i thought you were on holiday! thanks for your work - i thought the rel2s, reloffs etc should have been used to produce a relative controller - in the meantime:

  -i noticed that the feedback messages for the Vpots are cc48-55, on channel 1, with the following values (linked to the graphical behaviour): 1-11 dot, 17-27 pan, 33-43 bar, 49-54 Q-style
  - i tried too to add notes in the .tx field to route the messages to the correct pages and it works
  - i'm having a look inside bcr 1.1firmware sysex...just to see if it's possible to recognize the strings related to MCU emulation (i'm not very optimistic) and especially the led beahviour (MCU has 11 leds, corrsponding to led 3-13 of the BCR) 

  Take care, 
  Francesco


  ----- Messaggio originale -----
  Da: abhunkin <abhunkin@...>
  A: bc2000@yahoogroups.com
  Inviato: Mercoledì 28 novembre 2007, 18:37:25
  Oggetto: [bc2000] Re: BCR Sysex from DAW


  Francesco,

  As Royce stated (way back on August 18 - message 533),

  Art's
  .easypar CC 1 16 0 127 relative-3
  can be had with
  .tx $B0 16 ifp 1 ifn $41

  This is the.tx code I'm working with for your multiple VPot sysex - 
  but incorporating multiple page/bank -/+ messages at the beginning of 
  the .tx. The ifp/ifn options are wonderful with encoders.

  Art Hunkins

  --- In bc2000@yahoogroups. com, "goyya76" <goyya76@... > wrote:
  >
  > Hi Royce,
  > 
  > as you were saying the BCR seems to respond only to CC set up 
  > in ..easypar - i could put the relative Vpot message (eg for Vpot1 
  CC 16 
  > ch 1, range 0-127, relative-3) but i don't know how to writethe .tx 
  > string inserting a relative value (if it's possible, of course)...
  > 
  > ciao,
  > 
  > Francesco
  >







------------------------------------------------------------------------------

------------------------------------------------------------------------------
  L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail

Re: [bc2000] Re: BCR Sysex from DAW

2007-11-29 by Francesco Cecconi

Hi Art,

after an hour of trials i realized one thing: adding the page+/- notes does not work (incidentally, the page +/- seems to be note 40/41), just because the note message is sent each time an increment is sent....so for example a turn with 6 increments sends 6 "page+" note message  - if the plugin has 3 pages, the 4,5,6 note message does nothin, but the result is that the vpots are always "routed" to the last page....(see also Royce's ScretBC.pdf, when he talks about assigning a note to an encoder via .tx obtaining a  roll for a drum)
We would need the possibility to insert in the .tx field a "one shot" message, but i guess it's impossible...

Regarding the feedback messages, my feeling is that it's impossible to get the correct feedback, since:

1) the encoders seems to get feedback only with .easypar - even setting the correct CC in .easypar, there's still the problem of the range! a possible workaround is processing the output of the daw transforming it to a value in the range 1-127: eg, 1-11-->subtract 1 and multiply by 12.7 - i tried with cubase midi fx and it works (of course the math operation depends on the original range), i guess MIDIox can do the same...Otherwise, one could try to use val, val0.6 etc combinations for the note number and/or channel, in such a way that the first value sent is 41/ch1, the following are "nonsens" for the DAW (changing the channel should work), but i think it takes a lot of time

2) when changing page, the feedback message is always cc48-55, channel1 so eg encoder 1,33,41 and 49 would get the same position...

that said, i feel that a pseudo-C4 it's pretty difficult (if not impossible) to emulate...
Switching back to MCU emu, .tx with notes and cc work - for example, in cubase encoder 1-8 (in BCR own MCU mode) are linked
 to selected track send 1-8:

enc1 easypar: cc16 ch1 relative->track1, send1
enc2 easypar: cc17 ch1 relative->track1, send2
enc3 easypar: cc18 ch1 relative->track1, send3
...

but you can do:

enc1 tx: note 24, cc 16 ch1 relative->track1, send1
enc2 tx: note 25, cc 16 ch1 relative->track2, send1
enc3 tx: note 26, cc 16 ch1 relative->track3, send1
...

----- Messaggio originale -----
Da: Art Hunkins <abhunkin@...>
A: bc2000@yahoogroups.com
Inviato: Giovedì 29 novembre 2007, 17:02:34
Oggetto: Re: [bc2000] Re: BCR Sysex from DAW


 
Francesco,
 
Please try the attached and see if it works. It is an "overlay" preset (MCU emulation) that doesn't initialize (change) anything except the 4 banks of VPot encoders. I've attached both sysex and script. I'm also trying a version that includes .tx for the bank change messages as well as .easypar for the encoder itself - so as hopefully to be able to handle LED feedback from the DAW.
 
In that regard, I wonder whether setting the .default encoder setting to 3 would work to get appropriate LED display, or would the action be more complicated or not possible at all? (Royce, any ideas on this?)
 
Art Hunkins
Show quoted textHide quoted text
----- Original Message ----- 
From: Francesco Cecconi 
To: bc2000@yahoogroups. com 
Sent: Wednesday, November 28, 2007 1:42 PM
Subject: Re: [bc2000] Re: BCR Sysex from DAW


Hey i thought you were on holiday! thanks for your work - i thought the rel2s, reloffs etc should have been used to produce a relative controller - in the meantime:
 
-i noticed that the feedback messages for the Vpots are cc48-55, on channel 1, with the following values (linked to the graphical behaviour): 1-11 dot, 17-27 pan, 33-43 bar, 49-54 Q-style
- i tried too to add notes in the .tx field to route the messages to the correct pages and it works
- i'm having a look inside bcr 1.1firmware sysex...just to see if it's possible to recognize the strings related to MCU emulation (i'm not very optimistic) and especially the led beahviour (MCU has 11 leds, corrsponding to led 3-13 of the BCR) 
 
Take care, 
Francesco


----- Messaggio originale -----
Da: abhunkin <abhunkin@uncg. edu>
A: bc2000@yahoogroups. com
Inviato: Mercoledì 28 novembre 2007, 18:37:25
Oggetto: [bc2000] Re: BCR Sysex from DAW


Francesco,

As Royce stated (way back on August 18 - message 533),

Art's
.easypar CC 1 16 0 127 relative-3
can be had with
.tx $B0 16 ifp 1 ifn $41

This is the.tx code I'm working with for your multiple VPot sysex - 
but incorporating multiple page/bank -/+ messages at the beginning of 
the .tx. The ifp/ifn options are wonderful with encoders.

Art Hunkins

--- In bc2000@yahoogroups. com, "goyya76" <goyya76@... > wrote:
>
> Hi Royce,
> 
> as you were saying the BCR seems to respond only to CC set up 
> in ..easypar - i could put the relative Vpot message (eg for Vpot1 
CC 16 
> ch 1, range 0-127, relative-3) but i don't know how to writethe .tx 
> string inserting a relative value (if it's possible, of course)...
> 
> ciao,
> 
> Francesco
>









L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail 



      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html

Re: [bc2000] Re: BCR Sysex from DAW

2007-11-30 by Art Hunkins

Hello, Francesco,

I'm not sure I follow everything you've said, but I still have hope.

Please try the attached variant of my original basic "Overlay" preset - the one with all .tx (no .easypar) and no attempt to deal with the LED's.

The only change from the original is that the page -/+ messages are now notes 40 ands 41. I had them (as you probably guessed) as notes 46 and 47 - *Fader Bank* -/+. I had thought them the same, and used 46 and 47 because they are common to (nearly?) all DAW's. Unfortunately, page -/+ is DAW-specific - 40 and 41 in Cubase. So be it.

Please recall that OverlayA (attached), for *each* encoder move, sends 3 page back messages followed by the appropriate (0-3) page forward messages, then the encoder (VPot) increment/decrement. It doesn't send just 0-3 page forward messages then the increment/decrement.

I'm looking forward to hearing from you.

Art Hunkins
Show quoted textHide quoted text
  ----- Original Message ----- 
  From: Francesco Cecconi 
  To: bc2000@yahoogroups.com 
  Sent: Thursday, November 29, 2007 5:40 PM
  Subject: Re: [bc2000] Re: BCR Sysex from DAW



  Hi Art,

  after an hour of trials i realized one thing: adding the page+/- notes does not work (incidentally, the page +/- seems to be note 40/41), just because the note message is sent each time an increment is sent....so for example a turn with 6 increments sends 6 "page+" note message  - if the plugin has 3 pages, the 4,5,6 note message does nothin, but the result is that the vpots are always "routed" to the last page....(see also Royce's ScretBC.pdf, when he talks about assigning a note to an encoder via .tx obtaining a  roll for a drum)
  We would need the possibility to insert in the .tx field a "one shot" message, but i guess it's impossible...

  Regarding the feedback messages, my feeling is that it's impossible to get the correct feedback, since:

  1) the encoders seems to get feedback only with .easypar - even setting the correct CC in .easypar, there's still the problem of the range! a possible workaround is processing the output of the daw transforming it to a value in the range 1-127: eg, 1-11-->subtract 1 and multiply by 12.7 - i tried with cubase midi fx and it works (of course the math operation depends on the original range), i guess MIDIox can do the same...Otherwise, one could try to use val, val0.6 etc combinations for the note number and/or channel, in such a way that the first value sent is 41/ch1, the following are "nonsens" for the DAW (changing the channel should work), but i think it takes a lot of time

  2) when changing page, the feedback message is always cc48-55, channel1 so eg encoder 1,33,41 and 49 would get the same position...

  that said, i feel that a pseudo-C4 it's pretty difficult (if not impossible) to emulate...
  Switching back to MCU emu, .tx with notes and cc work - for example, in cubase encoder 1-8 (in BCR own MCU mode) are linked
   to selected track send 1-8:

  enc1 easypar: cc16 ch1 relative->track1, send1
  enc2 easypar: cc17 ch1 relative->track1, send2
  enc3 easypar: cc18 ch1 relative->track1, send3
  ...

  but you can do:

  enc1 tx: note 24, cc 16 ch1 relative->track1, send1
  enc2 tx: note 25, cc 16 ch1 relative->track2, send1
  enc3 tx: note 26, cc 16 ch1 relative->track3, send1
  ...

  ----- Messaggio originale -----
  Da: Art Hunkins <abhunkin@...>
  A: bc2000@yahoogroups.com
  Inviato: Giovedì 29 novembre 2007, 17:02:34
  Oggetto: Re: [bc2000] Re: BCR Sysex from DAW


   

  Francesco,

  Please try the attached and see if it works. It is an "overlay" preset (MCU emulation) that doesn't initialize (change) anything except the 4 banks of VPot encoders. I've attached both sysex and script. I'm also trying a version that includes .tx for the bank change messages as well as .easypar for the encoder itself - so as hopefully to be able to handle LED feedback from the DAW.

  In that regard, I wonder whether setting the .default encoder setting to 3 would work to get appropriate LED display, or would the action be more complicated or not possible at all? (Royce, any ideas on this?)

  Art Hunkins

    ----- Original Message ----- 
    From: Francesco Cecconi 
    To: bc2000@yahoogroups. com 
    Sent: Wednesday, November 28, 2007 1:42 PM
    Subject: Re: [bc2000] Re: BCR Sysex from DAW



    Hey i thought you were on holiday! thanks for your work - i thought the rel2s, reloffs etc should have been used to produce a relative controller - in the meantime:

    -i noticed that the feedback messages for the Vpots are cc48-55, on channel 1, with the following values (linked to the graphical behaviour): 1-11 dot, 17-27 pan, 33-43 bar, 49-54 Q-style
    - i tried too to add notes in the .tx field to route the messages to the correct pages and it works
    - i'm having a look inside bcr 1.1firmware sysex...just to see if it's possible to recognize the strings related to MCU emulation (i'm not very optimistic) and especially the led beahviour (MCU has 11 leds, corrsponding to led 3-13 of the BCR) 

    Take care, 
    Francesco


    ----- Messaggio originale -----
    Da: abhunkin <abhunkin@uncg. edu>
    A: bc2000@yahoogroups. com
    Inviato: Mercoledì 28 novembre 2007, 18:37:25
    Oggetto: [bc2000] Re: BCR Sysex from DAW


    Francesco,

    As Royce stated (way back on August 18 - message 533),

    Art's
    .easypar CC 1 16 0 127 relative-3
    can be had with
    .tx $B0 16 ifp 1 ifn $41

    This is the.tx code I'm working with for your multiple VPot sysex - 
    but incorporating multiple page/bank -/+ messages at the beginning of 
    the .tx. The ifp/ifn options are wonderful with encoders.

    Art Hunkins

    --- In bc2000@yahoogroups. com, "goyya76" <goyya76@... > wrote:
    >
    > Hi Royce,
    > 
    > as you were saying the BCR seems to respond only to CC set up 
    > in ..easypar - i could put the relative Vpot message (eg for Vpot1 
    CC 16 
    > ch 1, range 0-127, relative-3) but i don't know how to writethe .tx 
    > string inserting a relative value (if it's possible, of course)...
    > 
    > ciao,
    > 
    > Francesco
    >







----------------------------------------------------------------------------

----------------------------------------------------------------------------
    L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail 





------------------------------------------------------------------------------

------------------------------------------------------------------------------
  L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail

Re: BCR Sysex from DAW

2007-11-30 by rpcfender

Art

> In that regard, I wonder whether setting the .default encoder setting to 3 would work to get appropriate LED display, or would the action be more complicated or not possible at all? (Royce, any ideas on this?)

The only thing .default does is set the starting point in the preset memory at power up, or, if you have just sent the sysex, the control in edit buffer will go to this value. The LEDs just follow along.

In the conventional display modes the LEDs always start at the bottom leftmost
$encoder 1
.easypar CC 1 48 1 11 absolute
.mode 1dot
.showvalue on
.default 1

even if the numbers are going backwards
.easypar CC 1 48 11 1 absolute

I can't see a way around this except for
.mode spread
When it starts at the center and grows outward.

OR

You need at least 15 values to light all the LEDs.
If the program ignores any value it doesn't understand eg if the software's range of interest is 1 to 11 and it ignores 0 and 12 to 127 you could use this...
128 = 0 in the lower 7bits so
129 = 1 and
139 = 11
129 - 2 for the min and 139 + 2 for the max
$encoder 1
.mode 1dot
.showvalue on
.default 1
.resolution 96 96 96 96
.minmax 126 141
.tx $B0 48 val

with the last 2 LEDs on either side as min and max but redundant
$B0 $30 $7F LED 1
$B0 $30 $00 ; LED 2
$B0 $30 $01 LED 3 the real start
$B0 $30 $02
.
.
$B0 $30 $09
$B0 $30 $0A
$B0 $30 $0B
$B0 $30 $0C LED 13 the real end
$B0 $30 $0D LED 14
$B0 $30 $0E LED 15



Royce

Re: BCR Sysex from DAW

2007-11-30 by rpcfender

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

Re: BCR Sysex from DAW

2007-11-30 by abhunkin

Royce -

So, for an encoder in relative-3 mode, if you want a range of 1-12, 
with a .default = 1, you could specify .resolution = 12, and values 
would increment through 12 equally over one full knob rotation?

And also, the LED's would light up (in 1-dot mode) progressively 
throughout the rotation?

Finally, would any of this be different whether .easypar or .tx were 
used? (For now - and perhaps forever - we leave aside the issue of 
LED feedback from the DAW.)

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
Show quoted textHide quoted text
> duplicate MIDI messages.
> 
> All the best
> 
> Royce
>

Re: BCR Sysex from DAW

2007-11-30 by abhunkin

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
Show quoted textHide quoted text
> duplicate MIDI messages.
> 
> All the best
> 
> Royce
>

Re: BCR Sysex from DAW

2007-11-30 by rpcfender

Art

> So, for an encoder in relative-3 mode, if you want a range of 1-12,
> with a .default = 1, you could specify .resolution = 12, and values
> would increment through 12 equally over one full knob rotation?

Yes .resolution 12 = resolution 12 12 12 12

> And also, the LED's would light up (in 1-dot mode) progressively
> throughout the rotation?

But only 12 of them and the rotation would not match the LEDmovement
The LED spacing is roughly 360/16 = 22.5 degrees
So the resolution might be better at .resolution 16 to match the LED movement

> Finally, would any of this be different whether .easypar or .tx were
> used? (For now - and perhaps forever - we leave aside the issue of
> LED feedback from the DAW.)

If it is just the same MIDI message then no.
You can overwrite aspects of easypar anyway.
The range, for example, can be overwritten by using .minmax and so you can get signed values even in.easypar


All the best

Royce

Re: BCR Sysex from DAW

2007-12-01 by rpcfender

> Could you possibly try the following BCR script for me? (I'm going a
> bit batty.)
>
> $rev R1
> $preset
> .name '32 MCU VPots '

these are all defaults so you don't need them

> .snapshot off
> .request off
> .egroups 4
> .fkeys on
> .lock off

just this
> .init
>

$rev R1
$preset
.name '32 MCU VPots '
.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.)

$rev R1
$encoder 1
.easypar CC 1 7 0 127 absolute
.mode 1-dot
$end

is a perfectly good and complete BC sysex.
There are somethings you need to send otherwise they are reset though. See Mark's guide for this info.
So you can leave out any $ section
$global
$preset
$encoder x
$button x
$fader x

The $preset stuff applies to all controllers. It is executed in the order it is received in the sysex.
So .init clears everything, then you set up just the controllers you want. All others remain cleared.
If you don't use it it doesn't clear them and you can just change the parameters you want to.

If you send
$preset
.name 'Royce's '

You will just change the name, but if you ask the BC to send back the preset you will get the init, even though it didn't init the preset when you sent it.
This is unlike the other $preset commands that will be reset and their new values will be effective in the buffer.
It is a bit confusing.

> 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).
>
Yours .tx $F0 144 46 127 144 46 127 144 46 127 $B0 16 ifp 1 ifn 65 $F7
Where is the ending $F7 if you turn it to the positive

.tx $F0 144 46 127 144 46 127 144 46 127 $B0 16 1 $F7 if positive
.tx $F0 144 46 127 144 46 127 144 46 127 $B0 16 65 $F7 if negative
You need
.tx $F0 144 46 127 144 46 127 144 46 127 $B0 16 ifp 1 $F7 ifn 65 $F7
when using ifp and ifn you need to complete the meesage.

You can have multiple ifp ifn 's
.tx $F0 144 46 127 144 46 127 144 46 127 $B0 16 ifp 1 ifn 65 $F7 ifp$F7
also works

Royce

Re: [bc2000] Re: BCR Sysex from DAW

2007-12-02 by Art Hunkins

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.
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
$end
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.)
Example:
$rev R1
$encoder 1
.minmax 0 10
.resolution 96
.tx 144 44 127
.easypar CC 1 16 0 10 relative-3
$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.
Art Hunkins
Show quoted textHide quoted text
----- Original Message -----
From: rpcfender
Sent: Friday, November 30, 2007 7:48 PM
Subject: [bc2000] Re: BCR Sysex from DAW

> Could you possibly try the following BCR script for me? (I'm going a
> bit batty.)
>
> $rev R1
> $preset
> .name '32 MCU VPots '

these are all defaults so you don't need them

> .snapshot off
> .request off
> .egroups 4
> .fkeys on
> .lock off

just this
> .init
>

$rev R1
$preset
.name '32 MCU VPots '
.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.)

$rev R1
$encoder 1
.easypar CC 1 7 0 127 absolute
.mode 1-dot
$end

is a perfectly good and complete BC sysex.
There are somethings you need to send otherwise they are reset though. See Mark's guide for this info.
So you can leave out any $ section
$global
$preset
$encoder x
$button x
$fader x

The $preset stuff applies to all controllers. It is executed in the order it is received in the sysex.
So .init clears everything, then you set up just the controllers you want. All others remain cleared.
If you don't use it it doesn't clear them and you can just change the parameters you want to.

If you send
$preset
.name 'Royce's '

You will just change the name, but if you ask the BC to send back the preset you will get the init, even though it didn't init the preset when you sent it.
This is unlike the other $preset commands that will be reset and their new values will be effective in the buffer.
It is a bit confusing.

> 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).
>
Yours .tx $F0 144 46 127 144 46 127 144 46 127 $B0 16 ifp 1 ifn 65 $F7
Where is the ending $F7 if you turn it to the positive

.tx $F0 144 46 127 144 46 127 144 46 127 $B0 16 1 $F7 if positive
.tx $F0 144 46 127 144 46 127 144 46 127 $B0 16 65 $F7 if negative
You need
.tx $F0 144 46 127 144 46 127 144 46 127 $B0 16 ifp 1 $F7 ifn 65 $F7
when using ifp and ifn you need to complete the meesage.

You can have multiple ifp ifn 's
.tx $F0 144 46 127 144 46 127 144 46 127 $B0 16 ifp 1 ifn 65 $F7 ifp$F7
also works

Royce

Re: BCR Sysex from DAW

2007-12-02 by rpcfender

Art

--- 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 val 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
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
.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

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
Show quoted textHide quoted text
----- Original Message -----
From: rpcfender
Sent: Sunday, December 02, 2007 7:06 AM
Subject: [bc2000] Re: BCR Sysex from DAW

Art

--- 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

Re: BCR Sysex from DAW

2007-12-03 by rpcfender

Hi Art
> 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.

Woops. This is why it is good to say what messages you are trying to output at the start.

You only need the sysex bytes if you are sending sysex.
Midi Note on is not sysex

So the error is not the Midi note on ($90) but the sysex header. Boy, did I miss that one. Sorry Art.

$90 43 120 note on
$80 43 120 note off
$B0 43 120 CC
etc
all channel 1

$F0 43 12 67 ....... 22 $F7 sysex

>
> 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).
>

The format for tx is

.tx Midi message (another Midi message) (another Midi message) (another Midi message) etc
as long as the sum of the Midi messages is less than 125 bytes
The Midi message can be any legitimate Midi message you want

$F0 $41 $10 $00 $6B $12 $10 $00 $20 $1E value checksum $F7 FantomX reverb setting channel 1
$B0 $07 value volume on channel 1

Increase the volume and reverb at the same time
.tx $B0 $07 val $F0 $41 $10 $00 $6B $12 $10 $00 $20 $1E val cks-1 $F7

Note that the BC ignores white space so this is OK with the gaps


What is the message you want to send when you turn it clockwise?
What is the message you want to send when you turn it anticlockwise?


Royce

Re: [bc2000] Re: BCR Sysex from DAW

2007-12-03 by Art Hunkins

Once again, thanks for the great info/response, Royce.
Actually, I'm having no trouble sending multiple MIDI messages with .tx; I was just confused about the $F0/$F7 frame. Frankly, I had (wrongly) considered everything sent via .tx as "sysex". (I've never strictly sent sysex; never needed to.)
I'd suggest adding to the docs somewhere: ".tx can send one or mote standard MIDI messages, and/or sysex in the same data stream. Only the latter is enclosed with the sysex frame $F0 and $F7."
Regarding .easypar and .tx in the same module, I'd suggest a statement somewhat like this: "In a given module that includes both .easypar and .tx, .easypar must come first. Also be aware that .easypar resets a number of parameters, including .showvalue and .mode to off - meaning you'll get absolutely no visual display unless you specify these parameters *after* .easypar. With *only* .tx in a module, statement order is unimportant, as .tx doesn't reset anything."
Art Hunkins
Show quoted textHide quoted text
----- Original Message -----
From: rpcfender
Sent: Monday, December 03, 2007 12:59 AM
Subject: [bc2000] Re: BCR Sysex from DAW

Hi Art
> 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.

Woops. This is why it is good to say what messages you are trying to output at the start.

You only need the sysex bytes if you are sending sysex.
Midi Note on is not sysex

So the error is not the Midi note on ($90) but the sysex header. Boy, did I miss that one. Sorry Art.

$90 43 120 ; note on
$80 43 120 note off
$B0 43 120 ; CC
etc
all channel 1

$F0 43 12 67 ....... 22 $F7 sysex

>
> 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).
>

The format for tx is

.tx Midi message (another Midi message) (another Midi message) (another Midi message) etc
as long as the sum of the Midi messages is less than 125 bytes
The Midi message can be any legitimate Midi message you want

$F0 $41 $10 $00 $6B $12 $10 $00 $20 $1E value checksum $F7 FantomX reverb setting channel 1
$B0 $07 value volume on channel 1

Increase the volume and reverb at the same time
.tx $B0 $07 val $F0 $41 $10 $00 $6B $12 $10 $00 $20 $1E val cks-1 $F7

Note that the BC ignores white space so this is OK with the gaps


What is the message you want to send when you turn it clockwise?
What is the message you want to send when you turn it anticlockwise?


Royce

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.