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. OS3+ is necessary for BOOPSI classes and objects, though it might run on OS2.04 with classact installed. And 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 up to 8 tracks to be played simultaneously - using the 40MHz Delfina Lite - but more should be possible on the faster Delfina Pro, and especially the Flipper. Any resulting sound data can optionally be written to harddrive for subsequent mixing with other audio tracks, using either HDRecord or AudioLab.

To allow later editing, any recording of synth control events will eventually be done in "Bars And Pipes", via tools at both ends of the tracks, therefore that excellent MIDI sequencer will also be required. At this level, MIDI and the data from the 'chill machine' are very similar, both have note-on and note-off events that also convey pitch 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 "Bars and Pipes" provides, we are limited to playing DelfDCS only in a 'live' context, 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 will 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 (zero!) priority, meaning that I can't see any sense in that, since 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 it. "BarsNPipes" 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 track 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 (meaning OS4), unless a DSP Delfina or Flipper 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, or follows, Amiga OS conventions.

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, the NatAmi may have some additional capabilities, in the form of the FPGA, and this may 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" for the instrument 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), send 'loudness', or volume, information (sorry, not the qwerty keyboard) to DCO and DCA, and send trigger pulses to the envelope generator (ADSR) and/or to the step sequencer.

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 control sources to `Keyboard`, and then the DCO`s pitch will also 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 if we set a control source on the DCA to ADSR, then 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`) and the note will have a fast or slow `Attack`, depending on the equivalent dial setting on the ADSR module, a certain length of `Delay`, and a final `Release`, where the note will trail off, the length of which is set by the `Release` dial 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 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 too, 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 appear. 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.

Even a super-optimised `050 will have a hard time trying to interactively filter a 16-bit sample stream, especially if at the same time it has to generate at least two other streams too. And a LFO. Never mind running various timers for beat and successive duty cycles of the ADSR. Then also deal with 22 rotating `sliders`, 42 cycle gadgets, plus another twenty other gadgets of various types. There is also a step-sequencer in its own inset window that can be controlled/edited using the mouse, when it was stopped via its tapedeck style controls. This can run while you play with the sliders, buttons and keyboard, each move altering the sound stream, and every note-on, note-off or slider move can be recorded. Not just as pseudo MIDI data, but also to a hard drive as a .aiff track. IMO a synth `plugin` is probably the main item that could narrow the gap between BarsNPipes and CuBase. It would also give all those `missing` voices a chance to reappear, as if by magic, all fed from synth specific `mod` type data that was previously recorded to BnP`s tracks. This is how to add new tracks to existing tracks, each being played either by track data or live, by the musician, within individual instances of the synth `plugin`.

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 fixed rate, as the earlier Delfina did. It also has quite a bit more memory on board - and a single IN/OUT MIDI i/f.

"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 harddrive, as mono or stereo audio tracks. Just as if you were playing one of those original (mono) hardware synths.

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 this in the screen-grab of the "chill-machine".

There is one more rather interesting addition that I thought should be included: a multi mode operation, 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 already running on the DSP, that is, most of it is already written and partly hooked in, so the synth - "DelfDCS", or to use its more colourful name, "tHe cHilLmAchInE" - or even "tH3 cH1lLm4cH1n3" ;-) - can already produce some interesting sounds and noises, generated in real-time - and this is the amazing part - it is 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 fully connected to the DSP program's control points, or even to all the gadgets. 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 almost complete - see "tapedeck" buttons, BPM dial and the scrolling listview of note steps to the right of these, which will also include some special effects like portamento, vibrato, emphasis, etc. Secondly 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, such as DCOs, DCF, 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 latter as "ptools" in "Bars and Pipes".

Some DSP code was originally written by a group of Motorola employees, who then published it in a computer music related magazine, which was where I first came across it. However, that appears to be its only use - when I asked Michael Henke (of DelfMPEG fame) if he could help me with it, he decided that most of it needed to be rewritten, since the published code was partly incomplete and it wasn`t doing everything quite the way it was supposed to. Obviously he just couldn't resist the challenge, and fortunately for me, or rather for the project, he has done a rather excellent 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 a couple of years ago 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 programmer to follow the phases of some distant star. A 24 hour day seems far too short, 36 hours would be more useful, but that clashes with the culturally accepted and commercially enforced daily 9-5 cycle. This usually results in a feeling of being jet-lagged and too sluggish to do any creative work.

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 - Mayan Calendar, Bible, Nostradamus, Buddhists, astrologers and astronomers, as well as pretty much everyone else seem to agree on the general idea. In any case, the Amiga is evolving, just like ourselves, and any end product that will enhance its fun-factor should be worth all the effort - hopefully. It will give me one less reason for being tied to this Infernal Mark Of The Beast - or what I see as the platform/OS of- and for- 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