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

Reply via email to