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.
