electro-smith / daisysp

A Powerful DSP Library in C++

DaisySP • A Powerful DSP Library in C++

DaisySP is an open-source DSP (Digital Signal Processing) library that provides a comprehensive collection of modular components for creating audio software across various contexts, facilitating the development of high-quality and customizable audio applications.

📱 Applications

• Embedded hardware using the Daisy Audio Platform
• Audio plug-ins (VST, AU, JUCE)
• Mobile apps (iOS, Android)
• VCV Rack modules

✨ Features

• Control Signal Generators AD and ADSR Envelopes, Phasor
• Drum Synthesis Analog/Synth Bass/Snare Drum Models, HiHat
• Dynamics Processors Crossfade, Limiter
• Effects Processors: Phaser, Wavefolder, Decimate, Overdrive
• Filters: One pole Lowpass and Highpass, FIR, SOAP
• Noise Generators Clocked Noise, Dust, Fractal Noise, Particle Noise, Whitenoise
• Physical Modeling Synthesis Karplus Strong, Resonators, Modal Synthesis
• Sampling Engines Granular Player
• Synthesis Methods: Subtractive, Physical Modeling, FM
• Utilities: Math Functions, Signal Conditioning, Aleatoric Generators, Looper, DCBlocker

🚀 Getting Started

• Get the source: git clone https://github.com/electro-smith/DaisySP
• Navigate to the DaisySP repo: cd DaisySP
• Build the library: make
• Make some noise with the example programs!

👨‍💻 Code Example

#include "daisysp.h"

static daisysp::OnePole flt;
static daisysp::Oscillator osc, lfo;
float saw, freq, output;

for(size_t i = 0; i < size; i++)
{
  freq = lfo.Process();
  saw = osc.Process();

  flt.SetFrequency(freq);
  output = flt.Process(saw);

  out[i] = output;
}

❤️ Community

Connect with other users and developers:

• Chat on the Daisy Discord Server
• Join the Daisy Forum

🏆 Contributors

Thank you to all of the awesome people who have given their time and effort to this project!

Made with contrib.rocks.

✍️ Contributing

Here are some ways that you can get involved:

• Proof read the documentation and suggest improvements
• Test existing functionality and make issues
• Make new DSP modules. See issues labeled "feature"
• Port existing DSP modules from other open source projects (MIT). See issues labeled "port"
• Fix problems with existing modules. See issues labeled "bug" and/or "polish"

Before working on code, please check out our Style Guide.

⚠️ License

DaisySP uses the MIT license.

It can be used in both closed source and commercial projects, and does not provide a warranty of any kind.

For the full license, read the LICENSE file in the root directory.

daisysp's Issues

Phasor's name ?

I'd like to know why this module is called "phasor".
It seems to be just a ramp generator or sawtooth oscillator and not a complete phasor effect.
Thank you for clarifying that.
Xavier

Emscripten support

I've tried building DaisySP based code with emscripten. There was 1 error (not really an error, but some limitation with emcc not understanding a particular combination of access to enum via template object pointer?) and a few warnings related to implicit int/float convertion.

Having fixed that in #141, compiled result runs in the browser.

What's the C++ version used for DaisySP?

The makefile doesn't explicitly state the C++ standard to be used, as far as I can tell.
Is there officially a standard to use? I would suggest to use at least c++17, so that things like if constexpr () become available. This would be really nice for an embedded project, as it allows to do a lot of computation at compile time and save precious cycles without cryptic lookup tables and other unreadable code. There are more advantages, of course, but this would be the most useful IMO.

Change examples to not require input signal to demonstrate functionality

Affected modules:

• reverbsc
• pitchshifter
• stereodelay

Doc Deployment is failing

There are a few warnings that I don't see when building the docs on my end, but what's weird is it worked before we added the conditional.

I think its the lack of skip cleanup as it is running git stash --all before deploying.

Install instructions for dependencies on macOS are incomplete

Hi, great work so far!

Unfortunately, installing the ARM toolchain as per the instructions on the Wiki on macOS Catalina did not work for me as macOS security 'cannot confirm the developer identity' of the compiler. Of course, there are workarounds and homebrew casks etc for getting this done.

I'm sure this has been discussed before (and perhaps I have missed it), as per the mutable build environment, would it be appropriate to have a contained build environment for Daisy? If so, you could hook up something like VSCode to behave as a cross-platform IDE which operates on shared files between the container and the host OS. Further use of openOCD and thus GDB means you would have a consolidated workflow for code>make>debug that uses the same tools across all platforms. Of course, there are many benefits and drawbacks to this approach.

"How to Build" link in the README is broken

Add automated style checks from PR

@TheSlowGrowth mentioned setting up clang-format checks from PRs

This would be immensely useful, and time-saving.

I've been using the clang-format stuff with Visual Studio for a while. So I'm pretty much sold on using that on git for the style checks. But I've also seen stuff like AStyle used for this.

Open to other alternatives as well, but clang-format feels like the frontrunner.

Add some audio-input based examples for some of the effects processors

PitchShift, and ReverbSc come to mind.

As mentioned in #60 there's no harm in having more working examples, and it would be nice to be able to have some examples that use the audio inputs (as long as there is already a working example that doesn't require them already).

Oscillator::PhaseAdd missing include for M_PI

Include dsp.h and use TWOPI_F macro.

inline documentation changes

within makedoc.py/template.tex:

• remove indentation of code blocks
• formatting for better visual separation between sections

on a per module basis:

• move TODO sections to bottom of h files, and add section headers for them.
• reorganize (mostly the top few sections of comments) on all module headers.

---

example format:

Module/Class Name

Description

Something about the module blahblah

Credits

Author/Source: Person Person
Date Added: December 2019

Data Types

enums, templates, types, etc. etc each in their own subsection:

Curve

blah

Something Else

Functions

Init

arg1: rate in Hz

defaults:

code block

Process

code block

Parameters

Parameter Name

Description

Range

Units

code block

etc.

TODO:

Example

code example

Consider -Werror

Being a relatively new code base, we could think about including -Werror in the compiler options. This would help a lot to keep the compilation output clean and also help find bugs quickly.

Add platform dependent assert macro

It would be great to have a platform-independent way for assertions (e.g. bkpt 255 on ARM, assert(), etc.).

1. Create Source/platform.h
2. Add macro D_SP_ASSERTFALSE that triggers an assertion. The JUCE macro jassertfalse could serve as a template and could be extended for bkpt 255 when compiling for embedded targets.
3. Add macro D_SP_ASSERT(bool condition) that triggers D_SP_ASSERTFALSE if !condition
4. Replace all existing assertions with these macros

The same file could also be very useful in libDaisy.

AdEnv - Changing Attack/Decay time during stages can cause envelope to exceed its given range.

With knobs mapped to attack/decay respectively, changing one quickly will some times cause the envelope to go much higher than the values set.

I haven't checked to see if it happens when curve is set to 0 (linear), but worth investigating.

---

Temporary band-aid, change attack/decay times on re-trigger of the envelope instead of at a constant rate.

String.h breaking compilation after directory refactoring

New directory structure requires listing all folders with -I parameter to gcc. As a result, string.h ends up shadowing system header when something like #include <string.h> is used in third party code

It was not an issue previously, as only top level directory was added to include list.

add .clang-format file for automatic code formatting

To help enforce the coding style, it could be helpful to add a .clang-format file at the repository root. In Visual Studio, a simple keycombination can then be used to directly reformat portions of code - or an entire file.

Extending on this: Pull request can be tied to an automatic formatting check supplied by clang-format. I can help with that.

C++ 11 compatibility

This function is raising the following error if DaisySP is being built for C++11:

 error: body of constexpr function 'constexpr uint32_t daisysp::get_next_power2(uint32_t)' not a return-statement

That's because that version of C++ standard mandates constexpr to include just a single return statement, later revisions lifted that restriction. The function itself is not used anywhere in library code, but it was added as part of FIR filter commit.

So it should probably be removed, rewritten or guarded by __cplusplus version check if compatibility with C++11 is desired.

ADSR — Segment times not functioning properly

Looks like the coefficients aren’t being set when switching between segments.

Looks like an easy fix.

Filter consistently crashes for folded square waves

Hello!

I am seeing a consistent filter crash when feeding in a folded square wave for a custom patch project. I've tried a variety of frequency values for the filter from 1000 - 20000 hz.

Is there any suggested tooling for setting breakpoints/debugging? I can try and track down a call stack/device state if it is possible.

Add automated build checks

In addition to the automated style checks and doc deployment (see #35), the build could be checked as well.

The key will be to install arm-gcc-none-eabi on the travis VM. I'll have a look how that could work.

Port atone from Soundpipe

https://github.com/PaulBatchelor/Soundpipe/blob/master/modules/

Use Tone as example, it was originally a Soundpipe module as well.

https://github.com/electro-smith/DaisySP/blob/master/modules/tone.h

https://github.com/electro-smith/DaisySP/blob/master/modules/tone.cpp

ADSR produces small step and audible click in decay or release phase

https://es-daisy.slack.com/archives/CU7QB1K5Y/p1620032978070300

There's a rather unfortunate comparison, which forces the output to zero once the envelope falls below 0.01.

I'd suggest using a negative target value for the the filter and clip the output at zero. Also, for the attack a target value > 1.0 produces a more pleasant attack phase.

Migrate CI to Github Actions

It seems like, short of trying to request new OSS minutes every month (which some brief searching online shows that also seems to be frustrating and potentially fruitless) Travis CI is no longer really free for open source.

Fortunately, we have some stuff tested on the DaisyExamples repo that uses Github Actions, and can easily be migrated here.

Folder typo in build instructions

The build instructions for Mac say

Once downloaded, extract the folder from the .tar file, and move it to a destination of your choice for example, ~/Documents/

I think that should be ~/Developer/ (like it is in the Linux instructions) because the environment variable added to .bash_profile is ARMGCCPATH=~/Developer/gcc-arm-none-eabi-9-2019-q4-major/bin

Module subfolders

A suggestion: Move modules into subfolders to make them easier to find.
I would assume that this library can grow rather quickly and it might be a good idea to organize things from the start.
Subfolders could include:

• modulators
• soundsources
• utilities
• filters
• fx
• ... more?

Adenv crashes with segment times = 0

As dicussed on the Daisy forum.

Bitcrush does not work properly

The bitcrush module is outputing a huge DC offset in my testing, it seems that there's a bug in the code.
In line 27 of bitcrush.cpp:
out *= (65536.0f / bits) - 32768;
I believe it should be
out *= (65536.0f / bits);
out -= 32768;
or something equivalent instead.

Add a .vcxproj in every example directory

Currently, the main Visual Studio solution/project compiles fine using the VisualGDB addin. It would be nice to have the same for the examples. Having a project template would be even better!

Shaper oscillators emit DC

Hello

Something I just noticed when using DaisySP in my SuperCollider plugins is that some of the shaper oscillators (ZOsc, VarShape and varSaw) emit DC and it is necessary to use a dc blocker in between their outputs and the system output at the moment. For ZOsc and VarShape it depends on the "shape" parameter it seems how much dc is in there.

ThankS!

Build of drip module fails

When building, I get the following error:

modules/drip.cpp: In member function 'int daisysp::Drip::my_random(int)':
modules/drip.cpp:20:18: error: 'rand' was not declared in this scope
     return (rand() % (max + 1));
                  ^
modules/drip.cpp: In member function 'float daisysp::Drip::noise_tick()':
modules/drip.cpp:26:24: error: 'rand' was not declared in this scope
     temp = 1.0f * rand() - 1073741823.5f;
                        ^
Makefile:177: recipe for target 'build/drip.o' failed
make: *** [build/drip.o] Error 1

This same issue was mentioned in electro-smith/DaisyExamples#68, but was closed by the author. The author's suggestion of adding #include <cstdlib> does indeed solve the problem.

The author of the referenced issue was using Windows. I am using WSL on Windows, so I don't think this is a Windows-only issue; I can test on a proper Linux distribution to verify this.

Building on a Raspberry Pi ?

Hello all

Thanks for this great library. I have implemented some of the classes from DaisySP in a little collection of SuperCollider plugins (https://github.com/madskjeldgaard/mkplugins) and it works really great! Thanks so much...

The only problem I have found is that I can't seem to build the Daisy library on a Raspberry Pi.

I am trying on a Raspberry Pi 4 armv7l running cmake version 3.16.3.

Here's the error:

Scanning dependencies of target DaisySP
[  1%] Building CXX object DaisySP/CMakeFiles/DaisySP.dir/Source/Control/adenv.cpp.o
[  2%] Building CXX object DaisySP/CMakeFiles/DaisySP.dir/Source/Control/adsr.cpp.o
[  3%] Building CXX object DaisySP/CMakeFiles/DaisySP.dir/Source/Control/line.cpp.o
[  4%] Building CXX object DaisySP/CMakeFiles/DaisySP.dir/Source/Control/phasor.cpp.o
[  5%] Building CXX object DaisySP/CMakeFiles/DaisySP.dir/Source/Drums/analogbassdrum.cpp.o
/tmp/ccCj9Fuc.s: Assembler messages:
/tmp/ccCj9Fuc.s:65: Error: selected processor does not support `vminnm.f32 s20,s20,s15' in ARM mode
/tmp/ccCj9Fuc.s:179: Error: selected processor does not support `vmaxnm.f32 s0,s0,s16' in ARM mode
/tmp/ccCj9Fuc.s:182: Error: selected processor does not support `vminnm.f32 s16,s0,s22' in ARM mode
/tmp/ccCj9Fuc.s:355: Error: selected processor does not support `vmaxnm.f32 s0,s0,s15' in ARM mode
/tmp/ccCj9Fuc.s:358: Error: selected processor does not support `vminnm.f32 s0,s0,s14' in ARM mode
/tmp/ccCj9Fuc.s:390: Error: selected processor does not support `vmaxnm.f32 s0,s0,s14' in ARM mode
/tmp/ccCj9Fuc.s:393: Error: selected processor does not support `vminnm.f32 s0,s0,s15' in ARM mode
/tmp/ccCj9Fuc.s:423: Error: selected processor does not support `vmaxnm.f32 s0,s0,s15' in ARM mode
/tmp/ccCj9Fuc.s:426: Error: selected processor does not support `vminnm.f32 s0,s0,s14' in ARM mode
make[2]: *** [DaisySP/CMakeFiles/DaisySP.dir/build.make:115: DaisySP/CMakeFiles/DaisySP.dir/Source/Drums/analogbassdrum.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:1022: DaisySP/CMakeFiles/DaisySP.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

Support for Faust Programming

Are there plans to make the Daisy work with Faust ?

MIDI-CV clock script?

Hi, I was wondering if there is already a midi-CV script that could put out midi clock to trigger in order to sync my eurorack to a midi device? I'm not very familiar with C coding unfortunately so i dont know where to even begin to learn how to do it.

Port many things from soundpipe

Here is a list of modules to port from soundpipe:

• adsr
• allpass
• autowah
• bal
• biquad
• bitcrush
• blsaw
• blsquare
• bltriangle
• comb
• fold

---

just a starting point, the list could go on

Implement Fast Convolution algorithm

I'd like to add a fast convolution support to DaisySP. Let's discuss the requirements.

1. Definition
In short, it is an algorithm that allows computing linear convolution of a stream of data with a constant (usually long) vector in logarithmic rather than linear time by employing the fact that convolution in time domain is equivalent to multiplication in frequency domain, and the latter could be efficiently computed with Fast Fourier Transform in O(N*logN) time.
Typical applications of linear convolution are FIR filtering and reverberation.
There are two problems that are immediately faced with naive implementation:

• The Fourier transform performs cyclic convolution rather than the required linear convolution
• FFT is inherently block-based and thus introduces latency
  There are elegant solutions to both problems.
  The linear convolution may be redefined via cyclic convolution with a smart choice of FFT size and input signal padding, which is usually referred to as "Overlap and Add" and "Overlap and Save" algorithms (the latter will more appropriately called "Overlap and Discard" in this issue). The latency may be made arbitrarily small and even completely avoided by partitioning the filter kernel into a series of segments that are processed separately and recombined at the output which is possible since convolution is a linear operation.

2. High level requirements
2.1. The algorithm should be functionally equivalent to the existing arm_fir_f32 function
2.2. The algorithm should have valid results for any filter kernel lengths (including not power-of-2 and add values)
2.3. There is no preference between Overlap-and-Save and Overlap-and-Discard algorithms (initial profiling on Daisy shows that O&D has a slight edge)
2.4. The algorithm should reuse existing arm_* functions as much as possible unless it can be shown that custom implementation gives at least 10% overall performance increase
2.5. The algorithm should not use dynamic memory allocation
2.6. The algorithm should support the following channel mappings:
2.6.1. Mono -> Mono (1 filter kernel) [mandatory]
2.6.2. Mono -> Stereo (2 filter kernels) [optional]
2.6.3. Stereo -> Stereo (2 filter kernels L->L, R->R) [optional]
2.6.4. Stereo -> Stereo (4 filter kernels L->L, L->R, R->L, R->R) [optional]
2.7. The algorithm should allow multiple instances
2.8. The algorithm should use single precision floating point data
2.9. The algorithm should support single sample processing API
2.10. The algorithm should support block sample processing API for arbitrary block sizes
2.11. The algorithm should have the following unit tests:
2.11.1. Verification of processing results against arm_fir_f32 for various filter lengths, including non-power-of-2 and odd values, the target metric should be root mean squared error between reference and device-under-test and should not exceed -90 dB
2.11.2. Performance profiling (processing time per sample vs. filter kernel), including comparison with arm_fir_f32
2.11.3. Performance profiling (processing time per sample vs. block length) including comparison with arm_fir_f32
2.12. The unit tests should be self-contained and finish the execution with clear verification result (e.g. "PASS" or "FAIL") printed to console over USB UART.
2.13. The algorithm should be accompanied by an example application (e.g. spring reverb, since it's hard to do algorithmically)
2.14. The algorithm should be implemented in object-oriented fashion and follow DaisySP coding style

**3. Implementation details **
3.1. I propose to have two separate implementations, one is pure FFT convolution with latency and another is the partitioned convolution which would be based on the first one. In some applications the latency could be tolerated and thus partitioning would introduce unnecessary processing overhead.
3.2. In general, FFT convoloution algorithms allow some freedom in selecting the FFT size to decrease average processing cost at the expense of even more latency. I propose to limit the FFT size to 2x of the filter length (nearest power-of-2 of course). This is a reasonable compromise and also most useful for later inclusion into partitioned convolution scheme.
3.3. So far I haven't decided whether to allow or not run-time filter length choice (up to a pre-configured limit). Fixing it at compile time allows significant optimization (about 15% of throughput).
3.4. ARM filtering routines require the filter coefficients to be reversed in time (i.e. late-first order). I propose not to mimic this behavior as it is counter-intuitive for reverbs especially. But I can add an boolean parameter to flip the impulse response if required.
3.5. The ARM FFT routines inconveniently require out-of-place execution, while also modifying (i.e. corrupting) the input buffer. Otherwise several further optimizations would be possible.
3.6. Currently I propose to have the algorithm contain all necessary memory buffers within its class. Are there any arguments for user-provided memory storage?
3.7. Currently linking ARM CMSIS libraries for FFT and FIR routines significantly bloats the resulting binary. I currently can barely fit into 128kB flash. I didn't investigate it in depth, but it looks like the precomputed tables from arm_common_tables.c are the culprit.
3.8. The straightforward partitioned convolution has individual FFT's lined up in a way that results in a very spiky computation cost. It could easily result in audio drop-outs. Maybe I'll need to come up with some other, less efficient on the average, but more even processing scheme.
3.9. The partitioned convolution can be very efficiently processed in multiple threads in parallel. I'm currently thinking about fake parallelism, where the processing API would be split into two parts: bulk of the work (i.e. FFT's) would be supposed to be executed in the main application loop, while the time critical input/output handling would take part in the audio callback (i.e. in the ISR).
3.10. Just FYI, FFT convolution seems to overtake direct FIR filtering at 64 sample filter lengths on Daisy.
3.11. Haven't decided on the naming yet. My current class is called FastConv. I'm not sure whether to make two classes to implement # 3.1, or simply add compile-time configuration parameter. In the former case, I'd need a name for the second class.

Most probably I'm forgetting something, but I'd like to get the discussion going as soon as possible, so I can adjust my plans.

Enable compilation on native host

Hello!

From the project description and comments within the code, I understood you want DaisySP to be platform independent.

I had this idea I could plug DaisySP into the VCV Rack plugin development flow, and use VCV as a sort of rapid prototyping platform/virtual bench for DSP cores developed with DaisySP, and move to Daisy HW once I have done enough debugging/cleanup.

To achieve this I had to implement very minimal changes to the DaisySP codebase:

• protected ARM assembler with the arm macro and provided alternative code to compile on a standard host
• replaced the usage of M_TWOPI with the value of the expanded macro or with a constexpr in the oscillator and phasor modules ; M_TWOPI is not always defined in math.h, (it is for the ARM GCC, it is not, for example, for the mingw64 gcc).

For reference, this is the Makefile for the VCV plugin build. It is the Makefile shipped with the plugin template, I only had to append the search paths for the DaisySP include and module files.

# If RACK_DIR is not defined when calling the Makefile, default to two directories above
RACK_DIR ?= <path to Rack SDK>

DAISYSP_DIR = <path to DaisySP>

# FLAGS will be passed to both the C and C++ compiler
FLAGS += -I$(DAISYSP_DIR) -I$(DAISYSP_DIR)/modules
CFLAGS +=
CXXFLAGS +=

# Careful about linking to shared libraries, since you can't assume much about the user's environment and library search path.
# Static libraries are fine, but they should be added to this plugin's build system.
LDFLAGS +=

# Add .cpp files to the build
SOURCES += $(wildcard src/*.cpp)
SOURCES += $(wildcard $(DAISYSP_DIR)/modules/*.cpp)

# Add files to the ZIP package when running `make dist`
# The compiled plugin and "plugin.json" are automatically added.
DISTRIBUTABLES += res
DISTRIBUTABLES += $(wildcard LICENSE*)

# Include the Rack plugin Makefile framework
include $(RACK_DIR)/plugin.mk

I hope this could be useful for the DaisySP users and developers.

Best,
nico

Overriding dsp.h

There are a few problems with current implementation that I'd like to solve with a different version of functions defined in dsp.h:

1. current fmin/fmax code for ARM doesn't work with M4 MCUs, because it uses inline ASM that only works with VFP5 FPU on M7.
2. some functions could use platform specific implementations that are already available (i.e. pow/log LUTs on OWL)

Currently I'd have to create a forked version of DaisySP to replace dsp.h for custom implementation.

I wonder if it's not unreasonable to ask for such replacement to be supported officially. The problem with current code is that with quoted includes there's no way to shadow that header with a different file. Something that could probably work is including it like this:

#ifndef DAYSYSP_OVERRIDE_DSP_H
#include "dsp.h"
#else
#include <custom_dsp.h>
#endif

I can provide a PR for this or maybe some better approach could be used for overriding this file.

Process single sample or block, return or replace inconsistency

As I was working on an improvement for the Compressor module, I noticed how some DSP modules have some sort of Process-method to work on a single sample and just return a single output sample. Some use ProcessBlock, some require the input by reference and work directly on the buffer while others work on a given output buffer.
This makes using the library somewhat difficult (sometimes using it inside your input loop in the AudioCallback, sometimes outside)

Now there is something to say for both of these, as processing a block reduces method calls by blocksize (I think? I'm somewhat new to DSP programming) but processing a single sample gives more flexibility.

I would propose adding both options to all modules, if possible. And specifically for the ProcessBlock option: never work directly on the input buffer so that stays clean should the user wish to process that input though another module.

As long as a user doesn't use both single sample- and block-processing in a single AudioCallback, it should be fine, I think.

Would there be any problem with this?

Style guide suggests slow code passing by const &

Passing arguments that fit on a register by reference instead of by value produces slower code, as it requires an extra unnecessary load.
Here's a godbolt exemplifying this:
https://godbolt.org/z/TbYxvxbea
(you can see the extra ldr instruction on line 9)
References should only be prefered for data types that don't fit in registers or have expensive constructors associated with them.

Tone module: awkward name, unused private vars

First of all, cool lib and looking forward to trying out Daisy hardware!

To me the one pole filter being called "Tone" is awkward due to this being an audio library, and a tone is a musical note.
"onepole" is better, or variations thereof depending on preference.
Just a suggestion!

The module also has some unused/unnecessary private variables.

version.h header for preprocessor version checks

It would be neat to include a version.h file that contains a version number so that Daisy projects could use preprocessor statements to check if a matching version of DaisySP is available.

#define DAISYSP_VER_MAJ 0
#define DAISYSP_VER_MIN 1
#define DAISYSP_VER_PATCH 23

This assumes that such a versioning scheme exists already. I haven't seen it yet, tbh.

Tiny documentation error

In

https://github.com/electro-smith/DaisySP/blob/master/modules/adsr.h

there is a small typo on line 40:

/** Initializes the ATone module.

Should be

/** Initializes the Adsr module.

Was a bit confusing as it is the base for the documentation! :)

Documentation - Why not doxygen?

I wonder if it would be possible to use doxygen for the documentation.
Many editors support it out of the box or via plugins which helps enormously. Doxygen also allows for inline code examples, automatic links and many other neat features. I guess there were good reasons to use the custom python solution - if there were technical problems that prohibited doxygen, I could offer help to make it work.

Faust example: include original Faust DSP code

Hey everyone,

suggestion for the Faust Noise example (and all other future Faust examples): include the Faust DSP code in a way that the Faust patch can be previewd in the Faust IDE - faustide.grame.fr.

Also a small tutorial how to wrap the Faust Architecture File for Daisy around which type of export from the IDE (c++ code I suppose?) would be awesome!

Errors when building examples

I just set up the development environment under macOS 10.14.6. When I run ./rebuild_all.sh building DaisySP seems to work but there are errors when building the examples. Here's the output:

Building DaisySP
Done.
./rebuild_examples.sh: line 2: LIBDAISY: command not found
rebuilding examples:
rebuilding examples/adenv/
Makefile:14: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
Makefile:14: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
done
rebuilding examples/bypass/
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
done
rebuilding examples/compressor/
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
done
rebuilding examples/crossfade/
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
done
rebuilding examples/dcblock/
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
done
rebuilding examples/decimator/
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
done
rebuilding examples/delayline/
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
done
rebuilding examples/line/
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
done
rebuilding examples/metro/
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
done
rebuilding examples/nlfilt/
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
done
rebuilding examples/oscillator/
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
done
rebuilding examples/phasor/
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
done
rebuilding examples/pitchshifter/
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
done
rebuilding examples/pluck/
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
done
rebuilding examples/port/
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
done
rebuilding examples/reverbsc/
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
done
rebuilding examples/svf/
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
done
rebuilding examples/template/
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
done
rebuilding examples/tone/
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
done
rebuilding examples/whitenoise/
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
Makefile:13: /core/Makefile: No such file or directory
make: *** No rule to make target `/core/Makefile'.  Stop.
done
creating daisysp markdown files. . . 
    PolyPluck
No example Provided for PolyPluck
    adenv
    compressor
    crossfade
    dcblock
    decimator
    delayline
    dsp
No example Provided for dsp
    limiter
No example Provided for limiter
    line
    metro
    mode
No example Provided for mode
    nlfilt
    oscillator
    phasor
    pitchshifter
    pluck
    port
    reverbsc
    svf
    tone
    whitenoise
done.
Generating documenation for  doc/daisysp_reference.pdf
Created doc/daisysp_reference.pdf
done.
Creating Style Guide PDF
finished.

Oscillator Waveform POLYBLEP_TRI is very quiet

fm2 FM Osc

please make the daisysp::blosc Reset() function public

daisysp::blosc has a reset function. It does not appear to be used. Also, it is private. I've added a PublicReset() function to call the private Reset() function. It can be used to get a (really dirty) sync sound. It 's not a pristine analog sync, but it is a sound (I can send you a demo if you like). please make the daisysp::blosc Reset() function public

Banners on README are broken

After fc89ff5, README looks like this. Maybe andrewikenberry/badges is a private repository?

Problems with the SVF Filter at high cutoff frequencies

I keep having problems with the SVF filter crashing at cutoff frequencies higher than 2500 hz, especially when using more than one instance. When setting the cutoff with a knob and sweeping the frequency, over a frequency in about that range, the filter just crashes and sound from daisy doesn't recover. Whereas using more than one instance of other filters is fine (e.g. the moogladder).

I can't exactly pinpoint why - would it make sense to try and implement the filter with mat approximations and without the doublesampling, to get better performance out of it? It's a shame because as far as I can see it's the only highpass filter in DaisySP right now.