| Home | Chameleon | Skins | Developers | Users | Company | Links | News | Forum | Shop |  |
| SDK | CDE | Toolkit | Downloads | Resources | Tech. docs | Tech. FAQ | Interviews |
Technical F.A.Q.
What exactly is inside the Chameleon?
What is the system latency?
How do I become a Chameleon developer?
There must be a catch.
Are the Chameleon development tools open source?
What if I want to sell or give away my skins?
What about custom panels and hardware?
What do the development tools offer?
How does the simulator work?
C? Assembler? This sounds horribly complicated!
Is that it?
Is there a hardware debugger?
What kind of computer do I need to run the development tools?
Will there be a Macintosh version of the development tools? How about Linux?
The Chameleon contains a Motorola DSP56303 chip running at 100MHz, with stereo audio inputs and outputs going through high quality Crystal Semiconductor codecs running at 24 bit/48KHz. There are 4 MWord (1 word = 24 bits) of DRAM available to the DSP, and 8 KWord of SRAM on the chip itself.
The DSP is managed by a Motorola Coldfire MFC5206e microcontroller, which is a 32 bit chip running at 40MHz. This has access to 8 MBytes of external DRAM and 8 KBytes of internal memory. It runs a multi-tasking operating system called RTEMS, which along with another system called MIDIShare provides high-level access to all of the front panel functionality, MIDI flow, and DSP operation.
Finally, there is 1 MByte of Flash memory available for the storage of user applications, presets, and anything else you would like to put there.
All digital signal processors impose a delay on the signal when it is converted from analogue to digital or back again. This delay is called the system latency.
In the Chameleon, passing a signal through the A/D converters delays it by 0.67 milliseconds. It takes the same time to convert a signal back to analogue form,
so the total system latency for processing of real-time audio input would be 1.34 ms. In addition, there may be further delay to a signal as it is processed in the DSP.
However, this depends totally on how a programmer chooses to deal with input signals.
Signals can be processed sample by sample; at the sample rate of 48KHz, each sample lasts ~0.021 ms. Alternatively, many DSP algorithms operate more efficiently by working on a buffer of samples, processing a whole batch at once. The method used, and the size of any buffers employed, will probably add some further latency to the signal. This is a fact of life in the digital world, but many programming techniques exist to minimise these processing delays.
You should not assume that each individual sample processed in a single iteration of an algorithm adds 0.021ms of latency. The DSP56303 can perform over 2000 operations in the time it takes for each sample to arrive from the inputs, so generally a sample is processed and passed on to the output converters before the next input sample has arrived.
Easy: the development tools are available for free on this website, on the Developers - SDK Downloads. You get those, and then you buy a Chameleon (which includes the tools on a CD), and start programming. There are no fees (other than the cost of the hardware), no program to join, no contracts to sign. As long as you have (or are willing to learn) the programming skills, you can do whatever you like with your applications.
No catch. It's an open platform, we give the tools away for free because we want people to buy the hardware and write new musical applications for it. Aren't we nice?
To find out more about how others are getting on you can read interviews with some of the current Chameleon developers here.
Not for the moment. We give you the details of how to program for the Chameleon, using its operating system and development tools, but we do not give away the source of our own software. Doubtless it could be improved upon in various ways, but one of the things that makes the Chameleon useful is that developers can easily build on the system without worrying about the underlying hardware interface. If there were multiple versions of our tools floating about on the net, we wouldn't be able to make the same promises about stability and compatibility.
Besides this, building the Chameleon and making it useful to developers involved a lot of research, effort, and money.
We could only do this properly if we had a reasonable expectation of earning a living from it, which is why we are not yet ready to give away all our secrets.
No problem. As well as featuring the Chameleon, our website will include a page for each complete application so that users can find all the latest Chameleon software in one place.
If you wish to sell an application you have written, we can do this using the same mechanism that we use to sell the hardware, taking care of ordering and billing for you. To prevent piracy, each Chameleon has a unique serial number and you can easily prepare an application so that it will only run on that customer's machine.
If you wish to give away your application as freeware, or even offer the source code to other programmers, you can do this too.
Also not a problem. In fact, The Chameleon technology allows this to be totally customisable, from front panel layout to back panel connectivity.
The SDK (Software Development Kit) includes all the tools you will need to write your own synthesizers, effects, etc. for the Chameleon. At present, this involves writing your software in C/C++ for the ColdFire part, and working with assembler in the DSP to really fine-tune performance.
The Toolkit application gives you a direct interface to the Chameleon from your PC. As well as loading applications into the unit to make music, it also allows you to save them to Flash RAM or create a standard MIDI file for download from a sequencer. Commercial developers can add copyright protection to applications by keying them to the serial number of a customer's Chameleon. The Toolkit can also act as a terminal to the Chameleon and be used for viewing debugging information embedded in the user code.
The SDK includes GUI56300, a software simulator of the Motorola 56303 DSP chip used in the Chameleon.
Compiled DSP code can be loaded into this and their execution examined for debugging. You cannot access the DSP directly with a hardware debugger,
because all the communication between the computer and the Chameleon is handled by the microcontroller.
GUI56300 provides the same functionality as a hardware debugger by simulating the DSP on your PC.
Also, there are of course compilers, linkers, assemblers, and so on to actually turn your source code into a binary, which can run on the Chameleon. These add up to a number of small DOS programs. You will rarely execute them directly: instead you will use standard makefiles, which are invoked from the included Chameleon Development Environment, an integrated environment to make easy the Chameleon developing process. This environment includes a full featured syntax highlighting editor, direct use of provided tools, integrated output panel with error and warning recognition, and more...
Finally, we give you stacks of documentation (see the Technical Documentation) : tutorials, example code in C and assembler, reference material, and a selection of documents on programming considerations for DSP. Most of this is in PDF documents, which can be read by Acrobat Reader, which is also included on the CD if you need it. If you're an experienced programmer, you will find all the material that you need to get started right away. If you are not, then our growing tutorial material will get you off the ground and help you to begin coding your own audio tools.
All users will need to study the examples to learn just how to put together a Chameleon application. The examples start by showing you how to print 'Hello World' on the front panel display (aaah) and will go all the way up to building a monophonic wave table synthesizer. You will be shown how to interact with all the components on the front panel, write to the 3 different types of memory in the Chameleon (DSP, microcontroller, and Flash), and deal with audio input and output, as well as MIDI.
Yes, but think how clever you'll look! Seriously, these are the basic development tools which you need to create digital filters, delays, etc. which can be combined into a synthesizer or effects unit. Getting the best performance out of the hardware in the machine means going down to the code level and telling the chips exactly what to do. We have to offer these low-level tools first, because these are the ones that professional developers need most.
For those who want to make music rather than machine code, don't be put off by all these technicalities. Loading software into the Chameleon and then treating it as a normal studio tool is easy, and requires no understanding of the underlying program.
No! This is only the first version of the SDK. Because options for user development are central to the concept of the Chameleon, we will constantly be expanding it with more and more documentation, more example code, more DSP material, and more software tools. The latest version (and a lot more good stuff which is not part of the SDK) will always be here. Part of the reason that we are beginning with low-level coding tools is that feedback from users like you will help us to make better decisions about where the product should go in the future.
We do not wish to make promises now about exactly what form these software tools will take.
Many software (and pro audio) companies make extravagant promises about what features their product will have,
and then users are left waiting for long periods before these features appear, if they appear at all.
But, we do have a strong committment to our product and to the future of the Chameleon, so you will never be left in the cold with an obsolete, and out of date, product.
This first version gives you all the tools required to make your own Chameleon applications, and we believe that it does not contain any significant bugs. We think this is a lot better than telling you stories about other tools that are not ready yet. When we are ready to show a new application or tool, we'll post it in the news section of our page, so keep checking back!.
As mentioned above, the architecture of the Chameleon is complex. For example, the microcontroller, a Motorola Coldfire, is managing I/O from the front panel, MIDI, Flash memory, and the serial port, and generating all the parameter data for the DSP. Doing things this way (which we think is the best way) precludes direct access to the DSP with a hardware debugger, and this is why we include the GUI56300 software simulator.
As for the Coldfire microcontroller itself, it is running its own multitasking operating system and several drivers, which removes most of the really hard programming work involved in dealing with the different type of I/O. You cannot run a normal hardware debugger directly with the Chameleon, and even if you could you would be swamped by information from the operating system, which is complex.
As shown in the example code, we currently encourage you to approach debugging by embedding code into your own applications and reading the results in the Toolkit window. It is possible to compile applications in both debug and release modes, so this need not impose any overhead on the finished version. We do intend to add more sophisticated debugging tools in line with the overall growth of the SDK.
Basically, a PC running Microsoft Windows 98 or later. You will need a CD-ROM drive to load the SDK (unless you download it from our website),
and a serial port (e.g. COM1 or COM2) for the Toolkit application to communicate with the Chameleon. The installation will need about 100 megabytes of disk space.
The memory requirements are not so steep: the Toolkit requires about 2.5 megabytes, and the DSP simulator requires about 7.5 megabytes. All the audio is being processed in the Chameleon itself, so the PC only has to deal with C/C++ and assembly language. Everything will run quite happily on a basic Pentium with 64 megabytes of RAM. Compiling will obviously go faster on a fast machine, but neither the Toolkit nor the DSP Simulator (which you will be using most often) demands a lot of system resources.
As for the operating system, we test each release of the SDK on Windows 98, Windows 2000, and Windows ME. There is not a great deal of interaction with the operating system of the PC, because none of the software does anything more complicated than talk to the serial port or display some windows. There are no special drivers or system functions used. So compatibility problems are very unlikely to arise
Porting to the Mac (OS X) would mean rewriting not only the toolkit, but also the compilers, simulator, and all the other little tools which create executable code from source. This is less complex for Linux, as many of the development tools already exist on that platform. However, a Linux port would still take a lot of work, so we cannot say when there will be OS X or Linux versions available.
Since a PC running Microsoft Windows is the most popular platform, this is the only platform to which we are committed for the time being.
