Missing Source Files in DaisyExamples

I have a fresh install of the Daisy Toolchain and the Daisy Examples repo. Several Pod examples are missing dependencies, for example the Tone and Reverbsc classes can’t be found. I have an old clone on another machine that doesn’t have an issue with these.

Another example is that VSCode flags "#include “daisy_seed.h” saying:

“cannot open source file “ff.h” (dependency of “daisy_seed.h”)”

Looks like this dependency is a few levels down. Anyone know where these missing dependencies went?

A fresh download should have :
in the Makefile for examples which use the LGPL DSP code.

I just cloned DaisyExamples with —recurse-submodules, rebuilt libs with ./ci/build_libs.sh, then checked Pod/MultiEffect/Makefile. The LGPL line is there, and MultiEffect builds without error. I then commented out that line in Makefile, and tried to build; result was errors finding Tone and ReverbSc.

vscode is nice when it works, but it’s broken on my system again. Just too much bother for me.

Odd, my MultiEffect Makefile does have this line, and I took the same steps to clone. I also tried to run build_libs.sh from the ci folder, but it wants to open libDaisy from the same folder instead of DaisyExamples. I assume “task build_libDaisy” does the same thing though, and running that task actually fixed some other issues for me, but not this one.

What do you use instead of VScode?

Thanks for your help and patience!

I just use vi from the command line, though I’ll admit, a friendly debugger can be handy.

I’ve just noticed that some of these have been moved around. I’ve pulled the latest Daisy examples version, pulled the latest version of Libdaisy and DaisySP into that folder, then pulled the latest version of DaisySP-LGPL into the DaisSP folder.

When I run ./rebuild_all.sh from the root of DaisyExamples, I get this:

building libDaisy . . .
arm-none-eabi-ar: creating build/libdaisy.a
building DaisySP . . .
Building DaisySP-LGPL
/usr/bin/env: ‘python’: Permission denied

The Permission denied is common and has never caused problems before.
So then I enter seed/DSP/reverbsc and run make; make clean; make program-dfu; and I get this error:

.../daisysp/Source/daisysp.h:94:10: fatal error: daisysp-lgpl.h: No such file or directory
   94 | #include "daisysp-lgpl.h"

What is happening here? USE_DAISYSP_LGPL=1 is present in the DaisySP Makefile?

I never fully resolved this, but I think messing with the LGPL #ifdef statement in daisysp.h helped. Not sure if I just removed the ifs or changed it to #ifndef.

Am I overreacting or is the Daisy platform fundamentally broken while this is an issue? I’ve been playing with daisy for a couple of years, and while I only have rudimentary knowledge of C++, I am a professional software engineer. To anyone coming to this new and following the instructions, many of the examples aren’t going to work out of the box, and that doesn’t look good. And anything I’ve built that uses reverb or portamento now doesn’t work.

I think you’re overreacting, but I can see how this might cause trouble for those who cannot or will not figure out what is happening.

That’s not helpful. We’re not talking about edge cases here, we’re talking about getting things fundamentally working out of the box.

I would assume this project is meant to be used with specific versions, the moment you start messing around with its dependencies you should not expect any functional result.

The “Permission denied” should not be common, it means the ci/build_examples.py doesn’t run at all and that the python setup on your system is potentially broken.

I just tried the plain instructions from the repo and it’s building all of the example projects without issue for me.

1 Like

I just pulled the latest DaisySP and libDaisy versions (inc submodules). rebuilt libDaisy. then went into seed/DSP/reversc/ and typed make.

No problem.

1 Like

What system are you on? I’m having the same LGPL problems on Windows 11, but I know it’s all working on my Mac, although I pulled that a long time ago.

Did you pull the submodules recursively?

I think the command in the readme should be git submodule update --init --recursive.
It currently is missing the last flag, which might be why you do not have the LGPL code.

I do have the LGPL code, but the USE_DAISYSP_LGPL flag in the makefiles doesn’t seem to be working. If I go into daisysp.h and remove “#ifdef USE_DAISYSP_LGPL” and the #endif, then it works.

I’m getting even more confused. Now, I can build examples that have LGPL modules like Tone and ReverbSc, but I get the same “no such file” error pauldee is getting when I try to build examples like Chorus that don’t use LGPL. But if I put the #ifdef back, they will build again. What gives?

These issues coupled with the noise thing and phaser thing I posted are kind of dissuading me from using Daisy…

As far as I can tell, the python script just goes through every example and runs make clean and make?

But to eliminate all problems, I uninstalled all versions of Python and reinstalled it, ensuring it was installed for all users so I don’t have the permissions problem.

I then ran these commands:

git clone --recursive https://github.com/electro-smith/DaisyExamples
cd DaisyExamples

This time, the ./ci/build_examples.py script ran, recursing through the directories and building everything. It successfully went through the patch, patch_sm, petal and pod directories building everything fine. It went into the seed directory where it build Blink, Button, bypass and Drum all fine. It then went into the DSP directory where it built adenv and adsr fine. Then it tried to build allpass, where it failed with the same error:

.../daisysp/Source/daisysp.h:94:10: fatal error: daisysp-lgpl.h: No such file or directory
   94 | #include "daisysp-lgpl.h"

Right, I’ve got to the bottom of this now. Sorry, it’s my bad. I had anonymised the path of the file that was failing:


…to hide file paths because I’m paranoid. Unfortunately this hid the fact that it was looking at the wrong location for the file. I had added environment variables for LIBDAISY_DIR and DAISYSP_DIR so I could build Daisy project anywhere. Unfortunately, these overrided the values in the makefile, and so was looking at my old versions of Libdaisy and DaisySP. Most of the projects built OK but when it came to something that was relying on DaisySP-LGPL it failed.

I apologise again. Thank you @dreamer and @tele_player for your help. Unfortunately @masd I don’t think this is the same problem you were having?

1 Like

Even us professionals make mistakes sometimes :wink:

1 Like