CC+ Firmware Update for Rhodes Chroma

via David Clarke on the Rhodes Chroma list:

"Thank you all for your ongoing participation in the Chroma CPU Plus (CC+) project.

Firmware Release 217 (http://www.rhodeschroma.com/?id=cpuplusfirmware#217) has just been made available.

Based on user requests, the newly released version of firmware adds the following items:

* Native support for the SparkFun serial LCD controller
* Autotune failure information display [Set Split 40]
* User-defined MIDI velocity mapping
* Auto-send of patch parameters with a Program Change

Two elements are also changed in this release:

* Correction for the ‘reset’ issue noted here:
http://www.rhodeschroma.com/?id=2012&month=01#cpuplusfirmwarehiccup

* Update the MIDI Continuous Controller “Prog” Mode to allow automatic LCD decoding of patches from BCR2000, Enabler, iPad, etc.

Details and other notes are below:

============================

Support for SparkFun LCD Controller
-----------------------------------
Previous firmware versions exclusively supported the Parallax 27979 LCD display.

Some users have asked for more flexibility when choosing LCD display units, such as having an option for red-on-black (not supported by the Parallax 27979).

An alternate controller put forward for consideration by group members was the SparkFun serial-to-LCD unit (http://www.sparkfun.com/products/258).

Support for this controller is added in firmware release 217. Specifically, the Serial Display Type can be chosen by going into the Configuration Interface [Set Split 36] and selecting parameter 27 [P27].

The user has the following two choices:

PArL = Parallax
SFun = SparkFun

The setting becomes fully effective after leaving the Configuration Interface mode and power cycling the Chroma.

NOTES:

1) The ASCII messages used to decode Parameter 1 [Patch Type] previously used the “||” characters to signify ‘parallel’. As some special control sequences recognized by the SparkFun controller use the || character string, the display abbreviation of "||" has changed to "//".

2) The SparkFun controller is generic, and will support many different types/sizes of displays and run at different baud rates. That said, the CC+ firmware is written to expect:

- a 4-line x 20-character display
- 19,200 baud communications

Any display unit chosen for use with the SparkFun controller should be able to support 4x20 characters. As well, the SparkFun controller will have to be configured appropriately before use with the CC+.

Per the SparkFun documentation, at least 3 commands will need to be sent to the SparkFun controller before use with the CC+:

ASCII character 124 + CTRL-c [sets 20 character mode]
ASCII character 124 + CTRL-e [sets 4 line mode]
ASCII character 124 + CTRL-o [sets to 19200 baud rate]

Autotune Failure Diag. Info
---------------------------
At present, when a channel fails during auto-tune, a single number will appear in the DATA READOUT display on the Chroma’s panel. While that number will identify which dual-channel board has failed during auto-tune, it does not tell you which of the two channels on that board had problems nor does it provide any information as to what the actual failure was.

For those of us who work on our own electronics, it is often helpful if we can understand ‘why’ the auto-tune believed there was a failure, which channel it affected and which portion of that channel had a problem.

While some CC+ users had already been provided with an unofficial ‘voice card debug’ version of firmware, starting with firmware 217 this capability has been made part of the standard release.

The CC+ now internally keeps track of what failed on which channels during auto-tune. That failure information can be viewed after-the-fact to determine the nature of the failure.

Specifically, issuing [Set Split][40] tells the CC+ to print details of any auto-tune failures to the Alphanumeric Display (http://www.rhodeschroma.com/?id=cpuplusalphadisplay).

The information printed to the display consists of individual messages of the form:

CnEm

where “n” represents the hexadecimal channel number (e.g., 0 -> f for channels 0 -> 15) and “m” represents one of the 10 different error locations, as below:

0 = Oscillator scale factor high end measurement
1 = Oscillator scale factor low end measurement
2 = Oscillator scale factor computation
3 = Oscillator offset measurement
4 = Oscillator offset computation
5 = Filter scale factor high end measurement
6 = Filter scale factor low end measurement
7 = Filter scale factor computation
8 = Filter offset measurement
9 = Filter offset computation

The amount of data captured will depend on the type of auto-tune performed.

For a standard auto-tune (the type you get with the Auto-tune button or a power-up), you will only receive information on the first error caught on a channel.

If [Set Split][31] is used to tune the Chroma, then all elements of the channel cards are checked and all captured failures will be logged.

Examples:

Channel Board 5 with VCO (chip Z3) missing
Normal Auto-Tune LCD Output: CbE0
Set Split 31 LCD Output: CbE0 CbE1 CbE3

Channel Board 7 missing
Normal Auto-Tune LCD Output: CeE0
Set Split 31 LCD Output: CeE0 CeE1 CeE3 CeE5
CeE6 CeE7 CeE8 CfE0
CfE1 CfE3 CfE5 CfE6
CfE7 CfE8

Further background on the nature of these error locations is generally presented in the Tuning description on the site (http://www.rhodeschroma.com/?id=tuning).

NOTES:

1) The output only goes to the alphanumeric display. That means it is necessary to have a display installed and operational before you can take advantage of this feature.

2) As each message takes 5 characters, and the display supports 80 characters, at present a maximum of 16 failure messages (the first 16 errors logged) can be shown.

3) If there are no auto-tune errors detected, pressing [Set Split][40] will display a blank screen.


User-defined MIDI Transmit Velocity Mapping
-------------------------------------------
As discussed in the ChromaTalk mailing list, there is a desire to be able to modify the MIDI velocity mapping from the Chroma:

http://www.rhodeschroma.com/?id=2010&month=05#cpuplusalternatevelocitycurves

http://www.rhodeschroma.com/?id=2012&month=06#velocitycurves

Firmware release 217 now allows a user to specify and use a custom MIDI transmit velocity map.

The user can choose the desired MIDI Tx Velocity lookup table by going into the Configuration Interface [Set Split 36] and selecting parameter 29 [P29].

The user has the following two choices:

int = Internal CC+ velocity map (normal CC+ behaviour)
CUSt = Custom (user-defined) velocity map

The first selection will choose the default internal CC+ MIDI velocity map - the one which is used for all CC+ units with version 216 or earlier firmware.

The second selection will chose a custom velocity map stored inside the Chroma by a user (sent via MIDI SYSEX).

To send a custom map to the Chroma, a MIDI SYSEX message like the following would be used:

F0 08 00 4B 59 7F 39 dd dd dd .... F7

where dd = 32 bytes, corresponding to the desired 32-position table for MIDI Tx values (from 0 to 127)

You can also request the current custom map to be sent back to you from the CC+ you via SYSEX. That would be done with a MIDI Tx Velocity lookup table dump request, as below:

F0 08 00 4B 59 00 39 F7

The user specifies what their desired mapping is between the Chroma’s internal 32-levels of velocity and what corresponding MIDI velocity they would like the CC+ to generate for that.

For instance, the default mapping table is shown below:

Chroma Velo. -> MIDI Velocity
0 1
1 4
2 8
3 12
4 16
5 20
6 24
7 28
8 32
9 36
10 40
11 44
12 48
13 52
14 56
15 60
16 64
17 68
18 72
19 76
20 80
21 84
22 88
23 92
24 96
25 100
26 104
27 108
28 112
29 116
30 120
31 124

The Chroma will always attempt to automatically create an inverse mapping table and store that for lookup purposes, to help ensure that the Chroma will respond appropriately when recorded velocity is sent back to it. The inverse table is created when a new Custom Velocity Transmit Table is received via SYSEX.

In order to ensure that the reverse mapping is really an inverse of the forward mapping, the specified MIDI velocity values should be unique. If they are not unique, then you won’t necessarily get a 1:1 mapping in both directions.

For instance, consider if a user was to create a MIDI Tx mapping that had a MIDI velocity of 127 for Chroma Velocity 24, 25 and 26, as below:

Chroma Velo. -> MIDI Velocity
...
24 127
25 127
26 127
...

If you then attempt to create a reverse mapping (e.g., what Chroma Velocity should be created for a given MIDI Velocity), then as you can see, a MIDI velocity of 127 could only produce one of those Chroma Velocity values (24, 25 or 26).

To handle cases like this, the reverse mapping will use the lowest Chroma value. In the case of the “127” MIDI velocity example above, that would mean a MIDI velocity of 127 would correspond to a Chroma velocity of 24.

To facilitate experimentation with this feature, a series of velocity mappings have been created and are available on the Rhodes Chroma site (http://www.rhodeschroma.com/?id=cpuplusvelocitymaps).

The initial SYSEX files are as follows:

- default (a copy of the native CC+ mapping)
- linear/saturated curve (allow higher MIDI velocities to more easily occur - meaning you can get to a MIDI velocity of 127 without having to hit the keys as hard)
- convex curve (greater control over louder notes)
- concave curve (greater control over softer notes)
- experimental (non-uniform handling of velocity)

To use one of these, send the chosen SYSEX file to the Chroma, and set [Set Split 36][P29] to CUSt.

If you wish to go back to the original mapping, select ‘int’ from [Set Split 36][P29].

The last received custom map is remembered inside the CC+, and so the past custom map can be reselected at any time (without needing to send the SYSEX for it back to the CC+).

NOTES:

1) A MIDI note velocity of 0 is a special case to also mean “Note off” - and so for expected behaviour, you likely want to avoid using that value in the mapping table.

2) Before concluding that the velocity response of your keyboard needs to be corrected with a custom velocity map, please ensure that the Damper Bar and Stack Switch Adjustments are performed, as these can affect velocity performance:

http://www.rhodeschroma.com/?id=calibrationcheckout#damperbaradjustment

http://www.rhodeschroma.com/?id=calibrationcheckout#stackswitchadjustment

3) It is hoped/expected that if users find a custom map of their own that is believed to be of general use that it will be shared via the site (so that others can benefit too).

4) No ‘default custom’ map is programmed into the firmware - so one will need to be loaded via SYSEX to prior to initial, successful use of the Custom mapping feature.


Auto-send of Patch Parameters (MIDI ‘Talkback’)
-----------------------------------------------
Starting with Firmware 215 (http://www.rhodeschroma.com/?id=cpuplusfirmware#215), a SYSEX message was added to remotely request the Chroma to send the contents of its current panel program as a dump of MIDI Continuous Controller messages.

While this ‘on demand’ capability is present, users have indicated that it would be useful to be able to have the CC+ automatically send all parameters of the current patch as MIDI CC commands as soon as a new patch is chosen/selected:

http://www.rhodeschroma.com/?id=2007&month=03#cpuplusremotecontrol

In that way, any attached editor device would be able to adjust its faders/pots/virtual displays automatically to reflect the settings in the current patch (without that external device having to request the parameters.)

Starting with firmware 217, an optional “Auto-Send MIDI CC” feature has been added.

This feature can be chosen by going into the Configuration Interface [Set Split 36] and selecting parameter 30 [P30].

The user has two choices, as below:

Off = Don’t auto-send patch contents (normal CC+ behaviour)
On = Automatically send patch settings via MIDI CC

This feature is configured so that patch settings are sent via MIDI CC’s only via 'front panel' program changes from the Chroma (e.g., by
pressing a Program button - or pressing the Sequence footswitch). MIDI
program changes won't cause a MIDI CC dump EXCEPT if the CC+ is configured for ‘PLAY’ mode ([Set Split 36][P2] = PLAY) because in that mode a MIDI Program Change behaves just like a front panel change.


Automatic LCD decoding of MIDI Continuous Controller Data
---------------------------------------------------------
It is noted on the BCR2000 setup page (http://www.rhodeschroma.com/?id=BCR2000setup) that “...If you use the Alphanumeric display with the Chroma, and if the Chroma’s current parameter is the one being edited via the BCR2000, then the LCD display will similarly decode the values seen from the BCR2000.”

In other words, this says that the LCD display will automatically decode and show the significance of the CC changes sent from external editors (like the BCR2000 - and presumably the Enabler and iPad editors) if the Chroma’s panel has already selected that parameter.

For instance, if the Chroma’s panel is displaying “A Parameter 9” in the DATA READOUT display - then sending an external request to modify “A Parameter 9” will automatically be decoded and displayed on the LCD. If the parameter being edited is not currently being display on the Chroma - then the LCD does not decode any incoming MIDI CC commands.

This is consistent with the idea of having the LCD display and decode what the Chroma is currently seeing for Program 0.

That said - users with external control interfaces have requested the CC+ be able to automatically decode those parameters they’re editing - such that (for instance) no matter which parameter was edited via the BCR2000, the Chroma’s LCD would decode the values and show appropriate information.

Starting with firmware 217 a change has been made to the operation of the ‘Prog’ mode of selection of the ‘MIDI Continuous Controller Mode’ choices.

As before, the Continuous Controller Mode can be chosen by going into the Configuration Interface [Set Split 36] and selecting parameter 24 [P24].

The user still has two choices, as below:

InSt = MIDI CC’s affect the ‘instrument’ and don’t affect Program 0
ProG = MIDI CC’s change values in Program 0

"Inst" mode works as it always did.

A change has been made in ‘Prog’ mode such that:

If a MIDI CC is received on the MIDI base channel:
Change the Panel Mode to Edit A or Edit B, to match the received CC parameter
Change the Panel Parameter Number to match the received CC parameter
Make change in Prog 0 definition, as before.

Any CC’s received on MIDI channels other than the base channel will behave as in InSt mode.

As the Panel information gets changed with CC messages on the base channel, the Alphanumeric LCD display will be automatically updated to decode the received parameter.

Put another way, in "ProG" mode, CC messages on the MIDI base channel will affect Program 0 and will update the alphanumeric display. CC messages on other valid MIDI channels will manipulate the Instruments, but will neither update Program 0 nor update the alphanumeric display.


====================================

While it was intended to have added a “MIDI Sweep Sync” feature (the ability to sync the Chroma's Sweep generators/arpeggiator to MIDI) to this version of firmware, we were not sufficiently satisfied with the implementation to publicly release it at this time.

Some of the support code for that feature was left in - and if you go into the Configuration Interface [Set Split 36] and select parameter 28 [P28] you can choose between:

int = Internal Clock (normal Chroma operation)
nIdi = MIDI Clock (external sync operation)

At present, this setting is deactivated, and regardless of the setting, the normal internal clock source is used.

This feature is something we still intend to add; however, due to our personal schedules we did not think we'd have time to work on this in the near-term - and so firmware 217 was released just with the features noted above.

Please continue to raise new feature ideas on the mailing list for discussion - and if there are items that users agree would be good to add, we'll certainly consider adding them.

Of course, if any problems are encountered, please also let us know.

Thank you for your continued interest.

David Clarke

----
Note - the following pages from the site have been updated in association with this firmware release:

http://www.rhodeschroma.com/?id=cpuplusmanual
http://www.rhodeschroma.com/?id=cpuplusalphadisplay
http://www.rhodeschroma.com/?id=cpuplusvelocitymaps
http://www.rhodeschroma.com/?id=cpuplusfirmware
http://www.rhodeschroma.com/?id=parameterchart

Also new is an illustration of how some users have implemented their alphanumeric displays:

http://www.rhodeschroma.com/?id=cpuplusalphadisplay#userimplementations

If you have a display solution that you like, please share it with Chris Ryan and he can be sure to add it to the site."