electro-smith / daisysp Goto Github PK
View Code? Open in Web Editor NEWA Powerful DSP Library in C++
Home Page: https://www.electro-smith.com/daisy
License: Other
A Powerful DSP Library in C++
Home Page: https://www.electro-smith.com/daisy
License: Other
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.
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.
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.
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.
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:
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!
It would be great to have a platform-independent way for assertions (e.g. bkpt 255
on ARM, assert()
, etc.).
Source/platform.h
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.D_SP_ASSERT(bool condition)
that triggers D_SP_ASSERTFALSE
if !condition
The same file could also be very useful in libDaisy.
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.
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
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
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.
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.
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).
There are a few problems with current implementation that I'd like to solve with a different version of functions defined in dsp.h:
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.
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!
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.
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.
As dicussed on the Daisy forum.
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.
@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.
Affected modules:
Are there plans to make the Daisy work with Faust ?
After fc89ff5, README looks like this. Maybe andrewikenberry/badges
is a private repository?
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.
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
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.
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:
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.
Here is a list of modules to port from soundpipe:
just a starting point, the list could go on
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! :)
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.
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!
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:
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
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.
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
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.
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.
Include dsp.h and use TWOPI_F
macro.
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.
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.
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.
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.
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.
Looks like the coefficients aren’t being set when switching between segments.
Looks like an easy fix.
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?
within makedoc.py/template.tex:
on a per module basis:
example format:
Something about the module blahblah
Author/Source: Person Person
Date Added: December 2019
enums, templates, types, etc. etc each in their own subsection:
blah
arg1: rate in Hz
defaults:
code block
code block
Description
Range
Units
code block
etc.
code example
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.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.