Re: dsq-1: open-source software synthesizer
Am 30.03.2015 um 08:34 schrieb Rikki Cattermole: On 30/03/2015 7:26 p.m., ketmar wrote: what i really want to have is libdub. i.e. turning dub to library, so it can be easily integrated in any D project (rdmd comes to mind first). i don't want D building abilities, for example, but i really like to use it's package management part (and get list of files and compiler flags for that packages). sure, i can do this by parsing dub jsons and execing dub itself to do package management work, but libdub is better... maybe someday i'll wrote such thing. ;-) You can actually use DUB as a library without any issues (within the DUB eco system, just add it as a dependency, otherwise drop the app.d file when building). The API is still not ideal (missing some documentation and needs some cleanup), because it has grown by contribution from multiple people and a public API hasn't been a primary goal at the time. Yeah, the vibe.d/dub guys are amazing at getting stuff working. But horrible at abstraction's especially with library code. Okay.
Re: dsq-1: open-source software synthesizer
Am 01.04.2015 um 11:32 schrieb ketmar: On Wed, 01 Apr 2015 11:28:12 +0200, Sönke Ludwig wrote: You can actually use DUB as a library without any issues (within the DUB eco system, just add it as a dependency, otherwise drop the app.d file when building). The API is still not ideal (missing some documentation and needs some cleanup), because it has grown by contribution from multiple people and a public API hasn't been a primary goal at the time. i have concerns about API stability, though. it's always better to have officially announced library with some guarantees (we will break API on each release is good too ;-). This will happen soon, when it's ready for the 1.0.0 release. It'll then be subject to the usual SemVer guarantees.
Re: dsq-1: open-source software synthesizer
Am 01.04.2015 um 11:33 schrieb Rikki Cattermole: On 1/04/2015 10:28 p.m., Sönke Ludwig wrote: Am 30.03.2015 um 08:34 schrieb Rikki Cattermole: snip Yeah, the vibe.d/dub guys are amazing at getting stuff working. But horrible at abstraction's especially with library code. Okay. Nobody can be the best at everything. So it was a compliment :) You've done an excellent job with them. And by the looks of things, you are now splitting up e.g. vibe.d So again its mostly past tense observation on that front. I'm kinda the opposite. Great at abstractions. Horrible at getting the damn thing working. I personally usually stay away from using overly strong terms like horrible for online conversations, because it's just far too likely that someone gets offended (I'm usually a fan of good irony for example, but almost never use it online). On topic, I don't think that splitting up the library or not does necessarily have anything to do with abstraction. The library is built in a modular way, so that splitting it up mainly just becomes an issue of the build configuration. If you have other examples of where you think the abstractions are lacking, I'd be interested to know of course. I generally value good abstraction as important, but that doesn't always mean that the most extreme abstraction is the best one. Abstraction comes at the cost of added complexity (on the library side, but more importantly on the user side) and sometimes at the cost of performance, so it's always a trade-off.
Re: dsq-1: open-source software synthesizer
On 1/04/2015 10:28 p.m., Sönke Ludwig wrote: Am 30.03.2015 um 08:34 schrieb Rikki Cattermole: snip Yeah, the vibe.d/dub guys are amazing at getting stuff working. But horrible at abstraction's especially with library code. Okay. Nobody can be the best at everything. So it was a compliment :) You've done an excellent job with them. And by the looks of things, you are now splitting up e.g. vibe.d So again its mostly past tense observation on that front. I'm kinda the opposite. Great at abstractions. Horrible at getting the damn thing working.
Re: dsq-1: open-source software synthesizer
On Wed, 01 Apr 2015 11:28:12 +0200, Sönke Ludwig wrote: You can actually use DUB as a library without any issues (within the DUB eco system, just add it as a dependency, otherwise drop the app.d file when building). The API is still not ideal (missing some documentation and needs some cleanup), because it has grown by contribution from multiple people and a public API hasn't been a primary goal at the time. i have concerns about API stability, though. it's always better to have officially announced library with some guarantees (we will break API on each release is good too ;-). signature.asc Description: PGP signature
Re: dsq-1: open-source software synthesizer
On 1/04/2015 11:07 p.m., Sönke Ludwig wrote: Am 01.04.2015 um 11:33 schrieb Rikki Cattermole: On 1/04/2015 10:28 p.m., Sönke Ludwig wrote: Am 30.03.2015 um 08:34 schrieb Rikki Cattermole: snip Yeah, the vibe.d/dub guys are amazing at getting stuff working. But horrible at abstraction's especially with library code. Okay. Nobody can be the best at everything. So it was a compliment :) You've done an excellent job with them. And by the looks of things, you are now splitting up e.g. vibe.d So again its mostly past tense observation on that front. I'm kinda the opposite. Great at abstractions. Horrible at getting the damn thing working. I personally usually stay away from using overly strong terms like horrible for online conversations, because it's just far too likely that someone gets offended (I'm usually a fan of good irony for example, but almost never use it online). I agree, I was quite extreme. In reality we're only talking in shades of grey with a difference of maybe 5 (0 .. 255). There is a reason why most people IRL think I'm a jerk. Always take stuff like this with a grain of salt. It's only meant to make people think about the subject, not as a factoid. On topic, I don't think that splitting up the library or not does necessarily have anything to do with abstraction. The library is built in a modular way, so that splitting it up mainly just becomes an issue of the build configuration. If you have other examples of where you think the abstractions are lacking, I'd be interested to know of course. If I was to start doing it, Vibe.d would be next to useless. No you guys are doing a wonderful job. I really can't stress that enough. I generally value good abstraction as important, but that doesn't always mean that the most extreme abstraction is the best one. Abstraction comes at the cost of added complexity (on the library side, but more importantly on the user side) and sometimes at the cost of performance, so it's always a trade-off. There are more types of abstractions than just classes vs interfaces. What goes into a module for example is a prime example of an abstraction. A purpose.
Re: dsq-1: open-source software synthesizer
On Thu, 02 Apr 2015 00:54:52 +1300, Rikki Cattermole wrote: There are more types of abstractions than just classes vs interfaces. What goes into a module for example is a prime example of an abstraction. A purpose. it's even harder, as i sometimes has troubles deciding what should go into a function... signature.asc Description: PGP signature
Re: dsq-1: open-source software synthesizer
On 2/04/2015 8:42 a.m., Joseph Rushton Wakeling wrote: On Monday, 30 March 2015 at 05:23:18 UTC, Rikki Cattermole wrote: This is a primarily a french license. It took me a good while to understand that it was compatible with e.g. MIT. Compatible in what way? Isn't CeCILL a copyleft license? (It's not 100% obvious to me whether strong or weak copyleft is implied, because their definition of an 'External Module' is unclear: I'm not sure if something is rendered non-external by linking, or merely by static linking, or something else again.) As far as I remember, it should just be ok. The only real issue is with lgpl ext. But again, you can see why I want this clarified.
Re: dsq-1: open-source software synthesizer
On Monday, 30 March 2015 at 05:23:18 UTC, Rikki Cattermole wrote: This is a primarily a french license. It took me a good while to understand that it was compatible with e.g. MIT. Compatible in what way? Isn't CeCILL a copyleft license? (It's not 100% obvious to me whether strong or weak copyleft is implied, because their definition of an 'External Module' is unclear: I'm not sure if something is rendered non-external by linking, or merely by static linking, or something else again.)
Re: dsq-1: open-source software synthesizer
2015-04-01 13:54 GMT+02:00 Rikki Cattermole via Digitalmars-d-announce digitalmars-d-announce@puremagic.com: There are more types of abstractions than just classes vs interfaces. What goes into a module for example is a prime example of an abstraction. A purpose. Which also have it's problem. For example, most symbols in vibe.internal are public. That's because we didn't have `package(identifier)` (and we still don't have, since we're supporting 2.065).
Re: dsq-1: open-source software synthesizer
On 30/03/2015 7:14 p.m., ketmar wrote: On Mon, 30 Mar 2015 18:54:42 +1300, Rikki Cattermole wrote: 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! i'm speechless 'cause it's a great idea (let machine do it work!), but i'm not sure how this can be done with wide broad of licenses out here. and i definetely want to see std.license.compare in Phobos! ;-) I agree, I'm concerned about this as well. But hey, its one of the features the dub developers want to have.
Re: dsq-1: open-source software synthesizer
On Mon, 30 Mar 2015 19:17:35 +1300, Rikki Cattermole wrote: On 30/03/2015 7:14 p.m., ketmar wrote: On Mon, 30 Mar 2015 18:54:42 +1300, Rikki Cattermole wrote: 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! i'm speechless 'cause it's a great idea (let machine do it work!), but i'm not sure how this can be done with wide broad of licenses out here. and i definetely want to see std.license.compare in Phobos! ;-) I agree, I'm concerned about this as well. But hey, its one of the features the dub developers want to have. what i really want to have is libdub. i.e. turning dub to library, so it can be easily integrated in any D project (rdmd comes to mind first). i don't want D building abilities, for example, but i really like to use it's package management part (and get list of files and compiler flags for that packages). sure, i can do this by parsing dub jsons and execing dub itself to do package management work, but libdub is better... maybe someday i'll wrote such thing. ;-) signature.asc Description: PGP signature
Re: dsq-1: open-source software synthesizer
On 30/03/2015 7:26 p.m., ketmar wrote: On Mon, 30 Mar 2015 19:17:35 +1300, Rikki Cattermole wrote: On 30/03/2015 7:14 p.m., ketmar wrote: On Mon, 30 Mar 2015 18:54:42 +1300, Rikki Cattermole wrote: 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! i'm speechless 'cause it's a great idea (let machine do it work!), but i'm not sure how this can be done with wide broad of licenses out here. and i definetely want to see std.license.compare in Phobos! ;-) I agree, I'm concerned about this as well. But hey, its one of the features the dub developers want to have. what i really want to have is libdub. i.e. turning dub to library, so it can be easily integrated in any D project (rdmd comes to mind first). i don't want D building abilities, for example, but i really like to use it's package management part (and get list of files and compiler flags for that packages). sure, i can do this by parsing dub jsons and execing dub itself to do package management work, but libdub is better... maybe someday i'll wrote such thing. ;-) Yeah, the vibe.d/dub guys are amazing at getting stuff working. But horrible at abstraction's especially with library code.
Re: dsq-1: open-source software synthesizer
On Mon, 30 Mar 2015 18:54:42 +1300, Rikki Cattermole wrote: 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! i'm speechless 'cause it's a great idea (let machine do it work!), but i'm not sure how this can be done with wide broad of licenses out here. and i definetely want to see std.license.compare in Phobos! ;-) signature.asc Description: PGP signature
Re: dsq-1: open-source software synthesizer
On Monday, 30 March 2015 at 06:26:00 UTC, ketmar wrote: On Mon, 30 Mar 2015 19:17:35 +1300, Rikki Cattermole wrote: On 30/03/2015 7:14 p.m., ketmar wrote: On Mon, 30 Mar 2015 18:54:42 +1300, Rikki Cattermole wrote: 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! i'm speechless 'cause it's a great idea (let machine do it work!), but i'm not sure how this can be done with wide broad of licenses out here. and i definetely want to see std.license.compare in Phobos! ;-) I agree, I'm concerned about this as well. But hey, its one of the features the dub developers want to have. what i really want to have is libdub. i.e. turning dub to library, so it can be easily integrated in any D project (rdmd comes to mind first). i don't want D building abilities, for example, but i really like to use it's package management part (and get list of files and compiler flags for that packages). sure, i can do this by parsing dub jsons and execing dub itself to do package management work, but libdub is better... maybe someday i'll wrote such thing. ;-) +1 E.g. using libdub in my project DlangIDE would be much easy than command line interface.
Re: dsq-1: open-source software synthesizer
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!
Re: dsq-1: open-source software synthesizer
On Sun, 29 Mar 2015 17:02:53 +, 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! ;-)
signature.asc
Description: PGP signature
Re: dsq-1: open-source software synthesizer
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.
dsq-1: open-source software synthesizer
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
Re: dsq-1: open-source software synthesizer
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.
