"Okay. Requirements - or what do I need to run it on?" Preferably a fast Amiga: presently it runs on an '030/50, though an '060 might 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, though I did consider using the PPC too. But of course I have 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. Always try to re-use existing stuff rather than re-inventing.

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 other 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. Here we don`t have to pass through a slow MIDI bottleneck to reach the destination, it happens at CPU or memory speed.

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", multiple instances running on different channels and AHI units, or tracks. By using Exec messaging between those tasks, we can even make one huge instrument for example, with many DCO, DCF and ADSR modules running on each note played, adding complexity and depth.

In fact, 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. A waste of time, IMO, 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 as open source. 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" directly, where they will be stored and also edited almost exactly as if they were MIDI sequence data. If someone has a better idea, you are welcome to add it.

At the moment it is still undecided whether using separate windows for each module would be preferential or not, but maybe the design in the above snapshot will win out. It is compact, though unlikely to be the final picture. On the other hand, being able to have 4-6 DCOs lined up, with a few filters next to them seems a good idea too. There will be changes for certain, cosmetic and functional, or improvements. Skins, maybe, too. This means that it needs to be open source, It would take too long for one person alone. Presently it is SAS C specific - I only tried gcc briefly, so again, it`s not my domain, as learning DSP code already taxes the old grey cells to produce stamina for learning new techniques. Not that young any more - even PostFix fazed me with its alien terminology, that`s why I still run Windoze for hMailServer. Domains and accounts make perfect sense, while the huge manuals of PF mix up things even further.

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. It also runs the OS. This means that DelfDCS would not work on the AmigaOne (OS4) either, 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. An optional MUI/Zune interface would be needed for MorphOS and AROS. The DSP code rewritten to PPC would make it run the same as any win/linux app will do, so why not just use one of those? By now most of us will have a peecee or two next to the Mig, surely.

The new NatAmi, when it is ready, should be also nice to run this program, it has PCI slots where a Flipper can be plugged in. On the other hand, its fast "chipset" will also have some additional 3D capabilities, and coded to use the FPGA`s DSP capabilities, might allow for a re-written engine in DelfDCS to run DSP circuits/commands on the native chipset, without a Flipper and its lib, thus making it fully GPL. But not me, surely...