Embedded Keyboard Project, Part 4

Hello, this is just another update on our keyboard project. I feel we got a *LOT* done since the last time I posted. The project is now going very smoothly, and we feel we are meeting our schedule very well. I feel like we are around 80% done. Anyway, I wanted to share with you the following recording:

Okay, I guess that’s not my best recording yet, but after a few frustrating days of trying to get our ATSAM2195 Atmel synthesizer chip to work, we finally were able to produce sound output. This note was our first recording of the sound output off the chip.

Our final project circuitry actually fits on only one breadboard. We have a pic microcontroller, which has the task of reading all the key states, and generating NOTE ON and NOTE OFF commands to the synthesizer chip whenever a key changes value. The commands are then converted to MIDI messages, and sent to the ATSAM2195 synth chip.

Final project layout

In the image above, you can see our entire final project, minus the Arduino and LCD display, and minus the audio amplifier my lab partner built for this occasion. We decided to switch to parallel mode communication with the synthesizer chip, simply because we felt it was a bit easier to get going. Anyway, here is a quick and dirty c file we wrote for the PIC18LF4525, with which we were able to communicate with the synth chip:

midi_output_parallel.c

Next we need to integrate all the code for the keyboard controller, so actual key events on the keyboard trigger MIDI commands.

What I spent most of my time on lately was creating drivers for the Crystalfontz CFA533-YYH-KL LCD screen, which is a 2-row 16-character LCD display with 6 navigation buttons. We’re having an Ardueno Duemilanove control the LCD through a RS-232 connection. The navigation menu allows configuration of various things such as instrument, master volume levels, reverb, and chorus. We uploaded a list of the 128 different instrument sounds incorporated on the synthesizer chip.

We also incorporated commands to save current settings into the Arduino’s EEPROM, and restore to default settings. The settings are coordinated with the keyboard controller via I²C connection.

Testbench for LCD display controller

The I²C communication ended up not being straight forward, since I had trouble getting the Wire.h Arduino library to trigger interrupts in the PIC controller when the Arduino is asking for a byte of data. I ended up writing my own Master I²C drivers, which pretty much bit-bang the SCL and SDA signals. Using my library, I was able to get the Arduino talking quite nicely with the PIC controller.

Our current code files for the LCD display and menu drivers are as follows:

  • arduino_module.pde – Arduino project main file
  • common.h – Shared constants between keyboard controller and LCD driver
  • eeprom_driver.cpp
  • eeprom_driver.h
  • i2c_driver.cpp
  • i2c_driver.h
  • lcd_driver.cpp
  • lcd_driver.h
  • menu_items.h – List of items in the LCD menu

Download: arduino.zip

As of now, the LCD driver is mostly complete, besides some later proof-reading. Also, I can think of a few more features I would like to incorporate if I find the time such as transposition, and I want to change some things about how the menu is displayed.

Anyway, next time I post, the project might be completely done, perhaps just over the 3-day weekend. I have just one more week to work on this project, during which time I’ll be finishing the final project, preparing a 20-minute presentation on the project, writing one of Dr. Peckol’s typically long lab reports, and conducting a demo of our design.

Last day at RPC

Yesterday was my last day as an organist at Resurrection Presbyterian Church, after 2½ years of providing services on the piano and organ. Members of RPC threw on a really nice reception for me, where I was given a farewell greeting. Thanks for everybody who put this together!

The reason I’m leaving is because I will be interning in Cayo, Belize, with my uncle, who is the head of a small Electrical Engineering company, Innovatia Laboratories. It’s pretty much an internship, and I’ll be getting personalized training from him. As of now, I’m not sure how long I’ll be down there, but it’d be too much of an expense to fly up and play every Sunday. Although I’m not leaving until some time mid-July, these next couple weeks are packed with busy work for all my classes (if you haven’t noticed by my other blog posts). I have to think about moving out of my apartment into storage, and figure out a way to get down there.

It has been my pleasure working with Pastor Scott. Now Saturday nights and Sunday mornings feel a bit awkward, since all the days of waking up super early to set up and practice and talk to Brooke for half an hour are now over. I’ve received a lot of positive feedback over the past couple months. I will definitely miss working there, and hopefully, I will find a similar job in the future. My goal is that as long as I’m alive, there will be at least one church with good music and good theology. Maybe one day, if I find a stable job in the Seattle-Tacoma area, I will be able to use my talents once again at RPC.

Embedded Keyboard Project, Part 3

Today, I put several hours into the embedded project. My lab partner extended the 15-wire band by soldering on longer wires, then running the wires outside of the keyboard case, where they’re much easier to access in a bread board.
In the picture, the black wires are for the key matrix rows, and the red wires are for the key matrix columns. We also broke out controls for the power switch on the keyboard and for the two speakers, and we think we probably will try to incorporate them into our design.
After probing the 15-wire keyboard bus, we determined the overall schematic for the keyboard matrix:
This matrix design is exactly as I had speculated in an earlier post. I got keyboard drivers working, which as of now, detects when any of the keys have changed state, and which keys changed. The driver works by driving one of the rows high and the others low, then reading in the columns. This happens repeatedly for each of the seven rows. The old values of the columns are saved and compared to the new values, and when a change is detected, that is when we process a key change, and send MIDI commands to the Atmel synthesizer chip. Here is a PIC16F877a microprocessor wired up:
As you could see, we found we needed pull-down resistors for the column pins. We found without them, we got misread key strokes, since the voltage on the column pins wasn’t falling fast enough. We speculate the diodes introduce capacitance to the column pin nodes. We found 10 kΩ resistors are small enough to discharge the nodes in time for the next read.
The keyboard driver is currently written to toggle the LED on or off every time a key event is detected. The idea is, you press down one key, the LED turns on; press down another key, it turns off; release a key, it turns on again; etc. The current drivers for the keyboard controller can be found using the following links:
After pounding around for a while, we’re now pretty certain that every key event is being processed correctly, since after all keys are released, the LED always ends up in the off state.
Pressing down one key turns on the LED
As of now, we’re still using a PIC16F processor, which runs off a supply voltage of at least 4 volts. Our synthesizer chip runs off of 3.3 volts, and we don’t really want to deal with level shifters, voltage regulators, or use multiple logic supply voltages. So we requested some free PIC18LF samples from Microchip, which should be arriving early next, which can run off of a 3.3 volt power supply. Once those arrive, we could begin to try to send key commands to the synthesizer chip.
So I feel the project is falling together pretty well so far. Next week, we will begin trying to interface the ATSAM2195 chip, and we’re really hoping that we figure it out fairly quickly. As of now, I think all the soldering and modifications to the keyboard are complete. Just out of curiosity, I’m thinking about having my blood lead levels tested.

Embedded Keyboard Project, Part 2

For my Embedded capstone project, we ordered and are us using the ATSAM2195 Atmel synthesizer chip. This chip comes in a 44-pin QFN (quad flat no leads) package, and with this chip, you input MIDI commands using 31,250-baud serial communication, and the chip simply provides the output analog signal. The chip is only 7 mm × 7 mm × 0.9 mm large, and the pins on the chip are only 0.3 mm wide, making it is virtually impossible to use a soldering iron to attach the chip to a PCB.

Three ATSAM2195 synth chips

Since we were prototyping on a breadboard, we had to order an adapter, which converts a QFN-44 case to a DIP-44 (dual in-line package) case. Searching online, I found a kit with adapters, a stencil, alcoholic wipes, a tube of solder paste, plastic tab, tin headers, and a header spacer.

QFN-44 to DIP-44 adapter kit

The first step of the process is to apply the solder paste to the minuscule pin plates on the adapter. To do this, we taped the QFN-44 stencil to the PCB, then wiped a layer of solder paste over the holes using the plastic tab.



If we were lucky, when the stencil is taken off, the PCB would then look something like this, where each pad had just the right amount of solder paste on it, and there were no solder past bridges between pads.


The next step which required perhaps the finest motor skills was placing the QFN package on the PCB, without smudging the solder paste, and aligning the pins just right.


Once we felt the chip was aligned squarely on the pads, the next step was to start our ‘reflow oven’. Actually, it’s more of a ‘reflow skillet’. Strangely enough, the Electrical Engineering department at the University of Washington doesn’t have any tools for PCB printing, so we had to think of something else. So we found a tutorial on SparkFun for using an iron skillet for doing reflow. So we got the exact same model skillet as used in the tutorial, from Target, and put it to work.

Our reflow skillet

After a few minutes, the solder will melt and turn shiny, and after that, we removed the PCB, and inspected for bridges and continuity.

After reflow

The final step is to solder the header pins on, which is the easiest part. The header pin spacer is used to ensure the header pins are the correct distance apart, so it will easily fit into the solderless breadboard.


Abofe, we show the chip connected up to the bread board. The oscillator is there just for show, since unfortunately, the ATSAM2195 chip runs off of a 3.3 volt 9.6 MHz oscillator, but I’ve been finding it impossible to find one in a DIL package, so we’re sticking to the function generator until we find one. Below is another one we made, just for backup.


So, right now we’re crossing our fingers that the chips actually work, and they’re connected correctly. If using the chip is as straight forward as I hope it is, we should be making music with it by early next week. As of now, I’ve been working on drivers for the keyboard interface, which we’re going to implement on the PIC16F877a microcontroller. My other lab partner is writing display drivers for an Arduino Duemilanove (don’t ask me to pronounce that) for a hierarchical menu on an LCD screen. The idea is that the Arduino will be used as the user interface to set MIDI options, such as reverb, volume, instrumentation, etc…, and hand the options over to the PIC, which outputs the MIDI commands to the synth chip.

On a completely different topic, here is a C programming challenge I found online published by the company RapLeaf, and it took me around three hours to figure it out. I thought I would throw it out, because I found it fun to think through, and maybe some of my readers who are programmers would like a little bit of a challenge. They’re looking for programmers that are good at solving problems like this. I’ll be interviewing with them this coming Saturday since they liked my solution, although just for fun. It looks like their positions are geared heavily towards Computer Science majors, which I’m not.

Embedded Keyboard Project, Part 1

Hello,
This is the first of a series of posts detailing our EE 478 final project, which is to create a MIDI instrument. The idea is to dismantle an electronic keyboard, and rewire all the keys in order to make our own keyboard instrument. I’m feeling more free to publicize my work on this project, since my lab professor Dr. Peckol publishes our work on the class web site for future classes to use as reference, anyway (link).
For this project, we’re creating a 49-key digital keyboard instrument. The keyboard is equipped with an LCD screen interface which shows a navigation menu, and is navigated with pushbuttons. The navigation menu allows the user to change musical settings, such as instrument, reverb, chorus and volume. The system is designed to be low-power and low-cost. We are running all components in the system on a 3.5 Volt supply (except for the external speakers). The 49 key musical keyboard input is controlled by a PIC microcontroller, which converts the keyboard input into MIDI serial data that is sent to a synthesizer chip. The microcontroller is also responsible for interfacing with LCD and pushbuttons for musical configuration settings.
Today, we made our first leap into the project by purchasing a used 49-key MD-500 ‘Optumus’ Radio Shack keyboard on Craigslist for $20.
As you can see, the keyboard is equipped with all sorts of features, including a MIDI recorder / playback feature, metronome, prerecorded songs, auto-rhythms, MIDI-out, and more. For our project, we are creating our own features, so all of that stuff is going to be removed.
After taking apart the keyboard, here is what is in the inside:
As you can see, there are five visible main sections. There are the two speakers, which we may not end up using. There is the panel for all the buttons, which we won’t need either. On top of that, there is the LED screen for the front panel, which is not useful. The keyboard is powered by a battery pack, which we probably won’t use. There is the keyboard section (bottom), which has groups of 8 diodes, each for a section of eight keys. Total, there are 49 diodes on this board. Connected to this board through the large gray ribbon is the ‘mother board’ for the keyboard.

The ribbon consists of 15 wires, connecting the 49 keys to the keyboard controller. I needed a soldering iron to completely remove the mother board to see the circuitry on it, but by peeking under, here was what was uncovered:
As you could see, the keyboard wires feed into a 38-pin DIP adapter, which feeds into some mysterious ball of black glue. What’s under this black glue is probably the keyboard controller / MIDI synthesizer.
Hmmm… 15 wires and 49 keys… how does that work? Well, I found an informative site online, for creating a simple keyboard controller with the PIC16F877A microcontroller, which we now have quite a bit of familiarity with:

(Credits for this diagram go to Thomas Scarff, Lecturer at Dublin Institute of Technology, School of Electronic and Communications Engineering)
The circuitry in the keyboard is probably very similar to the image above. The keys are arranged as a matrix with rows and columns. On the keyboard I got, the notes are probably grouped by rows of 8, not 16. The keyboard controller polls only one of the rows of eight keys at a time by asserting high one of the row selector pins (pins 34 through 40 in the image). When a row is selected, the values of the notes on the row will appear on the column pins for the keyboard controller (pins 2-9, and 19-30 in the image). For 49 keys, you need 7 columns of notes to select out the individual row of eight notes (49 / 8 = 7, rounded up). Doing the math, 8 rows + 7 columns = 15, which accounts for all the wires in the ribbon. Our next step is to figure out which wire corresponds to which row or column on the key matrix.
The keyboard controller continuously loops through all the rows of keys and collects data on the state of all the keys. When one key is noticed to have changed, a on or off key event will be triggered, depending on the new state of the key.
Well, that’s all for now, I will continue to give updates as our project progresses.

Spring Quarter, 2010

Hello, friends and family,

It’s mid-quarter now, and it’s my last quarter at the University of Washington. There will be a department celebration on Friday, June 11, at 7:00 in Kane Hall, room 130. You need a ticket to get in, and I’m allowed to give out 3 of them; there might possibly be more available in the future. The University Graduation is on Saturday, June 12. If you want a ticket, let me know, and I’ll try to get one for you. More details could be found here: http://uwgraduation.com/.

Lately, I’ve been sprucing up my résumé and cover letter, and I’ve been looking into all sorts of employment opportunities. I’m trying to find somewhere preferably in the area. Sometime this Summer, I may be heading down to Belize to intern for Innovatia, my uncle’s company, during which time I will be put on interesting projects, hopefully to build up an eye-catching résumé for when I return.

This quarter, I’m only taking one engineering class, EE 478, which is the capstone course for embedded computing systems. It’s been proving enough of a workload, especially since one of my lab partners decided he didn’t want to come to class or participate in group meetings. So I’ve been working hard to keep up with only one lab partner; but we’ve been pulling along alright. EE 478 does have a reputation as being one of the most time-consuming classes at the University of Washington. It even has its own Facebook page! My professor Dr. Peckol is known for his high expectations, especially on his lab reports, which tend to average around 50 pages each. Overall, in the four classes I’ve taken with Dr. Peckol, I must have written well over 500 pages of lab report; and more still to come!

Me

This past week, we had due a project to design a microcontroller-based scanning and imaging system to be mounted on a probe to be used for extra-planetary exploration. This probe has three cameras and a 2-Kbyte SRAM partitioned into two buffers. When one buffer is full, the contents are uploaded to a ‘mother ship’, then transmitted to an Earth data collection center. This lab was just an introduction to the PIC16F877a microcontroller, and to synchronous and asynchronous communication, namely I2C and RS-232 (which you wouldn’t use for space exploration). Anyway, after pulling some overnighters, we got our circuit working perfectly. Besides that, we Here is what it looks like:

I’ve learned in the past week that troubleshooting the PIC could be at times time consuming. A couple times during this project, we narrowed down to problems to lines of code that look perfectly normal, but cause the PIC to crash for some reason. The PIC controller has a lot of quirks that if you’re not familiar with them, could lead you to pull your hair out wondering why the processor keeps crashing. The most time consuming problem we faced is when we discovered that the breadboard we were using at the time was broken, and wasn’t connecting things together properly.

The last few weeks of class, I’m going to be working on the EE 478 final project, which entails creating a fairly complex embedded system. My lab partner and I are thinking about using one of the Amtel synth chips (particularly, the ATSAM2195) to create a musical instrument. I was thinking about tearing apart a cheap keyboard, and then designing the system that generates MIDI inputs for the chip. We’re in the planning phase right now, but there’s many ways we’re planning to increase the complexity of the system if we so desire. These projects tend to cost people around $200 to $300 for parts.

Anyway, I’ll try to blog more often when something pops to mind. Take care.

Spring Break

It’s Spring Break now. I officially have only one more Electrical Engineering class left before I graduate, EE 478, which is the capstone for Embedded Computing taught by Dr. Peckol, who I would have had for a total of four courses during my time at the University of Washington.
This past quarter was perhaps my busiest quarter yet… I took three 400-level Electrical Engineering courses. I took EE 477/525, the VLSI capstone course in designing digital integrated circuits. The class ended up taking massive amounts of time for the projects. There were three projects in total, which amounted to over 150 hours of work each. We used the FreePDK45 design kit to lay out the first two projects, which were a 256-bit SRAM cell and a 20-bit adder.
For each of the projects, we were graded competitively on a certain Figure Of Merit (FOM), which was a number we got from multiplying several measurements of our circuit. For our first project, which was to design a 256-bit SRAM cell, the FOM was Area×Delay², which you calculate by measuring the total area taken up by the chip and multiplying it by the worst possible delay for storing data in the chip squared. The team that got the best FOM got full points for the competition portion of the project, the group with the worst FOM got no points, and everybody else was graded in between on a linear scale.
For the first project, the 256-bit SRAM, my lab partner Kaitlyn and I did pretty well, and got the second-best FOM in the class. The following image shows our final circuit, which measures 19.38 µm × 13.78 µm (267.1 µm²). For reference, the smallest size square particle a person with 20/20 vision can see is 100 µm × 100 µm, so you can fit around 35 of these cells in that area.
Our 256-bit SRAM cell (click to zoom in)
This SRAM consists of five distinct parts: a 5-to-32 decoder, 16 bit-line pre-chargers, 16 high-skew inverters, and 8 bit-line write drivers. With our design, we measure a maximum read delay of 1.055 ns.
For our second project, we were required to design a 20 × 20 bit adder. For our design, we designed a delay-insensitive carry-lookahead with speed-up circuitry (DICLASP) based on an IEEE article we found online. What attracted us about this specific adder design was that it implemented an O(log(log(n))) algorithm, whereas most tree adders we encountered used an O(log(n)) algorithm. We deviated a lot from the implementation used in the article, whereas we made it not self-timed, and used N-P domino logic. Looking back, that might have not been a good idea, since we found out it took an extreme amount of time to lay it out, since it required 11 unique cells. One of the only three overnighters I pulled this quarter involved starting the layout for our design at 8:00 AM with my lab partner, and not finishing the layout until 1:00 PM the next day (29 straight hours of layout). Unfortunately, our effort on this project was not worth the results, since we learned N-P domino logic is not the best choice if you have long wires in your circuit…. Anyway, here is our final project layout:

20 × 20 bit delay-insensitive carry look-ahead adder with speedup circuitry (click to zoom)
I feel if we had more time, we could have optimized this circuit to have a much better delay, but we ended up with a delay of 1.898 ns, area of 453 µm², and power consumption of 322 fJ per computation. We ended up having the second-worst FOM, which was Area×Power×Delay² for this project. I felt that we really chose one of the hardest designs to lay out, and if we had more time for the project, we could have done a lot better with the FOM.
By the end of this project, we felt we really didn’t have much time to spend on the final project, which was a 10×10 2’s compliment multiplier with modified Booth encoding, so we stuck with a static logic implementation for the entire circuit. The most time-consuming part of this project was figuring out how to do 2’s compliment signed multiplication, since all the examples we were shown were for unsigned multiplication. We had to figure out on our own how to implement the partial products for signed multiplication on our own, pretty much, since there was nowhere in our text book or on the internet which explained how to do signed 2’s compliment multiplication.

Fall Quarter

Unfortunately, this is one of those blog posts where nobody knows what I’m talking about, so feel free to not waste your time trying to read it.
Anyway, I took three engineering classes for Fall 2009 Quarter; EE 341 – Discrete Time Linear Systems, EE 473 – Analog Integrated Circuit Design, and EE 476 – Digital Integrated Circuit Design. In EE 341 – Discrete Time Linear Systems, you pretty much cover many of the principles needed for most audio, image, and video processing. The course pretty focuses on applications of Z-transforms (which are Laplace Transforms for discrete signals), Discrete Fourier Transforms, Discrete Time Fourier Transforms, and Discrete Time Fourier Series.
In EE 473 – Analog Integrated Circuit Design, you essentially learn how to create amplifiers using 23 nm CMOS technology. For our final project, we developed an 80-dB fully-differential amplifier with several design specifications for input and output capacitance, phase margin, power consumption, output swing, and unity-gain frequency. We used a folded-cascode topology with a common-source second stage, biased with low-voltage cascode current mirrors. The circuit also implemented common-mode feedback, which we just included as a couple resistors and an ideal op-amp, and also Miller compensation. Unfortunately, we only had one week to do the project, and we ran into a pretty time-consuming problem, but eventually we got something that met most of the specifications after a rather frustrating overnighter. We could have done better if we had a little more time.

In EE 476 – Digital Integrated Circuit Design, we worked on a 45 nm CMOS process. Our final project was to design an arbiter circuit in behavioral Verilog, then using software tools to convert the Verilog code into logic gates. We drew out a series of 9 logic gate standard cells, with which we actually drew out all the transistors and connecting metal layers, and used an automated process to convert the logic gates into a layout using standard cells. Below is our resulting integrated circuit, which measures only 15 x 15 μm², consists of 91 standard cells, for a total 362 transistors.

Here is our design for just one of the standard cells, the D-Flip Flop, which measures 1.235 x 3.23 μm². A Flip-Flop is essentially a memory storage cell, which holds one bit of information.
D Flip-Flop Schematic
Layout of the D Flip-Flop
It would take a long time to explain what’s going on here. All the blue rectangles are the lowest metal layer, the pink rectangles are the second metal layer, all the red rectangles are polysilicon (used for the gates for transistors), the W’s indicate the p- or n-doped wells, the triangles indicate p- or n- heavily doped regions. The layout image directly translates to the schematic above. Each of the colors represents a different mask during the manufacturing process. Since it costs well over a million dollars to manufacture an integrated circuit, we mostly relied on simulation software to test our design.
Most of the work in this quarter was learning how to use the Virtuoso design suite to design and simulate our circuits. Unfortunately, the University of Washington file servers were running extremely slow, and so we wasted a lot of time waiting for the mouse to catch up. It was also frustrating, since there were three classes all trying to use the University of Washington’s only 20 Linux computers at the same time.

Roland C-330 Home Organ

I need to introduce you to the newest member of my family, the Roland C-330 Home Organ. I’m officially the first one in Seattle to actually own one. My Dad and I went down to pick it up from the Rodgers factory in Hillsboro, Oregon over Thanksgiving weekend, and we were quite confident that it would fit in the Toyota RAV, since the Rodgers salesperson we met with earlier mentioned that it was small enough to fit in a car. As we figured out, JUST BARELY. We had to remove all the packaging. After getting it back to my apartment, I set it up and started to crank it up to see how loud it would go. Less than 30 minutes into playing it for the first time, somebody knocked on the door and complained I was being too loud… Oh, well, I guess that’s why I got head phones!

Below, I made a few recordings in my free time, to illustrate some of the sounds of this magnificent instrument. I will post more as I make them. The recordings came out perfect quality, and may have created some background noise and lost a little bit of high-frequency information as I converted them to MP3 format, so they sound a little different. They’re not perfect, but they should at least give you an idea why I fell in love with this instrument. I recorded using the Line-in audio port on my Powerbook G4 using SoundStudio3.

O Lamm Gottes, unschuldig (O Innocent Lamb of God), J. S. Bach BWV 1095 – Uses mostly flute stops

Prelude and Fugue in G Major, J. S. Bach BWV 557 – Set with a high amount of reverb, to mimic a cathedral sound

Nun komm, der Heiden Heiland (Come Now, Savior of the Heathen), J. S. Bach BWV 599

Herr Christ, der einge Gottes-Sohn (Lord Christ, the only Son of God), J. S. Bach BWV 601 – Illustrates full organ sound

Looking for organs

Hello, everyone!

Yesterday, my Dad, sister Diane, and I went down to Oregon to visit Rodgers Instruments LLC. Rodgers of course is the company that produced the organs for Faith Presbyterian Church. I have been having in my mind to pick up a good home practice organ, since I was losing valuable sleep on Saturday nights practicing for church service on Sundays, usually hindering my ability to stay alert in the service the next day.
I had a couple major criteria looking for an organ. Firstly, it would have to be compact and easy to move around, since there isn’t much space in the apartment to fit it. Also, I wanted something that didn’t sound like an electronic instrument, and had a good variety of instruments. After wasting time on Craigslist and being terribly disappointed by the terrible selection at Prossers Piano and Organ, began looking into the major Classic Organ companies (Johannus, Allen, and Rodgers), and actually got to go preview the Johannus 37 SE at somebody’s apartment in downtown Seattle. Johannus has been having a half-off sale for sometime, so some of their organs were attractively priced, including the Opus 7 I was looking at. Frankly, I wasn’t impressed with the Johannus organ tones, which still sounded very electronic to me, especially the reeds. To me, there really is no comparison with the Rodgers organ sounds.
I discovered the Roland/Rodgers C-330 organ while surfing online, which just started selling a week ago and there has been a wild internet buzz for a while. Roland is coming out with a Classic series, where they are trying to make authentic-sounding harpsichords, pianos, and organs for homes. After looking into this organ a little bit, I discovered that it is a very special piece of equipment. For starters, it had packed in it over 100 different Rodgers pipe sounds. The organ had excellent acoustics for what I wanted. And the tone quality was phenomenal (hear samples here).
Here is a photo of me trying out the Roland/Rodgers C-330 at the Rodgers plant in Hillsboro, Oregon: