Skip Navigation.
Section 0

ChromaTalk Archives: March 2013

Re: Chroma and Expander

Go to first message in original thread ("Seattle - Polaris and other ARP classics for sale"), February 2013

Robb Witt · Fri, 1 Mar 2013 07:03:21 -0500

All -

The "earthtone" overlays were never a production part. Any panels out there were made as prototypes... and never implemented in production. If you track through the "color scheme" materials on the site you'll get this, but perhaps it's not as clear as it could be.

The particular Chroma under discussion may be my old unit, assembled out of reworked and discarded parts when I worked at the Woburn facility. It had "earthtone" panels and was sold to someone in the Denver area in '92. It last surfaced owned by a Leonardo Ascarrunz who was trying to sell it in 2010. The description more or less matches, and the fact that some of the keys are discolored certainly does because, as noted, mine was made from scavenged parts... and thus also never had a serial number. I think Leo had said he'd replaced the power supply as well. If so, treat her well... I've long regretted that sale.

Conversely, we did supply a very few "earthtone" overlays as gifts to special customers or dealers... and those pop up from time to time. Perhaps someone made that mod to some other unit.

Best of luck with it.

Jesper Ödemark [21010135] · Sat, 02 Mar 2013 15:00:27 +0100

Brian McCully skrev 2013-02-28 23:15:

--- I was told it had just 'smoked up' before I purchased it (the salesperson said it was still sounding fine even while it smoked) so they just yanked the 115VAC plug and put it in the back room of the store, and I think I bought it the same day. I have not attempted to turn it on, but it sure smells like a burn in the PS area. Visual internal inspection didn't yield a clue about what fried. I'll see how far I get with repairs and some other updates, then consider the next options.

Unplug the PSU from the rest and fire it up. It might give a clue to what happened. If all seems OK, then get a good replacement PSU and trash the old one...

Good bargains, finding an expander and a halloween Chroma the same day! :D

Brian McCully [21030361] · Mon, 4 Mar 2013 21:15:43 -0800

Thanks for the advice, Jesper. Got one of Luca's SPSU's on order, regardless. Just in case! -Brian

Go to next message in thread, April 2013

CC+ Expander (only?) implementation - voice allocation, spill-over

Brian McCully [21030361] · Fri, 1 Mar 2013 09:15:59 -0800

I've been reading up on the Expander, via the forum discussions and the docs section (i.e. the Expander performance manual). And reviewing the CC+ implementation - as to whether the CC+ thinks it's inside of a Chroma or Expander. Wow - what a wealth of information - it's easy to get lost! I have a couple of thoughts, then questions.

Referring to the discussion from the Jan 7, 2012 question of whether the Expander is a 4 oscillator voice [see "squeeking oscillator"], then reading back further to the web-linked Tony Williams interview comment of the Expander functionality as basically linking voices - but not expanding (or spill-over past the max voice allocation, relative to splits and linked voices). Linking = layering (vs. increased polyphony which is what one might consider the term 'expander').

Considering the Expander in a pre-MIDI mindset, without hooking up the Expander to the Apple IIe for however that system allocated voices(?), it's just a stand-alone tone module, in pre-MIDI larger than 19" rack space format (like today's rack tone modules). Tony's comment was that the old brainboard processor didn't have enough firmware headroom to allow for expanded polyphony functionality (voice spill-over).

That said, I appreciated Dave Bradley's [16330135] 14 voice of polyphony work-around (link to silent mono voice program), but then I was thinking "how do I do a Set Split on the Expander (only hooked up via CC+ MIDI, not to a 'host' Chroma), when it's a panel button 'special function' and there's no keyboard". Do I always have to copy a Chroma split patch over to the Expander via sys-ex, then reverse the Hi and Low link assignments? Or can I hit the Special Function key, and then send it a MIDI note and the split is set? (Sorry I haven't tried this yet...still in research mode here.)

Next question, when the CC+ is in 'Expander' mode, what does it do differently?

Without quoting the CC+ docs directly, operationally does the voice allocation only 'layer' by default, or (what may have been the eventually intended operation) now do a voice spill-over for the Expander operation (i.e. relative to the host Chroma CC+ mode, which wouldn't apply)?

A voice spillover (or e.g. odd/even note triggering split to separate modules, etc.) can be done via MIDI using apps like MAX or the programming portions of Logic, Cubase, etc. But it would be easier to deal with (if the CC+ firmware allowed, or maybe it already does this) on a per program basis (considering links and their voice allocation) in the Chroma, and/or Expander, and/or possibly in Paul's forthcoming Digital Chroma hardware or plug-in.

Many years ago when I first got ahold of a 2nd Chroma, the intended primary use was for increased polyphony (Rhodes patch!), secondarily for layering. That Chroma never fully functioned, oops. Now that I have an Expander, I see that the increased polyphony mode was not implemented in production units. I'd think that with a CC+, whether you have a linked 2nd (or 3rd) Chroma, or an Expander, that a 'voice spill-over polyphony increasing' function would be a good thing. Sorry for the length of the post. -regards, Brian

Paul DeRocco [21030230] · Fri, 1 Mar 2013 09:42:11 -0800

Increasing polyphony is what one would obviously want in an Expander, but it's not easy. You need a dedicated interface, whose language is quite different from MIDI, because the master has to do the voice assignment, and tell the slave exactly what to do. The Single modes for the sweep generator would be tricky to implement, too. A protocol would be needed for the master to tell the slave to do an auto-tune, and then find out if any boards failed. It's not an easy drop-in to the existing architecture. And it would still be up to the user to manually match the volume and tone controls.

As to keyboard splits, the original architecture required them to be done in the keyboard controller. For linked sounds, the Expander just listens on two channels. It's up to the controller to do layering, splitting, octave transposition. I don't know if the CC+ has any improvements in this area.

David Clarke [21030085++] · Fri, 1 Mar 2013 14:35:18 -0400

There's nothing overly 'different' about an Expander.

To a very high degree, if you were simply to chop the keyboard off the front of a Chroma - you'd have an Expander.

For all intents and purposes, the Expander is a keyboard-less Chroma.

That means the things you should expect to be able to do with an Expander would essentially be the same things you should expect to be able to do on a Chroma without a keyboard.

... Next question, when the CC+ is in 'Expander' mode, what does it do differently?

You'll notice when comparing the left side of the front panel of the Chroma and the Expander that there are LEDs in different positions, with different functions (e.g., no transpose or link uppper/link lower functions on the Expander).

The code needs to know about those differences in order to ensure the right data is sent to the panel and make the correct lights light up.

With the original CPU board, the choice of Expander or Chroma was hard-coded in the EPROM image. If you used the Expander chips - it would expect the LEDs/settings of an Expander. If you used the Chroma chips - it would expect the LEDs/settings of a Chroma.

The CC+ configuration setting simply allows one set of code to handle either the Expander or Chroma case without having to change EPROMs (e.g., a matter of convenience).

The CC+ does not add any additional voice-allocation modes to increase polyphony - for exactly the logistical reasons noted by Paul.

Brian McCully [21030361] · Fri, 1 Mar 2013 12:56:04 -0800

There's nothing overly 'different' about an Expander.

Okay it's clearer for me now - no surprises from all I've read to date, thank you.

I still have the question - on the Expander, how does Set split work for getting a keyboard split point (sans keyboard), via external MIDI?

So maybe a possible way to link with pseudo-polyphony expansion for real-time play via MIDI only, is to play one handed per Chroma instrument, with linked sustain pedal messages. ;>) Or...duplicate one or more patch banks of the Master Chroma on a linked slave (2nd Chroma or Expander) and create a Mac or PC MIDI 'helper app' for the Master that would emulate (convert) the panel functions to parameter functions - such as Master front panel octave transposition to parameter 26 on the slave (huh - ok, both A and B status' need to be considered too...). But I don't see any 'link transpose' type messages listed in the MIDI controller map table.

Also the app could convert the sys-ex data for mono/poly status to interpret the patch's voice allocation scheme, and trigger voice spill-overs on the slave for anything greater than the master's patch voice allocation. In various cases like the 'Single modes for the sweep generator' - it may just not be feasible with MIDI alone - but in reality there may not be many playing applications with patches that demand increased polyphony.

There was recent discussion about firmware upgrade for clocking (p28 sweep clock source) [see CC+ firmware release 217: User-defined MIDI Velocity Mapping, Auto-send of Patch Parameters and more] - which would be as accurate as the separate MTC feeds to both Master and Slave. A mode for Auto-tune send and failure response would probably be of less importance, unless you were playing live, but I can't imagine anyone lugging these instruments to gigs anymore.

Thanks again for the clarification. -Brian

David Clarke [21030085++] · Fri, 1 Mar 2013 20:27:32 -0400

... on the Expander, how does Set split work for getting a keyboard split point (sans keyboard), via external MIDI?

...

... But I don't see any 'link transpose' type messages listed in the MIDI controller map table...

(Note: My keyboards aren't accessible at present, so I can not verify my comments via a quick test - but the following outlines what I would expect to be the case. I anyone sees different behaviour or has corrections - please feel free to offer them).

While perhaps not 100% strictly the case, it is useful to consider the Chroma to be two separate functional blocks - a keyboard module (to generate note on/note off/pressure data) - and a sound generation module (to take key data and make sounds.)

The 'split' and 'transpose' data affects the former (the keyboard module) - not the latter.

Lets look at a 'transpose' (for instance).

When you have a transpose, it is the KEY data which changes.

For instance - if you play C2 - but have 'transpose up 1 octave' selected, then the output of the 'keyboard' functionality is C3.

The sound generator has no concept of the 'transpose button' being pressed or not. It can't tell (nor does it care) whether you played "C2, transposed up 1 oct", "C3", or "C4, transposed down 1 oct". In all cases, by the time the keyboard data gets to the sound generator, it is the exact same information (a C3).

That's why you don't see (for instance) a MIDI transpose message on the Chroma. The transpose function deals with the notes that are generated from the keyboard on the Chroma, not how the notes themselves are interpreted by the sound generating electronics.

A similar argument applies to the 'set split' point.

A split has signficance if you are playing a keyboard. Specifically, it will determine when the key data is sent to one sound destination (instrument) or another. That split data though doesn't actually 'change' the sound patch.

Using this analogy, you can consider a Chroma to be a Keyboard + Sound Generation Module. You could then consider the Expander to just be the Sound Generator Module. Under that description it may be a bit more clear how/why the split and transpose data really doesn't have the same signficance for the Expander.

Brian McCully [21030361] · Fri, 1 Mar 2013 18:41:45 -0800

Oh! Okay...I think I'm getting it, thanks. Sorry I still don't have the Expander hooked up via MIDI (I just put it back together), but if I get this all straight it'll save me a lot of time (and I guess it applies to a Chroma as a slave device as well...).

So whenever a split program is saved in the Chroma, and then say loaded into the Expander and played via MIDI from another MIDI keyboard, then it will be up to whatever the split points, transposition, etc. are on that 'master' keyboard to determine what is played on 2 separate Rx channels of the Expander? Only if it's played by the master Chroma (using the same patch on the master), will it react like the original split/layered patch, etc.?

By default is the Expander always in two channel RX mode (for a 'split' sake), or only when it's been loaded with a Chroma's split or layered program, and/or does it operate according to the global 'P5 Instruments available' value - which may require voice allocation?

I will need to check out Omni on/off related info - with all this in mind.

If all this info is written up somewhere, please point the way to the reference(s) - I still have yet to find it all, obviously. I will poke through the Syntech manual write-up next, as it applies to some of the same basic functionality. many thanks! cheers, -Brian

David Clarke [21030085++] · Fri, 1 Mar 2013 23:31:18 -0400

... it will be up to whatever the split points, transposition, etc. are on that 'master' keyboard to determine what is played...

Generally speaking, yes.

... and/or does it operate according to the global 'P5 Instruments available' value - which may require ... voice allocation?

Setting MIDI aside for the moment:

- as a RECEIVER of data, the Chroma (or Expander) can always have up to 8 'instruments' defined. Each instrument will have its own assigned patch. The Chroma's voice allocation rules will come into play to try to best service the needs of any/all defined instruments.

- as a SENDER of data, the Chroma can send information for up to 2 'instruments' - a 'main' instrument and a 'link' instrument (if there is a link).

The "P5" setting isn't a Chroma setting (per se); rather, it is for the MIDI interface. In that context it really controls how many MIDI channels are allowed to be simultaneously supported by the interface (for the receipt of MIDI data). By convention, 1 MIDI channel gets assigned to a dedicated Chroma instrument. So - you if you have P5 set to "6" - could you have up to 6 simultaneous 'instruments' being played on the Chroma by MIDI.

... I will need to check out Omni on/off related info - with all this in mind.

Omni On/Off will be a MIDI concept and not a Chroma concept - and so (in general), the definition of what will happen in those modes is defined by the MIDI implementation.

If all this info is written up somewhere, please point the way to the reference(s)

As the topics you have questions about generally refer to interfacing to/between Chromas, I would suggest that the most appropriate single reference would be the Chroma Interface Manual, and in particular the "Chroma Structure" section. While this talks about the Chroma Port on the keyboard and not MIDI, that is the basic communication interface on the keyboard. The Syntech MIDI interface (as an example) can be though of just as a converter between what is documented in the Chroma Interface Manual and MIDI. The elements presented to that interface are reflective of how the data is managed inside the Chroma too.

SPSU kit on Expander

Luca Sasdelli [21010226] · Fri, 01 Mar 2013 20:31:28 +0100

Hi all,

does anybody have some pictures and/or recommendations about installing the SPSU kit on the Expander? Unfortunately I don't own one, but I've sold several kits to be installed on Expanders and it was told me that it did fit quite properly.

Is it true? :-)

Eric W. Mattei [21030443+] · Fri, 01 Mar 2013 14:55:52 -0800

Hi Luca

Here are a couple of pictures, but it's not a very good camera. I left the Expander open for now, so if you need a close up of something, let me know. If these pictures are useful to you, download them because eventually I'll want to delete them.

005_front_Cropthumb

010_back_Cropthumb

I got an SPSU for my Chroma and my Expander. They "fit" in most every sense of the word, but my technician did report some minor issues:

On one of the supplies, the color coding for the wiring was not consistent with the installation page. I think that was the supply that went into the Expander.

On both supplies, some of the wiring on the SPSU was too short.

On the Expander, there was a lot of noise after the SPSU was installed. This noise was not present before, so presumably this was caused by the SPSU. BUT, the wiring running from the EQ Board to the back panel was only grounded on the back panel end. Grounding it on both ends fixed the problem. He did not experience this problem on the Chroma. The corresponding wiring on the Chroma was grounded on both sides.

Everything else was fine.

And don't get me wrong here. My Chroma and Expander now weigh less, they should consume much less power (witch is reassuming since I'm added devices to the system), they should be more reliable and I'm not baking the CC+ and all the antique components.

My compliments to the chef!

Luca Sasdelli [21010226] · Sat, 02 Mar 2013 19:34:56 +0100

Many many thanks, Eric!

I'll take your kind suggestions into account and I'll provide longer wirings and double-check the color coding with the page descrption.

Eric W. Mattei [21030443+] · Sat, 02 Mar 2013 12:54:01 -0800

You're welcome Luca and Brian McCully [21030361] (per your off list email).

It was good timing since my board is still in the shop so the studio is down. Also, a variable speed reversible drill with a Phillips head bit reduces the pain of Chroma cracking. But don't use it to drive the screws back in! That's better done by hand so as to avoid stripping the screws.

Enjoy.

Eric

For sale origional rhodes chroma computer Board firmware V1.4 chips complete.

Leon van der Sangen [21010301] · Wed, 6 Mar 2013 19:16:34 +0100

Hi,

I have a rhodes chroma computer Board firmware V1.4 for sale. It’s complete and functioning a year ago since then it’s out of the chroma.

I don’t know what a decent price is. Maybe someone can tell me.

If someone is interested please let me know, i live in the netherlands international shipping is no problem.

Cheers,

Leon

Chris Ryan [21030691] · Wed, 6 Mar 2013 18:40:56 -0800

Have a look at Price History: Other Items which includes several past sales.

Retail Prices

Chris Ryan [21030691] · Wed, 6 Mar 2013 20:55:59 -0800

New on the site this month is a page with several sources of retail prices, including price lists from the U.S. and Canada and a magazine ad from the Netherlands—the latter thanks to Erik Vellinga [21010268]. If you have any further information, feel free to send it on.

Paul DeRocco [21030230] · Wed, 6 Mar 2013 21:06:04 -0800

Wow. The Computer Interface Cable was $135, thirty years ago. Let's hear it for MIDI.

I'm also surprised to see a $425 price for the pressure sensor. I didn't realize this ever got into the catalogs. I thought only a few were made by the engineering department.

Chris Ryan [21030691] · Wed, 6 Mar 2013 21:16:36 -0800

Keep in mind that those were Canadian prices. And when I bought my Chroma in December 1983, the pressure sensor was supposed to be available "soon," but never was, at least in Canada.

Jesper Ödemark [21010135] · Thu, 07 Mar 2013 14:32:36 +0100

Isn't that case in the dutch ad unusual? I have the pedals packed in the lid abobe the keys and mine was sold in Germany originally.

Chris Ryan [21030691] · Thu, 7 Mar 2013 08:40:01 -0800

Mine has the pedal case above the keys as well. The picture appears to be cut from the brochure: see the second to last page.

enhanced sysex file format? patch names...

Brian McCully [21030361] · Thu, 7 Mar 2013 13:58:23 -0800

Is there memory space in the CC+ to incorporate (or accommodate) patch names? I did a site search on 'patch names' and didn't find a lot of discussion on this (maybe it's somewhere under 'program names' instead? I did search 'sysex' but it was mostly discussing format conversion...). It's been a long time since I used Galaxy to move around patch names in banks, but I do seem to remember one could tag in x amount of characters (19 max? ref: GXY2SYX.c) patch names. Of course the Chroma itself never utilized names as such in the sysex data dumps.

Seeing as how we may see a Digital Chroma patch format be developed (enhanced from the current default Syntech format?), it'd be awesome if there was some standard way to tag the current (historic) set of Factory Set, Chroma Cult, etc. patches, that are available.

An ASCII name up to 15-20 characters? More ASCII allocation for comments (e.g. on patch links)?

A cross-platform Librarian that stood the test of time (unlike most of the Mac applications listed on the site (Galaxy, Sounddiver, etc) would be nice even if it 'kept' the names and left them out of the Chroma. thanks, -Brian

Ken Ypparila [21030229] · Thu, 7 Mar 2013 14:34:25 -0800

The Syntech format is just a copy of the dump that comes from the Chroma computer interface. It splits all the bytes in half to conform with the MIDI 7 bit limitation.

David Clarke [21030085++] · Thu, 7 Mar 2013 21:52:16 -0400

The CC+ format currently matches the Syntech format, to offer the greatest amount of interchangeability between interfaces (e.g., the sysex dump information from one can be used with the other, etc.).

In terms of patch names, here's an excerpt from the CC+ page at the Chroma site:

"...A currently planned (future) upgrade is the implementation of patch names and the addition of a 20x2 alphanumeric display, to allow more useful display of parameter functions and choices..."

The alphanumeric display did of course get added.

We have maintained sufficient reserve memory to accomodate patch names but to be honest, there has been very limited interest in having patch names. Add to that that in order to take advantage of the names you'd want to print them to the Alpha Display - and it only seems like a handful of people actually have the extra display attached, and of those, it is not likely all would want/use the patch name feature. (In short, there's nothing technical preventing patch names from being supported, but to date there's not been sufficient interest to justify the effort.)

Philippe [21010227] · Fri, 8 Mar 2013 03:08:32 +0100

I'd be interested too !

Dave Blees [21030552] · Thu, 07 Mar 2013 18:19:19 -0800

I seemed to recall that I had utilized some chunk(s) of "free" patch memory for storing a name, when I was building the GenEdit editor for Atari ST way back when, so I just went and checked the old source code, and sure enough, it was a whopping 18 bytes-worth, and I did have it set up so that the patch name would successfully ride along to & from the Chroma patch memory.

I wonder if the CC+ software is using those "free" bytes in patch memory these days... ? I think 18 was every free byte with Rev14...

Mirko Lüthge [21010245+] · Fri, 08 Mar 2013 07:27:29 +0100

I am interested in to, for RC and RCE !! I think the most owners are interested in reading patch names but the less are asking for it. So here is my call too.

Pleeeeeeeeeeeeeeeeaaaaaaaaaaaaaaaaaaaaaaaasssssssssssssssssseeeeeeeeeeee

thanks a lot

David Clarke [21030085++] · Fri, 8 Mar 2013 09:04:37 -0400

... I had utilized some chunk(s) of "free" patch memory for storing a name...it was a whopping 18 bytes-worth, and I did have it set up so that the patch name would successfully ride along to & from the Chroma patch memory.

I wonder if the CC+ software is using those "free" bytes in patch memory these days... ?

The design of the CC+ attempted to maintain (as much as possible) the same 'exposed' memory map as in the original Rev 14 Chroma CPU setup. That was done to facilitate the continued use of external accessories that 'reached in' to the Chroma.

In this specific case, the CC+ does maintain the lower memory mapping - and so the same bytes that would have been available in the original Chroma Rev 14 firmware in NVRAM would still be available in the CC+.

With regard to CC+ implementation though, the two main differences with regard to RAM storage are 1) all of RAM is non-volatile - not just a portion and 2) RAM is bigger, allowing for additional storage

Brian McCully [21030361] · Fri, 8 Mar 2013 07:35:21 -0800

Is there room in the Chroma for 4 banks of 50 patches with 18 to 20 length character names? More/less?

In addition to being useful for an Alpha Display, patch editing software (on PC/Mac or a tablet) could / should have an editable text field for the patch name. An ASCII embedded name in a sysex patch (or bank) could be searchable on a PC/Mac OS. A Mac/PC convertor could open/save in new/older formats. A batch convertor could be created for all of the website-posted banks. The sys-ex header could just add a 'designator number' for the newer format. Does a new format have to be ratified by the MIDI Manufacturers Association? ;>)

Trying to stay on topic here, but there's a lot more advantage to having patch names than not. Especially for versioning. And the whole other topic of a librarian and sub-categorization (like many of the softsynths, with 'leads', 'bass' 'pads', 'ambient', etc)

could eventually apply, but won't happen until patch names exist. thanks, -Brian

David Clarke [21030085++] · Fri, 8 Mar 2013 13:02:44 -0400

Is there room in the [CC+] for 4 banks of 50 patches with 18 to 20 length character names? More/less?

Yes.

In addition to being useful for an Alpha Display, patch editing software (on PC/Mac or a tablet) could / should have an editable text field for the patch name...

The 'problems' you have on the PC/Mac side are that:

  • There likely is no concensus about what program could/would/should be used to archive/manipulate the sysex files
  • As there is no industry standard for the data 'in' a sysex file (hence the 'system exclusive' name), no existing editor would either:
    1. know how to extract the names and associate them with a patch
    2. know how to take a name that migth be assiged in a given editor and store it in a SYSEX file such that the CC+ could decode it.

If there was a defacto patch editor that a reasonable majority of people planned to use then the external setting/manipulating of the name information would seem to be a bit more useful.

In lieu of that, experience has shown that if people have to do a lot of different things to achieve the end goal (take file, run converter X, output to Y, etc.), they generally don't - and just skip it.

That said, if we as a group decided there was merit to add this feature, then we should agree on 'how' it would work.

I would suggest that a low-impact idea would be to not necessarily define an new "CC+-only, name-enhanced SYSEX patch dump" format that would require converters to be used; rather, it would be to just define an additional "patch name only" SYSEX type.

The idea would be that you could create a text file with the desired patch names. That would get converted to sysex and sent to the CC+ as a separate SYSEX file.

While it would have to be tested to confirm that it would work as desired, if you just wanted to manage one file as a 'Patches + names' copmbination, then that would just be the concatenation of a standard Syntech patch bank sysex + the patch name sysex.

The benefits here being that you won't necessarily 'break' Syntech support - and you have a defined way to 'add' names to patch banks that don't currently support them.

Philippe [21010227] · Fri, 8 Mar 2013 18:11:08 +0100

Well, at least it would be great if that name would show up on the added LCD when switching from a program to another...

Marais · Fri, 8 Mar 2013 12:30:49 -0500

agreed.

Brian McCully [21030361] · Fri, 8 Mar 2013 13:12:43 -0800

I'm fine with this idea - I've seen it used with other synths. Would it be for writing individual patch names (to a single location in the Chroma), or banks of names and/or both?

Chroma 21030550 For Sale

Chris Ryan [21030691] · Tue, 12 Mar 2013 22:49:46 -0700

$4,800.00. See Rhodes Chroma for sale by Switched On Austin (Texas, USA). I emailed them and they replied, "It is on consignment from the original owner, who worked for Peavey in the 80's. We just finished giving it an extensive service and we have two more in the queue for service at the moment." Has an updated power supply. It is a little rough cosmetically. Appears to include a Syntech MIDI interface.

21030550 is new to the registry.

21030550

David Clarke [21030085++] · Thu, 14 Mar 2013 12:54:27 -0300

Did they happen to provide any S/N info on the 'two more' (in case those too were new registry entries?)

Chris Ryan [21030691] · Thu, 14 Mar 2013 12:35:56 -0700

I don't have that info yet.

OT FS: Korg PS-3100, Los Angeles

Dave Moylan · Thu, 14 Mar 2013 13:02:55 -0700

Not Chroma related I know, but I figure people on the list are generally people who like rare expensive synths. I'm going to sell my Korg PS-3100. It's near mint. 100% functional and only a few very small nicks in the case. Can provide pics but would rather a buyer saw it in person; I'd prefer not to ship. Looking for $6K.

New PSU retrofit and progressive tuning failure...

Lawrence Eldridge [21010100] · Thu, 21 Mar 2013 10:13:58 +0000

Hi folks,

I'm wondering if anyone could give some advice towards an issue that's cropping up - I've got a Rhodes Chroma that's currently in repair - it has the CC+ installed, and very recently had the new PSU retrofit installed, however the engineer that's overseeing all of this recently got back with the following issue: "auto tune throws out all the cards from time to time and once it starts to throw out a voice it cascades the number of failed cards until all failed.". This sounds like the issue described here: Hardware Fault Diagnosis & Repair: (2.1.1) Progressive tuning failure although I can't see why it would be a PSU problem - has anyone had had anything similar happen? Is it a big concern? If it happens once in a while I'm wondering whether its just a quirk as the unit warms up.

Any help is greatly appreciated,
Lawrence.

Luca Sasdelli [21010226] · Thu, 21 Mar 2013 11:19:30 +0100

Hi Lawrence,

did you engineer recalibrate the instrument as recommended in Switching Power Supply Unit Replacement Kit ?

In synthesis (and in sequence):

  1. adjust +5V analog for exactly 5.05V
  2. adjust I/O board offset to minimum (the only one timmer on the board: DC millivoltmeter on the close test points)
  3. patch with pulse wave and width set to 32: adjust each VCO trimmer to gain 50% duty cycle

Cheers
Luca

Lawrence Eldridge [21010100] · Thu, 21 Mar 2013 10:31:21 +0000

Hi Luca,

Thank you for getting back so soon - I'll double check with the engineer now and will let you know what I find... I'm hoping that its just a calibration issue as you mention.

Lawrence.

Polaris slide pots?

Dave Blees [21030552] · Fri, 29 Mar 2013 08:41:21 -0700

I am in need of a replacement slide pot, to get an otherwise good Polaris up to 100%. I checked Mouser's catalog & others, but haven't found a suitable replacement yet, so I am hoping somebody who has sourced these in the past may have an answer, or maybe if I'm lucky, somebody may have a scrapped unit with parts available(?)

The part in question is one of the 20 slide pots on the Polaris panel: 10k linear/30mm travel/20mm shaft

Thanks!

George Sarant [21030818] · Sat, 30 Mar 2013 18:43:00 -0400

I got that from Syntaur.com

They are good for parts.

Dave Blees [21030552] · Sat, 30 Mar 2013 22:34:29 -0700

ba-da-bing! I KNEW somebody had to have these somewhere. Thanks for the tip, George! This group is the greatest! I will soon have a progress report on this Polaris refurb project...

(Here's a link to that part's page for reference: Syntaur: Slide Potentiometer. Syntaur.com also currently lists replacement keys, slider knobs and a few other Polaris parts.)