A realtime, digitally controlled 'analog' synthesiser:

Selecting the image opens a new window showing a screengrab of the program.

"First of all, what exactly does this thing do?" Well, it is nothing less than a fully fledged Amiga native emulation of a late sixties' 'acid' type Voltage Controlled Synthesiser, such as the EMS VCS3. It should appeal to those musicians out there who are into analog sounds in realtime. In more techie terms, this is a software version of a realtime analog instrument that works according to a principle generally known as 'subtractive synthesis'. This is not a new concept, there are many examples running on machines with much faster CPUs than the old M68k that drives the Amiga.

Basically, DelfDCS, as that is what I decided to call this program on the file-system level, will be able to do pitch or filter sweeps, weird whooshes and all sorts of spaced out noises, all that in addition to what is already available on the Amiga in the form of several TB-303 emulators. All the controls can be played and adjusted with the usual real-time accuracy that the Amiga is capable of, which means no mouse lag, jitter or dropped mouse events, just like when drawing with a large brush in DPaint.

At the moment it is still undecided whether using separate windows for each module would be preferential, but maybe the design in the above snapshot will win out. It is unlikely to be the final picture, there will be changes for certain, cosmetic and functional, or improvements, especially if anyone can suggest some, and can convince me that they are worth the effort.

"Requirements - or what do I need to run it on?" Preferably a fast Amiga: presently it runs on an '030/50, though an '060 would be better if we want to multi-task it with AudioLab, or Evolution, and Bars N Pipes. OS3+ is necessary for BOOPSI classes and objects, though it might run on OS2.04 with classact installed. Most importantly, there has to be at least a Delfina Lite soundcard, or its newer form, the Flipper Edition, with AHI installed. This sound card is absolutely vital because the engine of the synth runs on the Motorola 56002 DSP which drives that card. This was unavoidable, as even the '060 on a CyberStorm or Blizzard wouldn't be fully up to the task of generating multiple layers of sounds in real-time. And of course I had found this public domain code for the Moto DSP: snippets for DCOs - Digitally Controlled Oscillators - LFO - Low Frequency Oscillator - a DCF - Digitally Controlled Filter - and ADSR - the Attack-Delay-Sustain-Release duty-cycle of an Envelope Generator.

Depending on the complexity of the patch, it should be possible to record several tracks to be played simultaneously - that`s using the 40MHz Delfina Lite - and more can be possible on the faster Delfina Pro, and especially the Flipper. At present, any resulting live sound data can optionally be written in real-time to harddrive for subsequent mixing with other audio tracks, using either HDRecord or AudioLab on the Amiga - or whatever you may use on your platform.

The Moto 56k/~40MHz DSP in the Delfina could run ~16 patches in parallel - this from the Moto team who wrote the synth code snippets - and while mine was oc`d to 80MHz, the new Flipper is faster at 73MHz since it can output at any freq, it won`t need to convert the sample data to play it at some chosen fixed rate, as the earlier Delfina did. It also has quite a bit more memory on board - as well as a single IN/OUT MIDI i/f.

So to allow later editing, it is best to record synth control events which will eventually be done in "Bars And Pipes", via tools at both ends of the tracks, therefore that particular MIDI sequencer will also come in useful. At this level, MIDI and performance data from the 'chill machine' are very similar, both have note-on and note-off events that convey pitch/loudness values, and both have various control codes/events, especially if we also consider the SysEx codes of MIDI.

Without "Bars and Pipes", and without the very sophisticated and intuitive record/edit facility that this MIDI sequencer provides, we are limited to playing DelfDCS in a 'live' context only, or as a single track instrument, its output recorded as an audio file. To tie in the "chill machine" with "Bars and Pipes" makes perfect sense, giving DelfDCS the ability to play alongside any regular MIDI and audio tracks, in exactly the same way that similar soft-synths perform on those other platforms. And just as CuBase has its soft-synth plug-ins, DelfDCS will be able to function as a soft-synth "plugin" for "Bars and Pipes".

As a result, adding a dedicated track-edit window to the `chill machine`, to make the program fully independent, is of a very low priority, meaning zero, as I can't see any sense in it at all. It would be a waste of time, having to virtually `re-invent the wheel` and a waste of an excellent sequencing environment to forgo the use of "BarsNPipes" which is freely available nowadays, while also undergoing continuous development. So that should not present a problem at all, `ptools` are not that hard to hack together, and in this case it is only a question of transferring the codes between DelfDCS and the tracks in "Bars and Pipes" where they will be stored and also edited almost exactly as if they were MIDI sequence data.

Rewriting the DSP parts of the code to work on the PPC would not be a trivial task either, so there are no immediate plans to port it to the new generation of Amiga or its clones. The 56002 DSP is purpose-built for audio generation and streaming, while the PPC is obviously more of a generic type processor. This means that DelfDCS would not work on the AmigaOne (OS4), unless a Delfina or Flipper with its DSP is also available. The GUI part of the program can easily be compiled to run on any Amiga as well as on a `clone`, it is written in fully portable `C` and closely adheres to Amiga OS conventions and the Amiga Style Guide.

The new NatAmi, when it is ready, should be perfect for this program, it has PCI slots where a Flipper can be plugged in. On the other hand, it will also have some additional 3D capabilities, coded on the FPGA, and this might allow for a re-written engine in DelfDCS to run DSP circuits/commands. We will have to wait and see...

Specifications

"So how do I use it?" Notes or sounds can be played on either the Amiga's qwerty keyboard, similar to the way that most trackers implement it, using F1 - F5 for octave change, or alternately from a MIDI keyboard. Both methods will be able to do the usual stuff that keyboards are expected to do on synthesisers, namely send pitch control values to the oscillators as well as to the filter (DCF), though 'loudness' or aftertouch values can not be generated by the qwerty keyboard. Pitch values and volume information for DCO and DCA, and trigger pulses for the envelope generator (ADSR) and/or for the step sequencer, can be easily generated by either input source.

Of course to get any sound to appear at all, a `patch` needs to be created first. This can be as simple as connecting the output of a DCO to an Output channel, which will result in a continuous tone, its timbre being determined by the DCO`s wave-shape and its pitch set by the DCO`s frequency settings dial. We could also set one of the DCO`s control sources to `Keyboard`, and then the DCO`s pitch will be controlled by the last key that has been pressed. Obviously there is no `Attack` nor a `Release` slope to the note yet - the easiest way to achieve that is by routing the DCO`s Output to the DCA instead of to an Output channel and sending that to an Output channel, then set a control source on the DCA to ADSR, giving our sound an envelope. Every time we press a key, the ADSR`s duty cycle will be triggered, but only if we set the ADSR`s trigger input to `Keyboard`. The note will have a fast or slow `Attack`, depending on the equivalent dial setting on the ADSR module, it will have a certain length of `Delay`, and a final `Release`, where the note will trail off. The length of these is obviously set by the Delay and Release dials on the ADSR module.

But let`s make it a bit more exciting than just have a straight and unfiltered wave-shape. We can achieve just that by routing the DCO`s output to the DCF, then patch the output of that into the DCA, just as we had done with the DCO previously. Now we will have a DCF modified tone instead of a straight one. Obviously the DCF will have to be controlled as well, so let`s set one of its control sources to Keyboard. This will track the pitch of the last keypress, modifying the DCF to be `compatible` with any frequency that we play on the keyboard, avoiding distortions that would otherwise occur. We could also attempt to set one more control on the DCF, so let`s choose ADSR for that, as this will create some interesting changes in tone colouration as the envelope of the note goes through the stages of the ADSR. And finally we can also play around with the two dials of the DCF until we have found some optimal setting.

While not much, this should at least give you a start, and as you can probably see, the possibilities for unbridled creativity are endless. So rather than me continuing to explain other patch combinations, I think it would be best if I left you to your own imagination as I am quite sure that you will soon be able to start finding your very own style and run with it. Obviously there will be more detailed patches described in the manual, as well as example patches that can be loaded into the program.

"Is this all there is to it?" One planned possibility is an option to connect any two of the synth's controls to some external control source, such as an analogue joystick, plugged into the machine`s joystick port, or the pitch/mod wheels of a MIDI keyboard. The synth controls will also be accessible while looping some sequence, while the sequence itself will have the ability of being transposed from the keyboard as well as being re- triggered on the fly by a key press. Eventually, and hopefully, all this should be possible even while replaying some previously recorded tracks. However, to begin with, DelfDCS will be able to record your sonic creations directly to hard drive, as mono or stereo audio tracks. Just as if you were playing one of those original (mono) hardware synths.

There is one more rather interesting addition that I thought should be included: a multi mode operation (available only from the qwerty keyboard), where we can select between the Arab Tone System, the strangely named "solfeggio mode" (see also wikipaedia`s entry), and the officially accepted "equally tempered scale". Each mode will generate its own natural and highly individual frequencies from the keyboard input, adding entirely new ways of expression/experience to this already versatile instrument.

Present status:

The sound generating engine of the synth is partly running on the DSP, that is, some of it is already written and partly hooked in, so the synth - "DelfDCS", or to use its more colourful name, "tHe cHilLmAchInE" - or even "7H3 cH1lLm4cH1n3" ;-) - can already produce and modify sounds generated in real-time. And this is the amazing part - it is all done on our humble Amiga running on a `lowly` `030 CPU! A decades old dream... :-)

On the 68k side, most of the control window (see above screengrab), representing the user interface, as well as some other important functions, are already in place, though not yet properly connected to the DSP program's control points, or even to other functions. At this time there are only a couple of major routines that still remain to be done: one of those is the timer-device controlled step-sequencer/arpeggiator, which is partly complete - see "tapedeck" buttons, BPM dial and the scrolling listview of note steps to the right of these. This will also include some special effects like portamento, vibrato, emphasis, etc. which can be edited by right clicking on the particular entry when it is on the "edit" line, or within the box. However, this will have a live record facility to quickly grab a riff `in mid-flight`, and click play to loop it on the next bar.

Presently the chillmachine ould only work as a solo intrument, for additional voices there will also have to be some method to record/edit the notes played on the computer`s qwerty-keyboard or on any connected MIDI keyboard, plus of course all patches/control-changes that are played on the synth`s user-interface. This also needs to grab the controls of DCOs, the DCF, the DCA or ring modulator, ADSR, etc., just as it is happening in real-time. As mentioned above, in the "Requirements" section, the plan is to eventually implement this recording via "ptools" in "Bars and Pipes" to utilise tracks in that program to record and then to edit all our data, and then to replay it. Each track can then spawn its own "chill" window for that exact purpose.

To get a more professional look, an increased control-range, as well as better handling, it was decided that a custom gadget is needed, to replace the conventional and readily available sliders, and connected, so that it can quickly send its parameters to the DSP program. You can see these round buttons in the screen-grab of the "chill-machine".

Some DSP code was originally written by a group of Motorola employees, who then published it as an example in a computer music related magazine, which was where I first came across it. However, that appears to be its only use - an example - as when I asked Michael Henke (of DelfMPEG fame) if he could help me with it, he decided that most, or all of that code needed to be rewritten, since the published code was partly incomplete and it wasn`t doing everything quite the way it was supposed to. As I am not familiar with DSP coding, I had to accept his word for it. Obviously he couldn't resist the challenge, and fortunately for me, or rather for the project, he has done a fair job this far, having almost completed his own version of the synth engine that he had started in spring 2006.

Sadly at this point in time I managed to `lose` my A4000`s functionality - I suspect this is caused by the mobo SIMM sockets which I had to wire-fix some years previously, when the plastic retaining clips broke off - unfortunately at present only my A4000 has a Delfina card available for use. This means that completing the program and the DSP code will have to wait until I can replace that problematic mobo.

And now that I look at all this text above, it occurs to me that some of it will have to make up parts of the user`s manual, or DelfDCS.guide, as that is still on the TODO list...

This program has been slow in coming, partly due to a shortage of resources, and partly due to a tendency of this old hacker to follow the phases of some distant star. A 24 hour day seems far too short, so either 28 or even 36 hours would be far more useful, but that clashes with the culturally and commerciallt accepted daily 9-5 cycle that we are expected to fit our lives around. This usually results in a feeling of being jet-lagged and too sluggish to go on.

As to how long it took to get this far, a link to the project's history is to be found below - and if you have time to kill, go ahead and read it. We live in the End Times - the Mayan Calendar, Bible, Nostradamus, Buddhists, astrologers as well as astronomers, plus pretty much everyone else, all seem to agree on the general idea of unique events unfolding. In any case, the Amiga is evolving, just like ourselves, and any end product that will enhance its hack value should be worth all the effort. It will give me one more trick to avoid any evil and rude system - or what I see as the platform/OS of - and for - suits, such as the NWO.

Only Amiga is Fun!

If anyone thinks they can contribute with code, catalogs, guides or whatever, then this program could be made open source and set up as a CVS. You can send me a note here:

History