dsq-1: open-source software synthesizer

[Rikki Cattermole via Digitalmars-d-announce]

On 30/03/2015 6:02 a.m., D. Martinez wrote:
> 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

That's a rather interesting license. Maybe add a TLDR into your readme? 
As I doubt most people here have seen it before.