| Home | Chameleon | Skins | Developers | Users | Company | Links | News | Forum | Shop |  |
| SDK | CDE | Toolkit | Downloads | Resources | Tech. docs | Tech. FAQ | Interviews |
Short Introduction
Chameleon contains two separate chips. The Digital Signal Processor, or DSP, is designed specifically for manipulating audio. It may be programmed in C, but for real performance you should program it in assembly language - code that allows you to directly access the built-in features of the chip. Assembly language, or assembler, may seem quite imposing at first. But as the chip is built to process audio, so the assembler is built for writing audio-manipulation software. If you have experience of DSP, you will probably find the assembler code quite logical and accessible once you get going.
But a synthesizer or effects unit does not operate with audio alone. It needs an interface to be really useful in the studio: that means you need a way to respond to input from the front panel or from the MIDI ports, and to use these same components to return information to the user. This is the job of the Coldfire microcontroller, which may be programmed in C or C++. To make your life easier, the Coldfire runs an embedded operating system called RTEMS, which takes care of real-time task scheduling and provides high-level drivers for MIDI and access to internal hardware features.
Coming up with some good algorithms and writing the code makes up the bulk of a programmer's work. But how is code to be transmitted to the Chameleon for testing, and eventually for making music once the programmer is satisfied?
Languages like C, C++ and even assembler are designed to be read and interpreted by humans. Once a program - even a tiny one - has been written, it must be translated into some format that the hardware can understand. This is the purpose of software tools like compilers and assemblers. The behaviour of these tools can of course be fine-tuned by the programmer, but this process often adds an unwanted extra layer of complexity to software development. Add the fact that most projects are split across multiple code files - or they would be unmanageable - and the compilation process could start to take as long as writing the code.
On large projects most programmers use something called a Make utility to automate the compilation process. The Chameleon SDK naturally includes such a utility as well, allowing a programmer to turn a collection of files into an application with a single command. It is instructive to understand what happens during the Make process.
- Assembler code, if any, is converted into DSP machine language.
- The resulting file is processed by a special utility which allows this code to be included in a C program.
- The uController code plus any DSP code processed in step 2, is converted into a machine language file.
- This file is the final application. It may be transmitted directly to the Chameleon using our Toolkit software, or further processed into a MIDI file for general distribution to anyone with a Chameleon.
- Once the application is transmitted to the Chameleon, it begins running automatically on the uController.
- If the application uses DSP code, this is converted and transmitted to the DSP itself by the operating system as soon as the uController program asks the system for access to the DSP.
- Once transmitted succesfully, initialisation is complete and audio can be processed.
If you are new to this, you might be feeling a bit overwhelmed by all this programming terminology and the big learning curve. Even if you know all about synthesizers and how they work, programming them in code on a screen is quite another matter. We understand this, and we accept that the Chameleon could be a bit intimidating for the less experienced. Having this in mind, we try to provide high-level tools and a complete documentation set that will allow a much wider range of people to create their own unique synthesis and effect programs that can be shared with other Chameleon users. Allways keep in mind that low-level programming allows programmers to achieve the highest performance. There's no other way to get useful applications running.
But just because we haven't provided easier enough tools for the novice programmer, it doesn't mean we're not interested in your needs! Why not let us know now what sort of features you would like to see?
