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

On Sunday, 29 March 2015 at 17:02:54 UTC, D. Martinez wrote:
> 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. :)

Hmm, this sounds like it might be a bug or design flaw.  "debug" is supposed to provide an escape hatch from even pure functions: I don't see why it wouldn't provide the same for @nogc and nothrow.  At the very least, we should have a @nogc/nothrow alternative to writefln to allow such simple debugging.

On Sunday, 29 March 2015 at 17:24:53 UTC, Joakim wrote:
> On Sunday, 29 March 2015 at 17:02:54 UTC, D. Martinez wrote:
>> 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. :)
>
> Hmm, this sounds like it might be a bug or design flaw.  "debug" is supposed to provide an escape hatch from even pure functions: I don't see why it wouldn't provide the same for @nogc and nothrow.  At the very least, we should have a @nogc/nothrow alternative to writefln to allow such simple debugging.

import core.stdc.stdio : printf;

On Sunday, 29 March 2015 at 17:30:39 UTC, Foo wrote:
> On Sunday, 29 March 2015 at 17:24:53 UTC, Joakim wrote:
>> Hmm, this sounds like it might be a bug or design flaw.  "debug" is supposed to provide an escape hatch from even pure functions: I don't see why it wouldn't provide the same for @nogc and nothrow.  At the very least, we should have a @nogc/nothrow alternative to writefln to allow such simple debugging.
>
> import core.stdc.stdio : printf;

I'm aware of that option and thought of mentioning it, but it is inconvenient when dealing with D strings.

On Sun, 29 Mar 2015 17:02:53 +0000, D. Martinez wrote:

> 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.

that's why i wrote `iv.writer` with compile-time format strings and nogc conversions for numbers. it still using `to!` for other objects (including floating point numbers, but this can be fixed). output strings and integral numbers is enough for debug logs for me. althru it's not "vanilla" D, it's still very easy to backport to D2 (actually, "sed" will do). it is build on templates, so it infers attributes. most of the time this is "nothrow @nogc".

and, to stop talking about myself, here is some hackery for you:

  import std.traits;

  auto assumeNoTrowNoGC(T) (T t)
  if (isFunctionPointer!T || isDelegate!T)
  {
    enum attrs = functionAttributes!T|
      FunctionAttribute.nogc|
      FunctionAttribute.nothrow_;
    return cast(SetFunctionAttributes!(T, functionLinkage!T, attrs)) t;
  }


  void myFuncThatDoesGC () {
    throw new Exception("hello!");
  }

  void anotherFunction () nothrow @nogc {
    //myFuncThatDoesGC(); // alas, but
    assumeNoTrowNoGC(() { myFuncThatDoesGC(); })(); // yay!
  }

but don't tell anyone that you got this code from me, or Type Nazis will kill me! ;-)

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.

On Mon, 30 Mar 2015 17:46:07 +1300, Rikki Cattermole wrote:

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

ah, 'cmon, one can google all the info in no time. i'd say it's probably time to stop guiding people on every single detail, this is gone too far.

On 30/03/2015 6:18 p.m., ketmar wrote:
> On Mon, 30 Mar 2015 17:46:07 +1300, Rikki Cattermole wrote:
>
>> That's a rather interesting license. Maybe add a TLDR into your readme?
>> As I doubt most people here have seen it before.
>
> ah, 'cmon, one can google all the info in no time. i'd say it's probably
> time to stop guiding people on every single detail, this is gone too far.

This is a primarily a french license. It took me a good while to understand that it was compatible with e.g. MIT.

Although I'm a little concerned because dub is meant to validate and tell you conflicts in licenses. I don't know if it would be worth adding this one.

On Mon, 30 Mar 2015 18:23:11 +1300, Rikki Cattermole wrote:

> Although I'm a little concerned because dub is meant to validate and tell you conflicts in licenses.

O_O

On 30/03/2015 6:35 p.m., ketmar wrote:
> On Mon, 30 Mar 2015 18:23:11 +1300, Rikki Cattermole wrote:
>
>> Although I'm a little concerned because dub is meant to validate and
>> tell you conflicts in licenses.
>
> O_O

Hey hey hey, context matters!