Plugdata - new PD environment that can flash straight to Daisy

Yesterday we released plugdata v0.6.3 which has integration with heavy/hvcc → Release v0.6.3 · plugdata-team/plugdata · GitHub

Plugdata is a new interface and user experience for pure data, that can also run as a plugin.

It includes a Compiled mode that will warn you when you use incompatible objects. After which you can retrieve the compiler toolchain for your platform (about 1.5GB) and then either export just C++ code, flash a Daisy device or output plugins created with DPF.

We have included the typical target boards and also one for Simple (which simply has all the analog control pins mapped). You can also select a custom board.json for your specific hardware setup.
You can then either output the Daisy source code, create a binary or flash directly to your Daisy!

Just like pd2dsy it has some options for optimizing for RAM and ROM which may be required based on the size of your patch or if you use large memory buffers (for delays and such).

Would love to hear what people think about this integration and what you come up with for Daisy.


this is excellent! is the versio hardware support possible, via custom json or otherwise? I apologize for the newbie question. thanks!

Should be, yes! Although someone would have to write such a custom json first.
Possibly not all peripherals will work and it’s dependent on libDaisy.

1 Like

excellent, many thanks, i’ll look into it!

1 Like

I’m finding plugdata to be really fun.

1 Like

Are you using it to build Daisy code?

I just installed plug data on my Mac, haven’t installed tool chain yet.

I still miss Axoloti. PureData is just so weird, though it’s more correct to say I prefer Axoloti’s level of abstraction.

I don’t understand your question.

Btw I also have several Axoloti and it’s great, but the Axoloti environment is not a full programming language like PD.

I was wondering if Joshua is using plugdata to build and flash onto a Daisy.

I just installed the plugdata toolchain, and haven’t had success producing code to run on the daisy patch.init(). Investigating now.

It’s working for me with a custom JSON, this is an awesome tool! Thank you for sharing this!

Does anybody have it working with Daisy, running on Mac OS 10.14.6 Mojave ?
I can get it to export the code, and I can build and upload, but no sound (patch.init())

Does it only load using DFU, or can it use Stlink?

If it can build and upload, then it should work. Probably something with your pd patch that is not correct?

It uses DFU internally only, so you can’t make it use Stlink for flashing.

And we have v0.6.4 update with a bunch of bugfixes already: Release v0.6.4 · plugdata-team/plugdata · GitHub

Installed v0.6.4 on Mac OS 10.14.6 Mojave
Simple patch which outputs random notes, works fine in plugdata.
I can’t easily use DFU, as my patch_init is in a case, and USB is inaccessible, STLINK cable is accessible.
So, I export as source, which produces directories daisy and libDaisy.
cd LibDaisy
cd …/daisy/source

This produces a bin file HeavyDaisy_foo.bin, as expected.

Then I upload with stlink:
make program

Which looks successful, but no sound.

I think I’ll wait until others get this to work.

1 Like

Hmm, are you able to share your patch or share a version that reproduces this behavior?

I’ve also had some instances where I needed to set up my patch in a specific way otherwise I would hear no audio at all.
(even when it would work with the DPF exporter as a VST, but not on Daisy somehow)

Here’s the patch - it’s from a Pd tutorial somewhere on the net. I also tried it after replacing the toggle at the top with a constant ‘1’.

#N canvas 483 175 656 482 12;
#X obj 117 78 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 1 1
#X obj 117 128 t b b;
#X obj 117 155 random 20;
#X floatatom 117 213 5 0 0 0 - - -, f 5;
#X obj 117 240 + 0;
#X obj 218 167 random;
#X obj 218 193 / 100;
#X obj 261 134 line;
#X floatatom 117 270 5 0 0 0 - - -, f 5;
#X obj 117 293 mtof;
#X obj 117 325 osc~;
#X obj 117 354 *~ 0.7;
#X obj 116 390 dac~;
#X msg 261 107 0 \, 100 30000;
#X text 26 16 random offset;
#X text 113 52 start here first;
#X text 259 80 then initiate detuning here;
#X text 365 385;
#X text 376 364 Johannes Kreidler;
#X obj 117 101 metro 300;
#X obj 117 182 + 40;
#X connect 0 0 19 0;
#X connect 1 0 2 0;
#X connect 1 1 5 0;
#X connect 2 0 20 0;
#X connect 3 0 4 0;
#X connect 4 0 8 0;
#X connect 5 0 6 0;
#X connect 6 0 4 1;
#X connect 7 0 5 1;
#X connect 8 0 9 0;
#X connect 9 0 10 0;
#X connect 10 0 11 0;
#X connect 11 0 12 0;
#X connect 11 0 12 1;
#X connect 13 0 7 0;
#X connect 19 0 1 0;
#X connect 20 0 3 0;

You’ll need to apply a loadbang to the toggle, otherwise the metro object will never start.

I finally got a simpler patch to make sound. Haven’t figured out how to fire the metro.


  • the ‘make’ program embedded in Mac toolchain won’t work with 10.14.6 Mac OS.
  • it would be super useful if stlink is supported, it’s much more convenient than DFU, especially in a case.

DUH! there is a ‘loadbang’ object (of course). Random booping coming from my Daisy!
@dreamer - thanks for the help!


Can you explain what happens? Maybe copy/paste the console output with the error?

For flashing via stlink support it’s best to open a feature request ticket so that this can be tracked.
At the moment this would have very low priority as we are focusing on other things.

It’s a missing symbol in a system library dynamically loaded by make. Testing this ‘make’ on its own, it appears this problem only occurs when make is called with the ‘-j’ option to run parallel jobs.

My workaround is to replace it with a dynamic link to /usr/bin/make, though I can’t be certain where this make actually came from.

This is a 2015 MacBook Pro, with OS and Xcode upgrades over the years.
Sure, it would be simple (though costly) to get a new(er) MacBook - but this one still serves my needs beautifully.

--> Generating Daisy module
Total compile time: 376.25ms
Compiling.../Users/robert/Library/plugdata/Toolchain/bin/arm-none-eabi-gcc -c -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=hard -DUSE_HAL_DRIVER -DSTM32H750xx -DHSE_VALUE=16000000  -DCORE_CM7 -DSTM32H750IB -DARM_MATH_CM7 -DUSE_FULL_LL_DRIVER -include stm32h7xx.h -I../../libDaisy -I../../libDaisy/src/ -I../../libDaisy/src/sys -I../../libDaisy/src/usbd -I../../libDaisy/src/usbh -I../../libDaisy/Drivers/CMSIS/Include/ -I../../libDaisy/Drivers/CMSIS/DSP/Include -I../../libDaisy/Drivers/CMSIS/Device/ST/STM32H7xx/Include -I../../libDaisy/Drivers/STM32H7xx_HAL_Driver/Inc/ -I../../libDaisy/Middlewares/ST/STM32_USB_Device_Library/Core/Inc -I../../libDaisy/Middlewares/ST/STM32_USB_Host_Library/Core/Inc -I../../libDaisy/Middlewares/ST/STM32_USB_Host_Library/Class/MSC/Inc -I../../libDaisy/core/ -I../../libDaisy/Middlewares/Third_Party/FatFs/src -O2 -Wall -Wno-missing-attributes -fasm -fdata-sections -ffunction-sections -Wno-stringop-overflow -g -ggdb -MMD -MP -MF"build/startup_stm32h750xx.d" -std=gnu11 -Wa,-a,-ad,-alms=build/startup_stm32h750xx.lst ../../libDaisy/core/startup_stm32h750xx.c -o build/startup_stm32h750xx.o
dyld: lazy symbol binding failed: Symbol not found: ___darwin_check_fd_set_overflow
  Referenced from: /Users/robert/Library/plugdata/Toolchain/bin/make (which was built for Mac OS X 12.0)
  Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: ___darwin_check_fd_set_overflow
  Referenced from: /Users/robert/Library/plugdata/Toolchain/bin/make (which was built for Mac OS X 12.0)
  Expected in: /usr/lib/libSystem.B.dylib

/Users/robert/Library/Caches/plugdata/ line 2: 13862 Abort trap: 6           /Users/robert/Library/plugdata/Toolchain/bin/make -j4 -f /Users/robert/Documents/plugdata/junk/daisy/source/Makefile GCC_PATH=/Users/robert/Library/plugdata/Toolchain/bin PROJECT_NAME=RF_tone

Thnx, we had another user in the Discord today with the same issue. Basically the toolchain binaries are not compatible with this version of MacOS. We’ll try to look for a solution, but no guarantees :wink: