Comments (8)
Agreed, just after I finished getting everything running with CI I had considered the same disadvantage.
The cost of maintaining a separate no_examples
branch for the ArduinoDaisySP library is beginning to seem much less than having to add/maintain a load of tests specifically for daisysp.
Still, though, we're not testing the DaisySP examples on PR since we would need to have libdaisy to do that. So I'm still deciding the best solution to that problem.
Also, worth mentioning that we do have a Daisy slack group if you're interested in that. For now it's mostly been for announcements, and trouble shooting. But its a good place to discuss things that don't necessarily fall into issue-territory.
from daisysp.
You might be able to wget a binary package from Arm's toolchain page since I think it contains binutils and everything else it would need.
I know STM32Duino has a pretty robust CI setup, but it looks like they're using Github Actions now with a few extra tools for dealing with all of the Arduino-building.
from daisysp.
Build job seems to work.
I'd like to add ./rebuild_examples.sh
but that relies on libdaisy being installed in the parent directory.
We'd have to manually clone the repo during the build process, but how do we then specify the specific commit to checkout? My solution would be to add libdaisy as a submodule, but that has its own drawbacks...
from daisysp.
sweet!
Yeah, the examples tie in with #25 anyway. I'm going to move those to DaisyExamples since that already has libdaisy and DaisySP as submodules, and then we can end up setting up the CI there to do a rebuild_all.sh
check.
from daisysp.
and at some point it might be nice to add some non-libdaisy tests so that we can just get the daisyp modules compiling since some of the header only files won't throw errors until a source using it is compiled.
Though, I'll have to toy with how small of an arm-none-eabi project I can get going, because I don't want to drag in a million files for tests..
from daisysp.
Alright, this appears to be working. It does fail to deploy, but I still haven't set up the electro-smith github page so that's to be expected.
I'm going to leave this open until it's passing.
from daisysp.
Alright, deployed and all passing
from daisysp.
Great!
A little afterthought: I agree it is a good idea to keep this repo free from dependencies. However, moving the examples to a separate repo has two disadvantages:
- You'll somehow have to compile the header-only modules, as you mentioned before. That means you'll manually have to setup some C++ file where EACH FUNCTION in this module is called at least once so that all of them are actually compiled. This basically means to build another "dumb" example for each header-only module.
- Having the examples here means that you'll see if they work, before merging a PR. As example and module go hand in hand, I think this is a very important step. Otherwise the example and the module become kind of decoupled and a change to the module will have to consist of two separate PR in two separate repos that have to be synchronized somehow during the review process.
from daisysp.
Related Issues (20)
- Overriding dsp.h HOT 5
- String.h breaking compilation after directory refactoring HOT 4
- Emscripten support HOT 1
- Problems with the SVF Filter at high cutoff frequencies HOT 7
- Building on a Raspberry Pi ? HOT 4
- Shaper oscillators emit DC HOT 2
- Style guide suggests slow code passing by const & HOT 1
- ADSR produces small step and audible click in decay or release phase HOT 4
- C++ 11 compatibility HOT 9
- Add platform dependent assert macro HOT 3
- Pitch shifter accepts transpose < 0.0f but does not work HOT 1
- documentation build action is failing HOT 1
- std::sin usage in Looper HOT 3
- Svf filter does not like to be modulated HOT 3
- CMake errors HOT 4
- moogladder tanh incorrect HOT 2
- ReverbSC does not initialize at 96kHz HOT 2
- SetFreq on VariableShapeOscillator seems to not work HOT 2
- Envelope timings incorrect HOT 1
- typo in fastroot() ? HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from daisysp.