Skip Navigation.
Section 0

ChromaTalk Archives: June 2012

CPS

Werner Schöenenberger [21010114] · Sat, 9 Jun 2012 21:48:34 +0200

Hi all,

I just installed the CPS into my Chroma. Even if several fellows expressed their happiness before, I have to do it as well: Chris [21030194+] you did a wonderful work, really exciting. Thank you so much for this extension.

Great synth - great community

Chris Borman [21030194+] · Sat, 9 Jun 2012 16:16:49 -0400

Thank you Werner! It is a LOT of fun to play! Working on getting my Chroma to boot so I can test two additional kits, one new and a replacement for one that USPS crushed during shipment and broke in half! Also please give a silent thank you to the unnamed individual who fronted the cash for this round of PCBs. He did so wishing to keep the accessory alive for future members. Nice guy! (aren't we all though?) Actually a bunch of Chroma folks did the same to kick this effort off before I even had it designed. My only regret is having to sell my Xpander cause I fubar'd the REv 1 design trying to inkjet print my own flex circuits. It actually worked great up to the connection point. Any movement, heavy breathing, etc. caused a connection failure. I was on top of the world for a bit there inkjet printing flex circuits...

Anyway, once tested I’ll have two or three extra kits ready to go and 10 PCB sets remaining to build up future kits.

Werner Schöenenberger [21010114] · Mon, 11 Jun 2012 20:29:43 +0200

Dear Chris,

Just a small remark without intention to start a new thread. You really packed the CPS perfectly. And even then some shipping companies manage to break such parcels - incredible handling...

Discussion on Possible CC+ Feature: Sync'ing Chroma Sweep via MIDI

David Clarke [21030085++] · Sun, 10 Jun 2012 16:07:17 -0400

As the Chroma list has been a bit quiet over the last while I thought this might be a good time to start a discussion on a possible feature update to the Chroma CC+.

It had previously been suggested by one or two people that the ability to sync the Chroma's Sweep generators to MIDI would be a nice thing to have.

Aside from the a desire to have 'more in there just for the sake of having more' do people think that having a sync'able sweep would actually be a feature that would get used?

If so - what would be the desired mode of operation?

Specifically - today the Chroma has a sweep 'rate' that the user sets via a slider. (Parameter #9)

The rate can then be modulated by a Sweep Rate Mod source (Parameter #10)

Would the desire to be to have MIDI control the base 'rate' of the sweep, and have the sweep rate mod source still act upon it (e.g., to effectively have the MIDI clock determine Parameter 9) - or would the preferred approach to have the MIDI clock override the 'resulting' sweep rate (e.g. to have the MIDI clock effectively defeat the Mod source and to directly control the resulting sweep rate)?

Your input and thoughts are appreciated.

Arun Majumdar [21030348] · Sun, 10 Jun 2012 16:59:28 -0400

Hi,

I like the idea of the midi control of sweep, but, it would good to be able to defeat it as well. I think that Midi on the base rate is more interesting than midi clock directly over-riding it --- on the other hand, if both features are possible, then, certainly, it would be nice to have both.

I would be happy to make a small donation to the cause as an "upgrade" maintenance fee :)

Thanks,

Arun

Brian McCully [21030361] · Mon, 11 Jun 2012 08:57:37 -0700

Hi David,

I think the override situ may work best because the first choice is already addressable via common cc's(?). Will the clocking be different in resolution than what is currently controlled by the Chroma processor(s)? Slower, faster, or more precise in reference to incoming MIDI clock? I always wished some of the LFO rates were faster to yield more 'growl' instead of fast flutter, but maybe I was just using the wrong approach... So, I guess my question is: will the minimum, maximum and specific clocking resolution(s) be determined by incoming MIDI clock rate or just be approximated closest to what the Chroma's current architecture offers? thanks, -Brian

Philippe [21010227] · Mon, 11 Jun 2012 19:07:38 +0200

Hi,

Maybe MIDI should control the base 'rate' of the sweep, and the sweep 'rate' slider (Parameter #9) could then control time subdivisions (1/2, 1/3, 1/4...) of the MIDI rate.

And since we are discussing possible new features I would like to suggest to add if possible the Release Velocity and Arpeggiator as controls for parameters such as filter cutoff, sweep rate, sweep amplitude, wave shape width mod, etc...

Thanks,
Philippe

Eric · Mon, 11 Jun 2012 19:35:33 +0200

Please give us different velocity curves with max output velocity up to 127 (with old 2.11 OS I can only get 112 max). I have 20 expanders and don’t want to reprogram all of them every time a new player comes into the studio since he always choose the Chroma as the master keyboard (and we all know why).

Werner Schöenenberger [21010114] · Mon, 11 Jun 2012 20:45:27 +0200

Hi, all

I second the opinion of Philipe. This should be the solution. When ever MOD source is selected to MIDI Clock, the "rate" slider should act as divider. I also think that whenever MIDI Clock is selected as MOD source but no MIDI clock can be received, the "rate" slider should act as normal, since this might be very helpful in sound designing.

Cheers,
Werner

Jeffrey D. McEachin [21030073+] · Mon, 11 Jun 2012 12:35:43 -0700

Maybe MIDI should control the base 'rate' of the sweep, and the sweep 'rate' slider (Parameter #9) could then control time subdivisions (1/2, 1/3, 1/4...) of the MIDI rate.

And since we are discussing possible new features I would like to suggest to add if possible the Release Velocity and Arpeggiator as controls for parameters such as filter cutoff, sweep rate, sweep amplitude, wave shape width mod, etc...

Yes, and yes!

David Clarke [21030085++] · Mon, 11 Jun 2012 21:04:56 -0400

A few brief follow-up notes to factor in for further comments:

Will the clocking be different in resolution than what is currently controlled by the Chroma processor(s)? Slower, faster...

Based on the way the sweep is currently generated, having it be 'faster' than the max rate of 12Hz isn't really achievable.

It is possible to make for a slower sweep that 0.12Hz (if that's desirable), and it is theoretically possible to get frequencies between 0.12Hz and 12Hz that isn't otherwise achievable today.

... or more precise in reference to incoming MIDI clock?

At present, there is no reliance at all on the incoming MIDI clock. The sweep rate is determined only by one of the 64 choices of the 'rate' slider, as potentially modified by a Mod source.

The main thing that a sync would potentially do is just allow the rate itself to better match with that from a clock source other than the fixed rates.

I always wished some of the LFO rates were faster to yield more 'growl'

The current sweeps are generated in software, and as there are independent sweeps for the A and B channels, that's 16 different sweeps that need to be calculated and applied.

The need to do the calculations and update all 16 channels is what the current limiting factor is.

I like the idea of the midi control of sweep, but, it would good to be able to defeat it as well...

It would be intended to allow the user to select MIDI Sync or not.

... will the minimum, maximum and specific clocking resolution(s) be determined by incoming MIDI clock rate or just be approximated closest to what the Chroma's current architecture offers?

It would need to be a combination of both - e.g., based on the incoming MIDI clock rate, but limited by the closest allowable rate supported by the architecture. (For discussion purposes you can assume that the smallest time change for a step in the sweep is 20mS. So - 4 steps at 20mS would be 80mS or about 12Hz. 402 steps at 20mS would be about 8 seconds - or about 0.12Hz.)

... Please give us different velocity curves...

If we needed to choose between MIDI syncable sweeps or customizable velocity curves as the next feature, which would be seen as potentially more desirable by the list?

... And since we are discussing possible new features I would like to suggest to add if possible the Release Velocity and Arpeggiator as controls for parameters such as filter cutoff, sweep rate, sweep amplitude, wave shape width mod, etc..

...I've so far been hesitant to make any changes to the patch structure/content so that we can keep the patch definitions 100% transferable and usable with non CC+ implementations...

Brian McCully [21030361] · Mon, 11 Jun 2012 20:46:31 -0700

Hi David,

I'd vote for customizable velocity curves as a much higher priority. 32 step resolution?

How would the values be input and saved? Sysex string, with 32 values? How many different curves would be possible to store?

thanks! -Brian

August B. Raring [21010148] · Tue, 12 Jun 2012 21:27:23 +0200

Hello David

on top of my wishlist since my Chroma had been midified in 1984 always has been the possibility to sync the arpeggiator to MIDI clock! Is there a relationship to the sweep generator?

David Clarke [21030085++] · Tue, 12 Jun 2012 20:41:25 -0400

Discussion on Possible CC+ Feature: velocity curves

I'd vote for customizable velocity curves as a much higher priority. 32 step resolution?

Yes - the Chroma natively has 32 velocity levels that it uses, so the general idea would be to have a 32-entry table that would permit the user to associate each of the 32 Chroma velocity steps with a MIDI velocity value (from 0->127)

How would the values be input and saved? Sysex string, with 32 values?

Yes. A sysex string would be used to download the table with 32 values to the Chroma. Once downloaded, it would become non-volatile (e.g., it will persist until changed).

Since there are only 32 values, there would also potentially be the possibility of live editing/creation on the Chroma itself in the same sort of manner as is described for editing the MIDI controller Map (xref the "P19" discussion at Configuration Interface & MIDI Support).

If editing on the Chroma was supported, then there would also need to be a sysex dump capability so that a custom created mapping could be saved to sysex.

How many different curves would be possible to store?

The number could be discussed here on the group - but I would suggest it might be best to just have one 'extra' one. E.g., to have the user chose between the "standard" table or a "custom" one, where the custom one would be updatable via SYSEX to whatever was desired.

David Clarke [21030085++] · Tue, 12 Jun 2012 20:43:58 -0400

... Is there a relationship to the sweep generator?

August, yes. The arpeggio rate is determined by Sweep Rate A (e.g., Parameter 9).

Doug Terrebonne [21030114] · Tue, 12 Jun 2012 18:07:18 -0700

I would definitely prefer MIDI sync sweeps...

Philippe [21010227] · Wed, 13 Jun 2012 10:03:57 +0200

me too.

John Simmons [21030454] · Wed, 13 Jun 2012 12:42:43 +0000

on top of my wishlist since my Chroma had been midified in 1984 always has been the possibility to sync the arpeggiator to MIDI clock! Is there a relationship to the sweep generator?

I like the sound of that!

Brian McCully [21030361] · Wed, 13 Jun 2012 18:45:21 -0700

Re: Discussion on Possible CC+ Feature: velocity curves

Hi David,

I think a MAX-type MacOS (or Windows) editable 32 x 128 graph of a velocity 'curve' would be a lot easier to deal with, than the P19 1:1 Edit A / Edit B situation (at least to begin with, in trying to figure out what works best).

If you code it, I'll create a sys-ex applette. At least for a Mac. Maybe somebody else has MAX for a PC and can then generate a stand-alone (and test it).

Yes, probably one on-board alternate curve would suffice. The applette could certainly store more.

regards,

Brian

David Clarke [21030085++] · Sat, 23 Jun 2012 11:52:09 -0400

Re: Discussion on Possible CC+ Feature: velocity curves

I think a MAX-type MacOS (or Windows) editable 32 x 128 graph of a velocity 'curve' would be a lot easier to deal with... ... If you code it, I'll create a sys-ex applette. At least for a Mac. Maybe somebody else has MAX for a PC and can then generate a stand-alone (and test it)...

I agree that a graphical approach would be best for most users - but the graphics app isn't something I'd be looking to create. (graphical user interfaces aren't my forte).

In terms of actual 'sysex' implementation, the application would simply need to create a list of 32 values, ranging from 0->127, and to then create a binary file with the following contents: 

0xF0   /* Start of Sysex */
0x08   /* Fender Manuf. ID */
0x00
0x4B   /* Converter ID */
0x59
0x7F   /* Indicate that this is a data dump, not a request */
0x39   /* Indicate that this is a MIDI TX Velocity File */

for (i=0;i<=31;i++)   /* stuff array data into sysex */
{
fputc(mapArray[i], f2); /* 32 entry array - values 0 -> 127 */
}

0xF7  /* End of Sysex */

Anybody out there able/willing to be create something that others could run, to make it easy for them to create a sysex file as that above?

Also on the general topic of velocity curves and translation - is anyone currently using a MIDI mapper to remap their velocity behaviour to be something closer to what they'd like (vs. what the Chroma MIDI outputs)? If so - and if you'd like to provide those mapping details to me, I can take that currently existing map and encode it in a sysex file to later have it available on the site.

(E.g., once the custom velocity curve feature is added, I'd expect to have a handful of pre-defined curves available for download from the site, so that people can try what others have found useful before worrying about creating custom ones of their own).

Thoughts/comments from potential users are always appreciated.

David Clarke [21030085++] · Sat, 23 Jun 2012 11:31:38 -0400

Thanks to all for their input on this discussion.

Experimentation has now been completed and based on those positive results I'll plan to include a Sweep MIDI sync feature in the next firmware release.

(No firm date for that release yet).

Brian McCully [21030361] · Sat, 23 Jun 2012 20:03:29 -0700

Re: Discussion on Possible CC+ Feature: velocity curves

Hi David, et al.,

This is a really simple application to build a stand-alone applette for Mac users. I have already created modules for other applications using what is called a multislider, in Max, to use for this sort of graphic editing (like graphic EQ's, ADSR envelope values, transposition maps, etc).

Basically it's simple MIDI hex messaging with: prepended F0 08 00 4B 59 7F 39 (32 values from a 32 slider multislider) appended F7

That's simple. Once again - anybody using MAX with Windows? I can build one for Mac users regardless, but it'd be nice to do a Windows module and I don't live in that world in music-speak. It can also store as many curve 'presets' as desired.

Brian McCully [21030361] · Tue, 26 Jun 2012 07:10:11 -0700

Re: Discussion on Possible CC+ Feature: velocity curves

Hi David,

Here are a few other thoughts about the MIDI velocity-curve.

  1. No one here seems to have MAX, at least for Windows. I can easily create a stand-alone GUI Mac OS X version, that can send sys-ex curve data, and/or display the curve from a sys-ex dump (it could also send a prompt for a dump), and save any number of presets, stored by the end user. I just don't foresee purchasing a PC just to run MAX to build stand-alones, (but I did have fun playing with the 23" touch screen on an HP last night...).
  2. can there be an instant way to see if the current curve is 'linear' (1:1) or 'modified'?
  3. on the topic of preset curves - the nomenclature used for the velocity curves by various companies is boundless - like hard 1 hard 2 soft1 soft2 log1 log2 expon spline etc etc. Kurzweil used tons of them and has the most complete curve implementation that I've seen - all of their reference manuals are on line for the K2000/K25/K26 etc if you're curious. I think that with a simple implementation having easily adjusted values for just 32 numeric values - one might not want to bother with any 'named' presets other than the 1:1 (reset). Again stored presets could be had in my little applette, and to modify them before sending is as easy as swiping a mouse across the 32 sliders, or clicking vertically on one slider to adjust its value on a 32x128 'bar graph'. I can also create a preview mode that allows the presets to be viewed, but not sent.
  4. Probably mentioned before... but would a velocity curve affect the internal triggering as well? Hopefully it only affects outgoing values because I'd hate to have to re-program all the Chroma's veloc related values because the MIDI velocity is optimized for outgoing triggering. Maybe a silly question but just wanted to make sure. There have been gripes about how the old last (Fender) firmware changed the feel of the internal triggering but I'm not sure that this is the same topic(?).

thanks! -Brian

David Clarke [21030085++] · Tue, 26 Jun 2012 20:38:20 -0400

Re: Discussion on Possible CC+ Feature: velocity curves

can there be an instant way to see if the current curve is 'linear' (1:1) or 'modified'?

The current thought was to have another configuration parameter (e.g., [Set Split][36], [P29]) that the user would select either "int" for the internal/default mapping or "Cust" for the user defined/custom uploaded map.

Did you have something else in mind?

on the topic of preset curves ...

The intent would not be to have names in the Chroma itself - but instead on the Chroma site (where the sysex files were), there might be some description (name) to subjectively say how the file behaves. It may actually be better to also just have a small graph showing the curve - accompanied by a short description instead.

... Again stored presets could be had in my little applette, and to modify them before sending is as easy as swiping a mouse across the 32 sliders, or clicking vertically on one slider to adjust its value on a 32x128 'bar graph'...

I may certainly be wrong - but I anticipate that most people will not be actively changing mapping; rather, they'd experiment to find one that they like - and then maybe tweak it a bit - and then that would become their 'default' map and they'd just always just use. Once they find the one they like, I wouldn't expect a lot of desire to revisit or go to alternate maps.

... would a velocity curve affect the internal triggering as well? Hopefully it only affects outgoing values...

In past group discussions it was concluded that the only desire was to change the MIDI behaviour, and to not actually affect how the Chroma internally uses its own keyboard velocity.

That being the case, the intent is really just to only affect the velocity that is sent via the CC+ MIDI interface.

To support those people who play their Chroma into a sequencer, and then layer play back, if a custom transmit map is used, a reciprocal mapping would be implemented for the velocity receive (so that what you played back would sound the same way it did when recorded).

Brian McCully [21030361] · Tue, 26 Jun 2012 20:17:40 -0700

Re: Discussion on Possible CC+ Feature: velocity curves

David, 'int' and 'cust' are fine. Instant recognition. Didn't know if it would say curve1 curve2 or curve10...

If the user has to edit it through the single slider UI via something like: 

v0  0
v1  4
v2  8
..
.. 
v31 127

sliding and editing through all the 32 parameters could get pretty brutal trying to dial in something that works well. So a GUI to me is almost imperative.

Didn't know if you had preset names in mind, but I can also have names (text) saved with the curves, that could be posted (on-line, subjectively). If you want to get into (~10 or 12 characters of) ASCII for the name in the sys-ex, that's possible too - I've done that with a Roland JX-8P / MKS-70 editor using MAX. In my last posting, I was trying to get at is how thought through this 'text label' part is, and avoiding spec-creep.

The manner in which I see a user curve developed is that they use the Mac/Pc editor, send the veloc curve file to the Chroma, and then tweak from that point. On subsequent edits, not re-writing the curve from scratch every time, but recalling either on the Mac/PC or from a Chroma dump - so there may be some velocity curve 'files' or presets saved along the way. So, either in the same session, or at some point later on, it would be nice to see 1) whether it is a 'cust' velocity map, then 2) query it to dump to the Mac/PC editor, then 3a) tweak it, or 3b recall a preset 4) send it.

Once the end user gets settled in, they may not change it. But they might - and it would be good to have it saved somewhere in case someone -else- changes it or the 'cust' curve is lost via a firmware upgrade, etc. Yes, a simple labelled sys-ex file will suffice as well.

As far as using an inverse curve in some future sense for playback, that may be a little odd, especially if one isn't sure at what point what curve was used whenever. I would vote for the Chroma only dealing on a 1:1 in the incoming MIDI, as I've never had a problem with the Chroma as a slave module in the velocity sense. It's been a while since I recorded the Chroma for MIDI playback, but wow that could get complex.

I'd almost want to record it to a sequencer with Yppirila's interface at 1:1 velocity for the Chroma playback, and then use the custom map out the other MIDI port for recording everything else...

David Clarke [21030085++] · Wed, 27 Jun 2012 19:53:35 -0400

Re: Discussion on Possible CC+ Feature: velocity curves

NOTE: An implementation question for the group below. If you think you may ever use a custom velocity feature, your input below would be appreciated.

... If you want to get into (~10 or 12 characters of) ASCII for the name in the sys-ex, that's possible too...

Given the limited number of potential users and the limited number of people within that user group likely to avail themselves of the custom mapping, I'd suggest simpler is better (e.g., I think we can get by just with the raw mapping, without any embedded text).

... it would be good to have it saved somewhere in case someone -else- changes it or the 'cust' curve is lost via a firmware upgrade, etc. Yes, a simple labelled sys-ex file will suffice as well...

And I think that would be the easiest plan. Just like the sysex 'patch' commands, you can either send a dump or request a dump - so once the user has the mapping they like, it can be requested and then saved on the computer (or in a sequence) for later retrieval.

As this is straight sysex, they could use normal sysex capabilities of standard sequencers to handle that portion of the operation.

As far as using an inverse curve in some future sense for playback, that may be a little odd, especially if one isn't sure at what point what curve was used whenever...

I don't disagree - but I think it would be equally odd if the unit used one map for transmitting and a different map (1:1) for receive - except if you always only ever used the Chroma as a master keyboard and sound module (vs. a sound-producing item itself you might sequence).

... as I've never had a problem with the Chroma as a slave module in the velocity sense...

Agree - but the main problem would be a play-back of a recorded sequence.

QUESTION FOR THE LIST: Assuming a custom MIDI velocity transmit mapping is done by the CC+, what should the CC+ do for received MIDI velocity info?

Option 1: Only ever have a custom map for MIDI Tx - always use the standard 1:1 map for MIDI Rx velocity (potential drawback: you'll have problems trying to play with a custom map, record that into a sequencer, then expect to hear the same thing played back).

Option 2: Anytime you have a custom MIDI Tx map, have the CC+ calculate an equivalent MIDI Rx mapping, so that anything you play and record will sound the same if you send it back to the Chroma (potential drawback - if you forget you have a custom map in use, then any standard MIDI data sent to the Chroma will be interpreted by the custom velocity map.)

Option 3: Offer both Option 1 and 2 to the user e.g., 3 choices for MIDI Tx Velocity: Internal Map, Full Custom (Tx and Rx) Map, Tx-only Custom map. (Potential drawback - one more thing a user has to keep track of - and potentially forget about - resulting in confusing behaviour of the velocity handling for MIDI).

Brian McCully [21030361] · Wed, 27 Jun 2012 18:20:55 -0700

Re: Discussion on Possible CC+ Feature: velocity curves

I have another question that's maybe been answered already but here it is: between the apple sequencer, the chromaface, the syntech and now the CC+ (the latter three which I have owned) did the playback always not match the outgoing triggering?

Is there a way to determine (quantify) what the actual offset is between the two in the CC+? Other than taking the time to record the literal audio from a lot of key presses of various velocities (and recording the MIDI velocity output at the same time with a sequencer), and then comparing that set of audio recordings, to match what plays from incoming MIDI. And then charting the difference between the 32 internal velocities.

Because then a standard incoming map could be just applied as a '1:1 fixer' when the Chroma is master with local off, triggering itself remotely.

David Clarke [21030085++] · Wed, 27 Jun 2012 21:44:16 -0400

Re: Discussion on Possible CC+ Feature: velocity curves

... did the playback always not match the outgoing triggering?

Brian - the 'mapping' is expected to be a reciprocal match.

E.g., if you play a velocity of Y inside the Chroma - that turns into MIDI velocity X.

When you send MIDI velocity X back to the Chroma - that does turn back into Chroma velocity Y.

As MIDI velocity is 0->127 and Chroma velocity is 0->31 the mapping is essentially as follows:

MIDI Tx:
MIDI Velocity = Chroma Velocity x 4
MIDI Rx:
Chroma Velocity = trunc(MIDI Velocity/4)

(Was that your question, or did I perhaps misunderstand?)

Brian McCully [21030361] · Wed, 27 Jun 2012 19:15:47 -0700

Re: Discussion on Possible CC+ Feature: velocity curves

No I think you misunderstood, or maybe everything is aok and you're just trying to clarify on something else. Let me phrase it differently.

If I play Chroma as master local off and trigger the same Chroma externally as a slave through a sequencer, would the sound produced be identical to that of just triggering the internal sounds? Or better yet..., if I play two Chromas side by side, one triggered by the other Chroma via MIDI (with identical patches obviously) is the sound output identical from both? If not, then what is the difference in the MIDI velocity mapping required to make up the difference? -Brian

(and if there is a difference, has it always been this way? Or if there is a difference, then can we just set up an incoming MIDI table to make up the difference, as an alternative to trying to match the seemingly low values sent from the current 1:1 mapping?)

Chris Smalt [21010280+] · Thu, 28 Jun 2012 15:42:08 +0200

Re: Discussion on Possible CC+ Feature: velocity curves

NOTE: An implementation question for the group below. If you think you may ever use a custom velocity feature, your input below would be appreciated.

Let's not forget that any half-decent sequencing software is capable to produce all the effects we're discussing: velocity scaling + inversion, tempo-synched controller sweeps etc.

If you prefer interfacing your Chroma with midi gear without a computer, there are several hardware boxes that can help you out.

And the internal architecture of the Chroma itself often offers a workaround already.

Brian McCully [21030361] · Thu, 28 Jun 2012 10:15:02 -0700

Re: Discussion on Possible CC+ Feature: velocity curves

Let's not forget that any half-decent sequencing software is capable to produce all the effects we're discussing: velocity scaling + inversion, tempo-synched controller sweeps etc.

Granted. Which also means you always have to boot a computer, glowing screen, noise and all. I enjoy the occasional 'piano mode' where I can turn on my MIDI interface in stand-alone MIDI-thru mode, and simply trigger other modules randomly and leisurely from the Chroma (and with the new PS, it's dead silent). My Chroma is also not in close proximity to my computer.

If you prefer interfacing your Chroma with midi gear without a computer, there are several hardware boxes that can help you out.

MIDI Solutions Velocity Converter is $149 US. David is offering an opportunity to have this capability without spending the extra $, and adding one more box in-line (or two boxes if there will be an inverse curve in the other direction).

And the internal architecture of the Chroma itself often offers a workaround already.

Please expand upon this. Is this workaround a global function or per patch editing? I am still puzzled how this (and the DX-7's) velocity issues ever came to be and still remain, and it would be nice if a new on-board 1:1 curve solution fixed the issue once and for all. -Brian

David Clarke [21030085++] · Thu, 28 Jun 2012 20:07:32 -0400

Re: Discussion on Possible CC+ Feature: velocity curves

... if I play two Chromas side by side, one triggered by the other Chroma via MIDI (with identical patches obviously) is the sound output identical from both?...

In short - yes.

Brian McCully [21030361] · Thu, 28 Jun 2012 19:36:47 -0700

Re: Discussion on Possible CC+ Feature: velocity curves

In long? So why is there an issue? Is it all about how hard we (have to) hit the keys?

Chris Smalt [21010280+] · Fri, 29 Jun 2012 14:38:06 +0200

Re: Discussion on Possible CC+ Feature: velocity curves

Is it all about how hard we (have to) hit the keys?

Nitpick: velocity is about how fast - no need to pound the keys.

Go to next message in thread, July 2012

Rhodes Chroma for sale

Michael Dykehouse [21030757] · Mon, 11 Jun 2012 08:26:22 -0700

Hello,

It pains me to write this email but I currently need the money. I wanted to offer my Chroma to list members in hopes that it ends up going to a good home. My Rhodes Chroma is serial number 21030757. It has the updated power supply, CC+, and the polyphonic after touch upgrade. Light discoloration on the wooden ends from the well known case foam issue but other than that very nice condition externally, and with a professional refinish this will be a "perfect" specimen. The inside looks like a museum- VERY very clean. I was very surprised when I first opened her up to see how clean she was-the best condition of any vintage I have owned. All voices pass tuning upon power up every time, all membranes are fully functional, zero issues. Since owning it I had a sample and hold chip replaced on one of the voice cards and I had to reconnect a membrane ribbon that had become loose, but that is it. Comes with the original brass foot pedals, the original (assume it is broken) power supply, and poster sized charts of this synthesizer's amazing architecture. I do not have the original case. I would REALLY prefer a local pickup here in Michigan as shipping (and I am assuming crating) this behemoth will be expensive. My asking price is $4750. I feel this is a very fair price considering all of the upgrades so there isn't going to be a lot of movement. Thanks very much and if you have any questions feel free to email me at mdykehouse.com

Anvil Case Foam Specs

Chris Ryan [21030691] · Mon, 11 Jun 2012 23:11:56 -0700

Deteriorating foam in the Chroma's Anvil cases is one of the banes of long-term owners. The material degrades to a sort of goo and, if the instrument is in the case during this process, the finish on wood parts in particular is damaged, necessitating a tedious cleaning process. Several owners have replaced the foam in their cases; Dave Blees [21030552, currently for sale] has kindly provided specifications for the replacement foam pieces. Thanks, Dave.

David Clarke [21030085++] · Tue, 12 Jun 2012 20:45:05 -0400

Dave B. - any chance that there would be pictures available for the site, to help illustrate how those separate foam pieces go together?

Dave Blees [21030552] · Tue, 12 Jun 2012 20:47:43 -0700

Good idea, D.C.! Since I still have the freshly-foamed case sitting here, and with my incomparable (or is it incompetent?) Photoshop skilz, that can be readily accomplished. Give me a few days....

Chris Ryan [21030691] · Wed, 13 Jun 2012 18:21:03 -0700

Picture received and added to the page. Thanks again, Dave.

Chris Smalt [21010280+] · Thu, 14 Jun 2012 20:54:18 +0200

The person who will reline my case is asking if the pictures are also available without the letters.

Peter-Jan Kleevens [21010014] · Thu, 14 Jun 2012 23:44:16 +0200

SUPER !! thanks :-)

Dave Blees [21030552] · Thu, 14 Jun 2012 14:14:36 -0700

AOK... Here's the plain, un-keyed version....

case_insides

Chris Borman [21030194+] · Thu, 14 Jun 2012 18:58:03 -0400

Great job Dave! THAT is some detail in the Chroma environment!

Chris Smalt [21010280+] · Fri, 15 Jun 2012 02:03:40 +0200

Yeah, I get nostalgia just watching those pix. I used to put that case on wheels and take it on the train!

Dave Manley [21030547] · Thu, 14 Jun 2012 17:18:47 -0700

Make sure the density of the foam is high enough - ie not too soft.

My chroma was damaged in shipment (apparently) by someone dropping the anvil case keyboard side down. The weight of the chroma caused the right side of the keyboard rail to contact the accessories box and bent the sheet metal right under the CHROMA label. I'd be tempted to remove the accessories box so this could never happen again.

If the idiot had dropped it any other way there probably wouldn't have been any damage. Murphy's Law at work I guess.

Rick Reed · Fri, 15 Jun 2012 01:18:48 -0400

I e-mailed an Anvil rep a few months ago about new foam, and I seem to recall a price less than $100. Calzone has a factory not far from me, so I could even have them glue them in for a bit more. Once I decide whether my Chroma is salvageable or not, I'll take that step to get the foam.

Any Chroma fanatics in Florida?

Technician Larry [21030198] · Fri, 15 Jun 2012 12:15:21 -0700

I just jumped into this thread so maybe some of this comment is redundant. Maxline Custom Cases in Wilsonville, OR is in the biz of making cases and they have supplied me with replacement foam in the past. They seem to be quite professional and I suspect they have identified and sourced the most suitable material for this application.

I struggled terribly with the process of cleaning up the old goo in preparation for replacing the foam. I scraped, scrubbed and sanded wasting significant amounts of time, energy and abrasives. Then I tried dissolving with all kinds of solvents. Nothing I tried worked hardly at all - isopropyl alcohol, acetone, paint thinner, etc. so I took the case outside and blasted it with a pressure washer. Come to find out, and much to my surprise, that the goo is WATER SOLUBLE. In a minute or two I had every last smear of goo completely removed. After leaning the case in an inverted position for an hour or so to let as much of the water drip out as possible I then set up the case on its side with a fan blowing on it for a couple of days. 100% results.

Lastly, the hard foam (structural for supporting the weight) in the bottom corners of the Chroma case I have here does not seem to be effected by the foam rot syndrome. I was able to leave that in place and it was not dislodged or damaged by the pressure washer treatment, though I was careful not to hit it directly with the PW.

Lars Johansson [21030632] · Fri, 15 Jun 2012 21:19:14 +0200

And this my friends....is why the case foam rot.

Damp, moist.

Jesper Ödemark [21010135] · Fri, 15 Jun 2012 21:35:59 +0200

So up in your region it ought to be OK... There and in the Nevada desert. :)

Side note: I'm so happy I saved my Taurus 2 before the goo below the panel killed the sliders.

Eric W. Mattei [21030443+] · Fri, 15 Jun 2012 13:19:10 -0700

My Chromas and I have lived in Los Angeles all our lives. It's dry here, but my cases were still hit by foam rot. Fortunately, my Chroma and Expander were not in the cases when the rot happened. I suspect that foam rot will happen sooner or later, no matter what the weather.

As for the Anvil Case Foam Specs, great idea! Wish I had them a couple of years ago when I re-foamed my cases.

Peter Forrest [21010096] · Fri, 15 Jun 2012 22:59:19 +0100

I agree - not damp, but the life-expectancy of the petroleum-based foam?

Chris Ryan [21030691] · Sat, 16 Jun 2012 14:39:19 -0700

I wrote to Anvil years ago (see Anvil Cases, June 1999) and received a response from someone at "Root International" whose url now redirects to Cases2Go; not sure what the relationship is with Anvil. The relevant bit: "Foam, being a petroleum product, deteriorates as a function of time. Heat can accellerate [sic] this process but it inevitably happens."

Re: Rhodes Chroma in Local Store

Go to first message in thread, May 2012

Chris Ryan [21030691] · Mon, 11 Jun 2012 23:15:44 -0700

I heard back from the seller and added his comments to the (new) entry for 21010037.

Chris Ryan [21030691] · Tue, 12 Jun 2012 23:39:28 -0700

This unit is now for sale on eBay: item #130708319168, €5,990.00, ends June 16, one offer.

Chris Ryan [21030691] · Tue, 26 Jun 2012 21:00:10 -0700

Relisted as item #130713926752 for €5,499.00, ends June 26. (The "1 offer" may be the seller or just a way of faking interest; I'm not sure.)

Chris Ryan [21030691] · Tue, 26 Jun 2012 21:01:34 -0700

Oops--ends July 6.

Michael Zacherl [21030253] · Wed, 27 Jun 2012 14:13:35 +0200

I just found this item# 130720491410 listed.

Circuit description/schematic corrections + repair help

Adrian [21040017] · Sat, 16 Jun 2012 00:02:03 +0930

Hi there,

I am repairing a number of faults on my new Chroma and thought I should start by thoroughly understanding the schematics and internal workings. One of the faults I'm looking at appears to relate to the switch/display matrix of the I/O board so (after starting with the CPU, address decoding and I/O strobe decoding) I'm now looking at the appropriate sections of the I/O board schematic (page 2) and the switch/display matrix section of the I/O board circuit description.

Firstly, it seems unlikely to me that J15-1 connects to pin 4 of Z13 and pin 10 of I2. That would make it the same as J15-8, which makes no sense for scanning the switch matrix. Referring to the assembly diagram I see J15-1 connected to pin 6 of Z13 and pin 14 of I2 instead, which makes sense since the matrix output is otherwise not connected to the switch matrix at all.

Secondly, in the circuit description I/O board switch/display matrix there are two references to "latch Z17", driven by /WRSDS. Z17 is a resistor array with no connection to /WRSDS, but Z12 fits the description much better. I am guessing this might be a transcription error from handwritten text, since 7 and 2 are very similar letters/numbers.

Could someone please check these two points and see if what I've said makes sense?

Is there a list of known corrections to the service manual and schematics somewhere?

Before I go any further I should point out that I've never owned or even used a fully functioning Chroma, so I may ask some questions that a real Chroma user would consider very basic :-) But I'm somewhat experienced with old synth repair and quite experienced with computer design.

As far as the actual problem is concerned, my I/O board fault symptoms are similar to those in Service Note SN3-007, however I've checked and Z39, Z40 and Z41 are all 74LS138, not 74S138. Specifically, what I'm seeing is the following:

  • The unit powers up OK but when left alone the Link Transpose Down 1 Oct flickers on and off, seemingly randomly. Occasionally Link Transport Up 1 Oct flickers on (but never at the same time as Down 1 Oct.) The frequency of flickering is usually fairly infrequent (i.e. every 10 seconds) although very occasionally it will happen a few times per second. Pressing Link Transpose buttons sometimes has an effect on the selected setting, sometimes not.
  • Link Unison acts similarly - without external intervention sometimes the LED is lit, sometimes flashing smoothly (~ 2-3 cycles per second) and sometimes off. The LEDs for No Link, Link Lower and Link Upper do not seem to turn themselves on like this. Pressing another Two Program Linkage button will have an effect but it's seemingly random which light will end up lit after each keypress.
  • Pressing Edit B pretty-much always causes the entire front panel to go blank - all LEDs and both displays go off, until another key is pressed. Pressing Edit B when the displays are blank causes things to light up for a split second then go blank again, pressing most other buttons usually (but not always) restores the LEDs and displays to normal operation.
  • Possibly related: when in Program Select mode, the program select number buttons 1-50 mostly work OK, but usually a second press on the same number (or, I suspect, a inadvertent double bounce on a key) will select a second program number. There is no clear relationship between the first and second program numbers, but it seems to be pretty consistent - e.g. second press on 6 always selects 16, then back to 6, then 16 etc. Many other numbers (but not all) show this same behaviour, but the 'second program' number is always consistent for a given 'first number'. Is this normal?

At this stage my suspicions are focussed on Z16, the 74LS244 octal buffer used to control putting key state information back on to B0-B7 (D0-D7 on the main CPU) when /RDSWB is low, or the switches themselves. I don't think Z12 or Z13 (matrix column latch and decoder) are likely candidates because they displays are both working just fine (although the first digit of the 8 digit display I2 is noticeably ghosted onto the 5th digit, so I suppose I could be wrong there.) The left panel switches that are behaving erratically are in matrix columns /STB2 and /STB3, but those columns' (right panel) program switches (11-15 and 16-20) don't appear to have the same issue - I'm not seeing any randomly selected programs. I'm not sure how to tell if Save One (on /STB2) or Save All (on /STB3) are being randomly pressed.

Are membrane switch failures common? Is this an expected failure mode?

Should I just bite the bullet and replace Z12, Z13, Z15 and Z16? Are 74HCT substitutes likely to be OK if I can't find 74LS?

In closing, this is unit 21040017 with a recently (~ 1 year ago) replaced SPSU and CC+, which I am told was working just fine a few years back. The previous owner had the SPSU replaced and the CC+ installed by a very reputable tech (Steve Jones from Sydney) and then he recapped and replaced the logic chips himself on the channel mother board. Unfortunately he is unable to continue with the repair process due to illness.

Sorry for the long detailed email; hopefully someone else more knowledgeable than I am finds this sort of electronic sleuthery fun too and will be willing to be a sounding board for my restoration efforts!

Now I am really looking forward to the day when my new baby sings again :-)

Cheers,
A.

Paul DeRocco [21030230] · Fri, 15 Jun 2012 10:58:38 -0700

Firstly, it seems unlikely to me that J15-1 connects to pin 4 of Z13 and pin 10 of I2. That would make it the same as J15-8, which makes no sense for scanning the switch matrix. Referring to the assembly diagram I see J15-1 connected to pin 6 of Z13 and pin 14 of I2 instead, which makes sense since the matrix output is otherwise not connected to the switch matrix at all.

You're right. J15-1 is strobe 5, which is driven from Z13-6.

Secondly, in the circuit description I/O board switch/display matrix there are two references to "latch Z17", driven by /WRSDS. Z17 is a resistor array with no connection to /WRSDS, but Z12 fits the description much better. I am guessing this might be a transcription error from handwritten text, since 7 and 2 are very similar letters/numbers.

Yes, again.

David Clarke [21030085++] · Fri, 15 Jun 2012 21:32:23 -0400

Is there a list of known corrections to the service manual and schematics somewhere?

No formal list (at least not that I'm aware of...)

  1. The unit powers up OK but when left alone the Link Transpose Down 1 Oct flickers on and off, seemingly randomly...

I have seen a couple Chroma's develop a week button or two, where the membrane itself is just on the edge of making connection most of the time. When the temperature/humidity changes a bit, it will get temperamental, and start to act like someone is pressing that button randomly. If you then go and apply a lot of pressure to it, rub it, otherwise disturb it, it will behave for a while.

  1. Pressing Edit B pretty-much always causes the entire front panel to go blank ...

While some of the other behaviours noted could be explained with the mechanical button issue (above) - this behaviour would indeed seem to be something else.

The only (intended) functionality that I'm aware of that will make the whole panel go blank (and stay that way) is if you press one of the Tape interface buttons (like "Load All"). Even then, it would only stay all dark until you hit the button again.

If the 'Load All', 'Save All' or similar buttons cause unexpected bad (or the same behaviour as 'Edit B', then there might be some sort of short/accidental connection between these.

  1. Possibly related: when in Program Select mode, the program select number buttons 1-50 mostly work OK, but usually a second press on the same number (or, I suspect, a inadvertent double bounce on a key) will select a second program number...

This is most likely not a problem but instead is an intended operating mode of the Chroma. Specifically, if you press the same program select button a second time it will go to the 'last' program. If you have edited the current program, then pressing it a second time will toggle back and forth between the original and edited patch. If you just changed patches, then pressing the same button again will toggle the selection back to the last patch.

You had noted odd behaviour with Link Transpose Up, Link Transpose Down, and Edit B.

It may be just coincidence, but per the Service Manual (Interconnection Diagram 2), these signals are all associated with the SW6 strobe on the left panel switch matrix.

- but not with 'Link' functions (Link Upper, etc.)

... (although the first digit of the 8 digit display I2 is noticeably ghosted onto the 5th digit, so I suppose I could be wrong there.)

The display is normally quite clear (with no 'expected' ghosting) - and so if you are seeing an obvious duplication of a character, then that may indeed be a legitimate observation of something untoward.

Chris Ryan [21030691] · Fri, 15 Jun 2012 18:39:11 -0700

No formal list (at least not that I'm aware of...)

Any opinions on a good way to track these corrections? A list, annotations on the schematic PDFs, other options?

Paul DeRocco [21030230] · Fri, 15 Jun 2012 21:20:09 -0700

This is most likely not a problem but instead is an intended operating mode of the Chroma. Specifically, if you press the same program select button a second time it will go to the 'last' program. If you have edited the current program, then pressing it a second time will toggle back and forth between the original and edited patch. If you just changed patches, then pressing the same button again will toggle the selection back to the last patch.

That's the "safe buffer" function, which is mentioned but not really explained in depth in the manual. Selecting a program when the last program had been modified copies the last program into the safe buffer. Selecting the same program again, before modifying it, would therefore be superfluous, so instead it fetches the contents of the safe buffer; it even restores the old program number.

Similarly, storing a program puts the old stored program into the safe buffer. Storing the same program again would therefore be superfluous, so instead it stores the contents of the safe buffer, undoing the previous store. This applies to the [STORE] [STORE] function, which stores under the current program number, as well as [STORE] [n] where n matches the current number.

One consequence of this algorithm is that any of the following sequences will swap a modified program with a stored program:

  • [n] [STORE] [n]
  • [n] [STORE] [STORE]
  • [STORE] [n] [n]

You had noted odd behaviour with Link Transpose Up, Link Transpose Down, and Edit B.

It may be just coincidence, but per the Service Manual (Interconnection Diagram 2), these signals are all associated with the SW6 strobe on the left panel switch matrix.

The first place to look for shorts is where the tails go into the connectors. I suggest carefully popping open the connectors, removing the tails, brushing them off, blowing air into the connectors, putting the tails back in, waving a dead chicken over it, and hoping for the best.

Adrian [21040017] · Sat, 16 Jun 2012 19:21:25 +0930

The first place to look for shorts is where the tails go into the connectors. I suggest carefully popping open the connectors, removing the tails, brushing them off, blowing air into the connectors, putting the tails back in, waving a dead chicken over it, and hoping for the best.

Thank you David and Paul - you were both spot on: I unplugged and tested J14 and it turns out that SW6 (J14-9) and STB1 (J14-2) are shorted on the switch panel itself. Is it possible/recommended to peel off the front panel overlay and fix the shorted switch? With a heat gun? I believe those sort of membrane panels are usually not removable :-( Are there replacements available?

Thanks again,
A.

Adrian [21040017] · Sat, 16 Jun 2012 20:44:27 +0930

Also, having just disconnected J14, J15 and J16 and powered it back on the flickering LEDs have stable now, and the 8 digit LED display no longer ghosts, so it's pretty likely that really is the cause.

David Clarke [21030085++] · Sat, 16 Jun 2012 11:14:08 -0400

... Is it possible/recommended to peel off the front panel overlay and fix the shorted switch?

... Are there replacements available?

Check out the following earlier discussion on the list: How does the control panel work?

At that time John Leimseider [21030434++] noted he still had some spare panels - and since that was only in January, chances are good that some replacements still exist.

Good luck with your repair.

David Clarke [21030085++] · Sat, 16 Jun 2012 11:04:34 -0400

...Any opinions on a good way to track these corrections? A list, annotations on the schematic PDFs, other options?

If it's not too much effort to achieve, red-lines on the schematic itself are usually a good way to show the markups.

I suspect that changes may only occur sporadically, just as people stumble across them (vs. us knowing all the changes right now).

In addition to the changes already noted I also had the following penciled in:

On sch. page 6-10 (Dual Channel Board Schematic 1):
  • The 'unused gates' at the bottom of the page should be Z1E and Z29A (respectively, instead of Z1F and Z29B, as currently shown).
  • In the B-VCF block, the upper left-most op-amp should be designated Z29B (vs. Z29A).

It should be confirmed by others from the list first, but on sch. page 6-21 (Balanced Output Schematic and Interface Cable Schematic) I believe the pinout of J28 is marked incorrectly. I think (to ensure the proper output polarity) the pinout should be "1 2 3 4" vs. the currently illustrated "4 3 2 1".

David Clarke [21030085++] · Sat, 16 Jun 2012 12:05:00 -0400

... it turns out that SW6 (J14-9) and STB1 (J14-2) are shorted on the switch panel itself...

Thinking about this a bit more:

SW6 and STB1 intentionally meet at the "Main Transpose Up" button - so assuming there's no other physical reason to suspect a short elsewhere (e.g., a piece of metal stuck through the panel, clear mechanical damage to the surface of the panel), the most likely location of the short is the switch itself (e.g., stuck closed).

One debug step will be to see if you can unstick the connection there. While admittedly not hi-tech, one approach to this will be to use a sticky substance to grab the panel so that you can 'pull' on the switch location.

Using 'mounting putty' (such as those things noted below) could be used. These would allow you to temporarily stick to the panel, and would have enough adhesion so that if you pulled on it quickly it would tug on the panel (vs. just pulling off the putty) or pulling slowly would allow you to see if the detected short is 'cleared'. While this wouldn't necessarily 'fix' the problem, it would help isolate the location and then let you determine what alternatives you might want to consider (e.g., attempt to slightly separate the layers at that switch by getting into the edge of the panel at the LED hole, etc.)

John Leimseider [21030434++] · Sat, 16 Jun 2012 08:50:07 -0600

Thank you David and Paul - you were both spot on: I unplugged and tested J14 and it turns out that SW6 (J14-9) and STB1 (J14-2) are shorted on the switch panel itself. Is it possible/recommended to peel off the front panel overlay and fix the shorted switch? With a heat gun? I believe those sort of membrane panels are usually not removable :-( Are there replacements available?

I have a couple of replacements available for the Chroma and Expander ... I can be reached at [address removed]

Attention Russ Lyons - questions relating to Chroma panel repair

See thread How does the control panel work, January 2012

Adrian [21040017] · Sun, 17 Jun 2012 19:18:40 +0930

Russ Lyons [21030574] · Wed, 4 Jan 2012 14:47:09 -0500

I peeled the whole patch/param section of the overlay off of a Chroma, drilled holes through the aluminum panel, mounted microswitches under each membrane button and hardwired the matrix to the I/O board. Then I glued the overlay back down over the swiss cheese. It did work well after that, but I was younger and am wiser now.

Hi Russ,

Can you confirm exactly what you mean by "I am wiser now" in relation to microswitch substitution on a Chroma front panel? Was it tricky, time-consuming, or something else? My left front panel membrane switches are most likely unrecoverable, and so I'm either going to have to import a new panel from overseas (expensive - I'm in Australia), or try this. Since my panel is effectively useless as it stands I figure I don't have much to lose. My right panel is working just fine, so I only have the left panel (21 switches) to do.

I am considering using switches like these (because I have 100 or so spares from another project and I can make up a PCB for mounting them on the underside of the front panel.)

Tayda Electronics: Tact Switch 12*12mm 12mm Through Hole SPST-NO

How wide were the holes you drilled? I am also wondering whether or not I could use a depth-adjustable router to carefully "drill" the holes in the front panel from the rear, thus negating the requirement to remove and re-attach the overlay. Any opinions?

Thanks,
A.

Chromatropolis

Tom Hughes [21030251+] · Wed, 20 Jun 2012 17:20:34 -0400

Hey Everyone,

I just got around to posting some info and pictures about my Chroma, Expander and Enabler, and I thought some of you might find it interesting - For Musicians Only: Welcome to Chromatropolis!

chromatropolis

Marais · Wed, 20 Jun 2012 17:37:33 -0400

A for Awesome!

Rick Reed · Wed, 20 Jun 2012 22:35:41 -0400

Well, I'm officially jealous!!

Werner Schöenenberger [21010114] · Thu, 21 Jun 2012 18:28:53 +0200

Hi Tom,

Wow very impressive. Can you control Chroma and Expander with the Enabler?

Cheers,
Werner

Tom Hughes [21030251+] · Fri, 22 Jun 2012 12:50:53 -0400

Right now, it’s just set up to control the Chroma. I discussed possibility of controlling both the Chroma and Expander with Randel, and it’s certainly possible. When I’m playing the Chroma and Expander together, I usually have them each on different patches that complement one another, so I probably wouldn’t want the Enabler to control both simultaneously. But it would be nice to get it set up to switch between the two quickly and easily.

Marais · Fri, 22 Jun 2012 13:34:27 -0400

a switch box would be a good idea, I think I mentioned something to Randel about this as well when I had my Expander.

Werner Schöenenberger [21010114] · Fri, 22 Jun 2012 20:29:29 +0200

Hi all,

I think, the solution would be to have an instrument ID in the sys-ex data stream. But this needs a change of the CC+ software (if it is not already implemented). Then the Chroma, Expander and Enabler would need a function to configure this ID, where the Enabler has to support more than one device. And of course, the Enabler would need a switch to switch between the instrument IDs.

Jesper Ödemark [21010135] · Sat, 23 Jun 2012 00:22:21 +0200

How's the enabler hooked up? Through the old interface port? Can't a simple old printer switch work to switch between chroma and expander? I did some mods on one to allow midi control vs. Caterpillar control of my EDP synths without unplugging.

David Clarke [21030085++] · Fri, 22 Jun 2012 19:23:51 -0400

I think, the solution would be to have an instrument ID in the sys-ex data stream. But this needs a change of the CC+ software...

I believe that the Enabler communicates its parameter settings to the Chroma/Expander via MIDI Continuous Controllers (vs. sysex), and so (in concept) it would just be a matter of having the Enabler be able to select (under operator control) which MIDI channel it is communicating on.

That way the messages would be go to the Chroma, Expander, Chroma #2, etc.

Marais · Fri, 22 Jun 2012 19:50:40 -0400

The midi channel on the Enabler is preset to one channel.

David Clarke [21030085++] · Fri, 22 Jun 2012 20:10:54 -0400

I'd have to assume it could be made a performance-controllable item (with some development). That said - the other approach that would require no modification of the Enabler itself would be to insert a MIDI mapper between the Enabler and the rest of the MIDI network. That way you could remap the communications to/from the Enabler as desired.

Re: Chroma 21030552 For Sale

Go to first message in thread, May 2012

Chris Ryan [21030691] · Wed, 20 Jun 2012 20:44:03 -0700

Sold for USD$4,500.00.

CPS Kit running status

Chris Borman [21030194+] · Thu, 21 Jun 2012 06:46:34 -0400

Good morning all,

I have one extra Chroma Pressure Sensor kit built and ready to go from the last build and the major parts (PCB’s and Mylar Sensors) to build 10 additional kits.

Lars Johansson [21030632] · Sat, 23 Jun 2012 23:34:55 +0200

Howie,

this [first post in this thread] is the latest message from Chris regarding another run of CPS-kits.

Technician Larry [21030198] · Sat, 23 Jun 2012 14:59:54 -0700

I might be a potential customer for one of these if I decide to rise to the occaision and build out the unit I have here. It needs the CPU and power supply and a refinish job, but would then be near perfect - no observable wear and tear on the keys, switches, contacts, connectors, case woodwork or road case. All accesories present. I'm skeptical that after completion I would have to keep it rather than sell. My life would be easier if I just sold as is tomorrow. I'm open to persuasion if anybody has an opinion they want to share.

Chris Borman [21030194+] · Sat, 23 Jun 2012 18:27:41 -0400

Don’t sell your Chroma. Mine has not made a peep in quite awhile. Somewhat boots up and at least emits MIDI data. I’ll certainly get around to fixing it but will never sell it. Still hurting from selling my Oberheim Xpander... Let me know I got PCB’s and mylar sensors for ten more kits.

Brian McCully [21030361] · Sat, 23 Jun 2012 20:55:59 -0700

Dee - I've owned my Chroma for 30 years or so. Never thought much about selling it. Updated all of it, and while it sits for a bit waiting to get its due playtime, I'd have to say that it's worth the ownership - regardless of all my financial or life's frolics or turmoils. Nothing sounds or plays like it, in its entirety. Period. There are soft-synth emulations or samples available from time to time, but never 'it'. Kind of like the smell of an old VW, there's a certain essence. I play Chapman Stick - it's a unique instrument - and like the Chroma whenever someone tries to emulate its sound, everything just falls short. It's just unique. You can still buy a Stick, but a Chroma - that's a rare purchase. Easier to play a Chroma btw.

The brain and PS updates are very much worthwhile, as they are like re-building and reinforcing the unit from the ground up. Cost-wise very reasonable...Two Major buy-ins - no battery leakage, and no PS hum.

The polyAT mod is one of those 'I should have it too' things that will demand your time/energy capabilities in 'programming, then playing'. Personally I've been really busy with other musical endeavors, but my quick take on the AT retrofit is that is cool but I haven't yet found a very musical application for it. It's uneven on my Chroma, and while it can be very dynamic it's not totally controllable like a monoAT is. I'd love to hear some musical examples of what Chroma-ites have come up with. Seems like there are lots and lots of possibilities, like everything the Chroma offers, anyway.

IMHO, YMMV, yadda yadda, hope it helps you keep on holding on, -Brian

Technician Larry [21030198] · Sun, 24 Jun 2012 00:07:07 -0700

Hi Brian: Thanks for those words of wisdom. I'm inclined to agree - I'll likely follow that advice. I could even build a new case from some wood like I used for these MG1 / Rogue end panels. What do you think?

wood

Brian McCully [21030361] · Sun, 24 Jun 2012 08:33:15 -0700

Nice! What kind of wood is it? The end pieces on my Chroma are all bleached out and marred from the foam-rot-removing exercise. Someday, I'll sand and re-do them,but it's at the bottom of a very long to-do list.

Hey - one more quite obvious thing but indeed worth mentioning - the Chroma is still quite alive and thriving thanks to some very talentedindividuals within this group. I have a few other 'classic' synths that have minimal to zippo support, i.e. this site rocks in comparison!

Technician Larry [21030198] · Sun, 24 Jun 2012 09:35:07 -0700

That is Black Walnut from the edge of the tree such that the transition from heartwood to sapwood is featured in the color contrast. I've never bought into the highest grade and most expensive lumber that is milled to remove all the sapwood and usually most of the high contrast figuring with it. Each perfect piece, void of any deviations that add character or identify it as a "tree part", looks just like the next piece. I like working with wood that still looks like it is part of a tree and that, by means of unique features, looks different than the next piece and the piece after that.

Black Walnut is especially suited for projects that can display the heartwood / sapwood transition as the contrast can be marvelously vivid and, as in the case of the end panel picture below, sometimes quite complex. If the walnut tree is killed and immediately milled when the wood is totally green (unseasoned) the contrast is even more vivid. As it seasons, that near snow white sapwood pictured here) will darken to various shades of gray, brown and yellow.

It would please me to see a trend of integrating fine woodworking with electronic musical instrument design. The two art forms seem like a natural combination, but maybe that is just a side effect of my addiction to whiffing saw dust. Love the smell of Black Walnut or Cherry, etc. running through the planer.

One of these days I'll put the belt sander to the Chroma case and see what kind of quality was in the wood they selected for this classic design a few decades ago.

Brian McCully [21030361] · Sun, 24 Jun 2012 16:00:39 -0700

When I first saw your last picture I thought of bacon for some reason. ;>)

At our last house we had a huge black walnut tree in the back yard. The squirrels would chew off the big sticky green nut clusters, and they would smack on the roof. Big thunk! And then the roots from the tree clogged our main sewer outlet out of the house and ended up costing us $4K+ to figure it out and repair it. It was the day my wife was due - she was not happy being nine months pregnant with no plumbing. So black walnuts don't bring me great memories, but the guys who hauled away the wood were quite pleased. At least I didn't have to sell the Chroma to pay the darn plumbers.

wood2

Soon to be a new Chroma owner...but too late to get a CPS kit?

Howie Shen [21030552] · Sat, 23 Jun 2012 14:29:29 -0700

Hi all,

I've just joined this list as I'm about to become a new owner of an absolutely beautiful Chroma. I'll add my information to the instrument registry once I have the instrument, but wanted to ask is it too late to get a CPS kit? Part of playing "catch up" with all of the information on this amazing site is not being aware of when update kits were first offered and whether they are still available in June 2012. Fortunately the Chroma I am purchasing already has CC+ and SPSU kits installed, but I REALLY want to get a CPS kit as well.

I was disappointed today browsing through the April 2012 archives to see Chris Borman announce that he was down to his last 8 kits.

Chris, are they really all gone by now with no plans (or ability) to make another that I could buy?

Or did anyone buy a spare that they would be willing to sell me?

I'm thrilled at the thought of owning a Chroma after many years of admiring the instrument from a distance, but will be annoyed that I joined the group literally a few weeks too late to grab a CPS kit to install.

Much thanks, Howie

Re: Programming Manual on eBay

Go to first message in thread, May 2012

Chris Ryan [21030691] · Wed, 27 Jun 2012 23:13:50 -0700

I've had a chance now to flip through this side-by-side with my Programming Manual (with the glossy cover). I didn't do this in word by word or even page by page, but as far as I can tell, the content is identical. The paper quality of the interior pages is about the same, and the reproduction quality isn't that good in either manual. Just guessing, but perhaps later in the instrument's production run producing the glossy covers was deemed too expensive or slow, and they went with a plain cover. Well, one more bit of Chroma trivia.

programmingmanuals

WTB: Chroma T-Nuts & screws - help needed !

Philippe [21010227] · Fri, 29 Jun 2012 00:58:17 +0200

Hi list,

I need help from the members of the list living in the States. My Chroma is missing a few pieces. T-Nuts such as these : 6-32 Pronged Tee Nut (100 pieces)

and some screws such as these : Stainless Steel Machine Screw, Black Oxide Finish, Pan Head, Phillips Drive

Problem is the sellers won't ship outside of the U.S. Would any of you living in the States be willing to order them for me ? and I would pay them in full to you upfront + shipping of course. Then after reception you would ship only a few to me and in exchange you can keep the 90% to 95% of the rest free for you for the favor. Please contact me off list if interested.

Regards,
Phil

Philippe [21010227] · Fri, 29 Jun 2012 12:30:10 +0200

Problem solved !
Thanks to all.
Phil