Bc2000 (for the BCF2000 & BCR2000)

klorisk wrote:
> File handling is a bit odd (for example: you
> can't import a sysex file directly to a "preset slot", but you can
> import it to a complete setup and then copy it to the preset slot you
> want).

Insofar as BC Manager's preset file handling is "a bit odd", that's largely a reflection of the way the BCF2000 and BCR2000 send/receive presets:

The BCF/BCR first places any preset data it receives in the "temporary preset" (also called "preset 0" in BC Manager). Then, when the BCF/BCR receives a "$store N" command, it copies its temporary preset to memory preset N (1-32).
Similarly, when a memory preset is sent FROM the BCF/BCR, the preset's number is appended to the SyxEx stream via a "$store N" command.

So whereas a preset syx-file can contain more than 1 preset, each of these presets (except the last one) must be followed by a memory preset number.
(Sending a file containing multiple presets WITHOUT preset numbers to the BCF/BCR would be useless: each preset would only go to the temporary preset area, each overwriting the previous!)

So there are several reasons why in BC Manager you can't import a syx file directly to the preset slot you're on:

1. A syx file can contain multiple presets. So for instance what would you like to happen if you're on preset 32 and the file contains 10 presets?

2. BC Manager takes the memory preset numbers specified in a syx file being opened/imported seriously: it puts the presets in the SPECIFIED memory presets.
So you can export a range of presets to a single file, and then when you open/import this file, these presets are restored exactly to their original positions.
Note that any slots for which no data exists in the file are not affected; so in that sense the open/import operations don't necessarily concern a "complete setup".
(See the manual, section 8, for further discussion of the Open and Import operations.)

So all in all I'm not sure whether yet another syx file opening operation would be useful (possibly further confusing the user), but I'm open to suggestions.

   Mark v.d. Berg.