dsq-1: open-source software synthesizer

[D. Martinez via Digitalmars-d-announce]

I am releasing today a first version of dsq-1: a software 
synthesizer modeled after some great 80's hybrid synths, Ensoniq 
ESQ-1 and SQ-80. The 'd' in the project's name stands for the 
author's first name, as well as, you know. ;)

The source code for the project is currently located on github:
https://github.com/martinez/dsq1

This project is a huge work in progress and is far for complete; 
the sound output is not very interesting in the current state and 
needs a lot of work.
Most of the architecture is implemented according to 
reverse-engineered information, some done by me, but mostly from 
Rainer Buchty which has done an extensive amount of work on this 
machine (cf. his website).

My progress is not going fast on this project, because I am 
currently busy with my Ph.D and other work. I share it because it 
will interest whoever wants to hack on this machine, because it 
implements the proprietary formats used (patch, waverom, etc..), 
or whoever wants to help on synthesis. I happily accept 
contributions.

Working with D has been generally a joy (coming from a C++ 
background), but there have been a number of annoyances to me, be 
it bugs or lack of features. I have kept a list of observations, 
into the project's TODO file. Most importantly:

1. My main grief so far has been the compilers. LDC has failed on 
me with a stack trace and no other information. This is 
reproducible on the latest commit, when there exists a dependency 
to the "tkd" library. Last time I checked this bug was reported 
on the issue tracker but not fixed yet. On the other hand the dmd 
compiler however has been very stable for me.

2. The function attributes: @nogc nothrow. These relate to my 
realtime audio thread because I want neither of these things to 
occur; my thread runs unmanaged by the D runtime and I appreciate 
the static checking. But I don't use it: why?
I use writefln a lot to debug my implementations, which is 
incompatible with either assumption. I wish it were possible to 
bypass @nogc nothrow in debug mode, only to emit a warning. To 
change dozens of functions to set @nogc on/off depending on usage 
context is not practical. I hope D can provide a better solution, 
than systematic use of sed scripts. :)

---
About the project itself for the interested:
See TODO.txt for a (non-exhaustive) list of things missing.

It has many subprojects, organized as such:
- synth: it implements the various parts of the softsynth (EG, 
OSC, LFO, ...)
- jack: softsynth for Linux implemented as a jack client
- synthui: user interface (nothing is done right now). not to be 
used directly, the process is instantiated by the softsynth and 
communicates via OSC protocol.
- synthlib: components that relate to the internal proprietary 
structures: patches and waves. relevant if one is implementing a 
librarian for instance
- liblo: binding to a OSC client/server library with C API
- util: various stuff for implementing and testing. math 
routines, plotting, fixed point. The fixed-point implementation 
math.fp is intended as a drop-in replacement for float and is a 
template for various precisions on 32-bit ints (ie. 16/16, 24/8 
etc).
- fptest: a playground project for testing fixed-point math
- esqtest: a playground project for independently testing 
internal components of the softsynth (wavetable synth, LFOs...)
- banker: what could be a bank management (aka. "librarian") 
application in the future. it can current open and display banks 
stored on disk (sysex/mdx), but no write support. GUI is horrible.
- to appear in the future: vstplug. a vst implementation, which 
should not be hard to do, possibly using the dplug library.

I make this project in the hope to port it to embedded ARM, if it 
ever gets somewhere. I have some analog CEM VCF chips to use in 
this project from one of these dead units. The bad thing is that 
because the unit's dead I don't have a good basis for comparison. 
So I am aiming for good results, not 100% fidelity with the 
original. I am not myself very good in math nor DSP programming, 
so again I welcome the work of contributors.

The porting to ARM, specifically STM32F4, will be hopefully an 
opportunity for me to extend on the work of others on embedded D.
link for reference: 
http://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22