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

Translating Midi Ox "snapshots" to .tx format

Translating Midi Ox "snapshots" to .tx format

2008-04-24 by poser_p

Hello, I'm new to this list. I want to do something that I presume is
fairly easy to do, but I want to check before I spend a few hours trying. 

I use an m-audio Keystation Pro 88 to control my Kurzweil K2000. The
KSP 88 will send "snapshots" of current controller settings that I can
capture and store via Midi Ox. These can be transmitted back to the
K2000 and act as a sort of "patch" recall for my "synth" programs that
I'm making for the K2000. What I'd like to do is assign a snapshot to
a button on the BCR so that I can use it to store these "patches"
outside of the computer. 

I'm pretty sure the "snapshots" will fit into the 125 byte limit for a
.tx message -- there are around 50 controllers on the KSP 88, so if I
put one per line then I should only have 50 or so lines. What'd be
really slick is if there were some sort of file converter (I'm a
programmer by profession, so I could write one if it doesn't exist
yet) that would take a Midi Ox "snapshot" file and translate it into a
.tx format file. I believe that I can also output those snapshots as
raw MIDI, so maybe a converter isn't needed.

Re: Translating Midi Ox "snapshots" to .tx format

2008-04-24 by poser_p

...Adding, the BCR can generate snapshots itself. Could these be
assigned to the BCR's buttons which, when pressed, would cause the
BCR's rotary controllers to assume the values in the snapshot assigned
to the button? Combining the BCR assignments and the KSP assignments
in a single "preset" would be beyond cool...
 

--- In bc2000@yahoogroups.com, "poser_p" <poserp@...> wrote:
>
> Hello, I'm new to this list. I want to do something that I presume is
> fairly easy to do, but I want to check before I spend a few hours
trying. 
Show quoted textHide quoted text
> 
> I use an m-audio Keystation Pro 88 to control my Kurzweil K2000. The
> KSP 88 will send "snapshots" of current controller settings that I can
> capture and store via Midi Ox. These can be transmitted back to the
> K2000 and act as a sort of "patch" recall for my "synth" programs that
> I'm making for the K2000. What I'd like to do is assign a snapshot to
> a button on the BCR so that I can use it to store these "patches"
> outside of the computer. 
> 
> I'm pretty sure the "snapshots" will fit into the 125 byte limit for a
> .tx message -- there are around 50 controllers on the KSP 88, so if I
> put one per line then I should only have 50 or so lines. What'd be
> really slick is if there were some sort of file converter (I'm a
> programmer by profession, so I could write one if it doesn't exist
> yet) that would take a Midi Ox "snapshot" file and translate it into a
> .tx format file. I believe that I can also output those snapshots as
> raw MIDI, so maybe a converter isn't needed.
>

Re: Translating Midi Ox "snapshots" to .tx format

2008-04-25 by rpcfender

Welcome

>I use an m-audio Keystation Pro 88 to control my Kurzweil K2000. The
>KSP 88 will send "snapshots" of current controller settings that I can
>capture and store via Midi Ox. These can be transmitted back to the
>K2000 and act as a sort of "patch" recall for my "synth" programs that
>I'm making for the K2000. What I'd like to do is assign a snapshot to
>a button on the BCR so that I can use it to store these "patches"
>outside of the computer.

>I'm pretty sure the "snapshots" will fit into the 125 byte limit for a
>.tx message -- there are around 50 controllers on the KSP 88, so if I
>put one per line then I should only have 50 or so lines.

If you mean one button to send all the sysex messages, then you are in
strife.
As you pointed out there is a message limit on a single control.
125 / 50 is not even 3 bytes per message so this won't be possible.

But if you want to split the sysex over a few buttons, the BCR/BCF has 4
x 8 buttons on the rotary controls top row, 2 x 8 buttons below this,
and 4 buttons on the bottom right = 52 so are a few you could use (there
are others if you need them)

> What'd be
>really slick is if there were some sort of file converter (I'm a
>programmer by profession, so I could write one if it doesn't exist
>yet) that would take a Midi Ox "snapshot" file and translate it into a
>.tx format file. I believe that I can also output those snapshots as
>raw MIDI, so maybe a converter isn't needed.

There are a couple of editors here. Mark's new graphic one can do just
about everything (but it doesn't make a cup of tea! Mark you should do
something about that)

I mainly use my script editor because that is what I am used to. Mark's
has a page were you can edit the script as well, but I think you can
just cut and paste the sysex messages from MidiOx into the .tx space in
the graphic part of the editor.
BCs use $ for the hex prefix so you will need to add that to each byte
as MidiOx displays in Hex unless you capture it using the sysex page and
convert it to decimal.

> ...Adding, the BCR can generate snapshots itself. Could these be
> assigned to the BCR's buttons which, when pressed, would cause the
> BCR's rotary controllers to assume the values in the snapshot assigned
> to the button? Combining the BCR assignments and the KSP assignments
> in a single "preset" would be beyond cool...

The feedback in the BC's doesn't respond to sysex. Midi CC (continuous
controllers) are normally used for feedback (I have tried others but not
all, so I can't say for sure that there aren't other message types that
would work) and only if the .easypar command is used in the script.

For feedback you will need to have a BC preset with CC and use a CC to
sysex converter to send it out and a sysex to CC to feed back to the BC
. There are a few about. Max/MSP should do it although I haven't tried

You could make a preset that could control the K2000 with the rotary
controls as well and set it up so that the defaults are the values you
need - this can be automatically sent when you change to that preset on
the BC. Then you can tweek away at the value on the BC during
performance. If you need to change to another preset the BC remembers
the values that you had before you changed presets and will send them
again when you reselect that preset rather than the defaults. The
defaults are reset when you power off/on

If you change a parameter using the KSP you can resend all the
parameters from the BC by holding 'Edit' and pressing '<' preset key



Hope that helps.

Royce

Re: Translating Midi Ox "snapshots" to .tx format

2008-04-25 by poser_p

Let's see, if I understand everything correctly then this:

B00B7F B00100 B04746... (the "raw midi" data as logged by Midi Ox for
a "patch")

should be converted so it looks like this:

$B0 $0B $7F
$B0 $01 $00
$B0 $47 $46
etc.

And I could put a few statements on each line. The full output looks
like this:

B00B7F B00100 B04746 B0486B B04900 B04A01 B01562 B01600 B0177F B0187F
B0037F 
B00907 B00C7F B00D00 B00E5A B00F07 B01400 B01900 B01A7F B01B00 B01C0F
B01D00 
B01E00 B01F7F B0467F B04B3D B04C00 B04D00 B04E00 B04F21 B05400 B05500
B05600 
B05700 B05800

Counting bytes (where one byte = one hexidecimal value), I come up
with 105. If I could divide it up among 10 lines or less then I think
that'd be o.k., correct? If so, I could throw together a quick little
program that converts the "raw" midi data to hex.

   -Andrew-

--- In bc2000@yahoogroups.com, "rpcfender" <rpcfender@...> wrote:
>
> Welcome
> 
> >I use an m-audio Keystation Pro 88 to control my Kurzweil K2000. The
> >KSP 88 will send "snapshots" of current controller settings that I can
> >capture and store via Midi Ox. These can be transmitted back to the
> >K2000 and act as a sort of "patch" recall for my "synth" programs that
> >I'm making for the K2000. What I'd like to do is assign a snapshot to
> >a button on the BCR so that I can use it to store these "patches"
> >outside of the computer.
> 
> >I'm pretty sure the "snapshots" will fit into the 125 byte limit for a
> >.tx message -- there are around 50 controllers on the KSP 88, so if I
> >put one per line then I should only have 50 or so lines.
> 
> If you mean one button to send all the sysex messages, then you are in
> strife.
> As you pointed out there is a message limit on a single control.
> 125 / 50 is not even 3 bytes per message so this won't be possible.
> 
> But if you want to split the sysex over a few buttons, the BCR/BCF has 4
> x 8 buttons on the rotary controls top row, 2 x 8 buttons below this,
> and 4 buttons on the bottom right = 52 so are a few you could use (there
> are others if you need them)
> 
<snip...>
> 
> There are a couple of editors here. Mark's new graphic one can do just
> about everything (but it doesn't make a cup of tea! Mark you should do
> something about that)
> 
> I mainly use my script editor because that is what I am used to. Mark's
> has a page were you can edit the script as well, but I think you can
> just cut and paste the sysex messages from MidiOx into the .tx space in
> the graphic part of the editor.
> BCs use $ for the hex prefix so you will need to add that to each byte
> as MidiOx displays in Hex unless you capture it using the sysex page and
> convert it to decimal.
<snip...>
Show quoted textHide quoted text
> 
> Royce
>

Re: Translating Midi Ox "snapshots" to .tx format

2008-04-26 by rpcfender

Hi Andrew
> Let's see, if I understand everything correctly then this:
>
> B00B7F B00100 B04746... (the "raw midi" data as logged by Midi Ox for
> a "patch")
>
> should be converted so it looks like this:
>
> $B0 $0B $7F
> $B0 $01 $00
> $B0 $47 $46
> etc.

Yes
>
> And I could put a few statements on each line. The full output looks
> like this:
>
> B00B7F B00100 B04746 B0486B B04900 B04A01 B01562 B01600 B0177F B0187F
> B0037F
> B00907 B00C7F B00D00 B00E5A B00F07 B01400 B01900 B01A7F B01B00 B01C0F
> B01D00
> B01E00 B01F7F B0467F B04B3D B04C00 B04D00 B04E00 B04F21 B05400 B05500
> B05600
> B05700 B05800

B0 is CC on channel 1 not sysex which starts $F0 and ends $F7 and usually has a manufacture ID device id and other heard bytes before you get to the data bytes, so you as in business as you could fit a whole lot of $B0 messages.

Midi has a thing called 'running status' where it is possible to state the status byte (B0) just once then stream out just the data bytes. So your message would look like this

$ B0 $0B $7F
$01 $00
$47 $46
$48 $6B
$49 $00
; $4A $01
$15 $62
; $16 $00
$17 $7F
$18 $7F
$03 $7F
$09 $07
$0C $7F
$0D $00
$0E $5A
$0F $07
$14 $00
$19 $00
$1A $7F
$1B $00
$1C $0F
$1D $00
$1E $00
$1F $7F
$46 $7F
$4B $3D
$4C $00
$4D $00
$4E $00
$4F $21
$54 $00
$55 $00
$56 $00
; $57 $00
$58 $00

Which saves nearly 1/3 of you data space and will work on the BC (as the BC doesn't care what numbers you put into .tx) and most synths will cope.

You can use 'running status' to send to a PC but you will never see it on a PC as MicroSoft think the know better than a standard that has lasted over 35 years and insist that all Midi device divers convert running status to a normal Midi messages adding that extra third back again. You can send out running status from the PC to test your synth (MidiOx can do this for you).


>
> Counting bytes (where one byte = one hexidecimal value), I come up
> with 105. If I could divide it up among 10 lines or less then I think
> that'd be o.k., correct? If so, I could throw together a quick little
> program that converts the "raw" midi data to hex.
>

You don't have to bother as it will all fit on one button with or without 'running status' as you were wanting to do.
Just look at my pdf called BC Secrets for details about .tx messages (files section).

$button 33
.showvalue on
.mode down
.default 0 ; (semi colon is a comment) this is not used
.minmax 0 127 ; this is not used
.tx $ B0 $0B $7F $01 $00 $47 $46 $48 $6B $49 $00 $4A $01 $15 $62 $16 $00 $17 $7F $18 $7F $03 $7F $09 $07 $0C $7F $0D $00 $0E $5A $0F $07 $14 $00 $19 $00 $1A $7F $1B $00 $1C $0F $1D $00 $1E $00 $1F $7F $46 $7F $4B $3D $4C $00 $4D $00 $4E $00 $4F $21 $54 $00 $55 $00 $56 $00 $57 $00 $58 $00

1st Button top left - check that I got the tx correct.

All the best
Royce

Re: Translating Midi Ox "snapshots" to .tx format

2008-04-26 by poser_p

Cool -- I wrote a little utility that converts the "raw" midi data
from MidiOx to behringer-formatted hex values. A cool feature, btw, if
anyone wants to implement it for one of the editors for the BC2000
would be to capture "snapshots" of midi data at a user-designated port
and convert them to .tx on the fly, so the user could assign them to a
button. I could try to write something like that (assuming the base
code is in one of the .net languages) myself if anyone wants to share
code. 
 
Thanks for your help -- I did a proof-of-concept test working manually
with my converter, next I'm going to add stripping out the extra B0
messages and see if the K2000 will respond correctly.

   -Andrew-

--- In bc2000@yahoogroups.com, "rpcfender" <rpcfender@...> wrote:

<snip...>

> B0 is CC on channel 1 not sysex which starts $F0 and ends $F7 and
> usually has a manufacture ID  device id and other heard bytes before you
> get to the data bytes, so you as in business as you could fit a whole
> lot of $B0 messages.
> 
> Midi has a thing called 'running status' where it is possible to state
> the status byte (B0) just once then stream out just the data bytes. So
> your message would look like this
> 
> $ B0 $0B $7F
>            $01 $00
>            $47 $46
>            $48 $6B
>            $49 $00
>            $4A $01
>            $15 $62
>            $16 $00
>            $17 $7F
>            $18 $7F
>            $03 $7F
>            $09 $07
>            $0C $7F
>            $0D $00
>            $0E $5A
>            $0F $07
>            $14 $00
>            $19 $00
>            $1A $7F
>            $1B $00
>            $1C $0F
>            $1D $00
>            $1E $00
>            $1F $7F
>            $46 $7F
>            $4B $3D
>            $4C $00
>            $4D $00
>            $4E $00
>            $4F $21
>            $54 $00
>            $55 $00
>            $56 $00
>            $57 $00
>            $58 $00
> 
> Which saves nearly 1/3 of you data space and will work on the BC (as the
> BC doesn't care what numbers you put into .tx) and most synths will
> cope.
> 
> You can use 'running status'  to send to a PC but you will never see it
> on a PC as MicroSoft think the know better than a standard that has
> lasted over 35 years and insist that all Midi device divers convert
> running status to a normal Midi messages adding that extra third back
> again. You can send out running status from the PC to test your synth
> (MidiOx can do this for you).
> 

<snip...>
Show quoted textHide quoted text
> All the best
> Royce
>

Re: Translating Midi Ox "snapshots" to .tx format

2008-04-30 by Mark van den Berg

--- In bc2000@yahoogroups.com, "poser_p" <poserp@...> wrote:
> I wrote a little utility that converts the "raw" midi data
> from MidiOx to behringer-formatted hex values. A cool feature, btw, if
> anyone wants to implement it for one of the editors for the BC2000
> would be to capture "snapshots" of midi data at a user-designated port
> and convert them to .tx on the fly, so the user could assign them to a
> button.

Done: the highly imminent BC Manager version 1.2.0 allows this.

In fact, even in earlier versions you could request/capture snapshot 
messages in the MIDI input message window. The only problem was that
you couldn't paste them into the ".tx" editing window; you can in the
new version.

rpcfender wrote:
> There are a couple of editors here. Mark's new graphic one can do just
> about everything (but it doesn't make a cup of tea! Mark you should do
> something about that)

I'll think about it, but actually this seems more like a job for the
BCF/BCR2000 themselves: it should be easy to make them send the
appropriate MIDI messages to a tea-making machine with a MIDI input.

Other things I'd like my BCF and BCR to do:
- dial phone numbers
- switch tv channels
- draw the curtains

The possibilities are endless...

Mark.

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.