Difficulties using pure data + daisy patch + midi

Hello! I recently got my Daisy Patch and have been experimenting with creating patches that use MIDI control. But every patch I make stops working after a few minutes, either just going silent or with a stuck tone.

I’ve created a fairly simple patch that exhibits the problem. If I flash it and send a midi sequence to it, it eventually fails, even if I touch nothing. I looked at the known limitations, but maybe I am missing something obvious. Any suggestions?


You’ll probably do better installing and using plugdata, which is actually being maintained and updated.

Plugdata is a friendly environment for Pd development, and directly supports build/upload to Daisy.

Look at the screenshot: this is plugdata :slight_smile:

@perkowitz can you give some more details on how you are flashing? Which flash option etc.?

I’ve now flashed this patch onto my Field using the big option and it’s running happily for a while already.
What kind of midi sequence are you sending?

The message buffer size is hardcoded at the start and it could be that it overflows and then crashes the device. A future idea is to be able to manually override/increase this size, but this will need modifications on how the heavy context is created in the libDaisy wrapper.

I’ve created this ticket to keep track of progress around the topic: Feature: Daisy - configuration for message buffer size · Issue #173 · Wasted-Audio/hvcc · GitHub

1 Like

The sequence is coming out of Ableton Live and is just a sequence of 8 notes looped. no overlapping notes or anything, no controllers. Is the message buffer size the limit on how big a single message can be? I don’t think I’m doing anything that would result in large messages. Or is it total number of messages sent? which seems like it would always eventually overflow if you use a patch long enough.

Here are my compile settings:


It is a queue and messages are taken out of the queue to process. But it could be that there are more messages coming in than the total queue size can handle.

The patch on my Field was running for about 10 minutes when it ended up crashing.
I will try to do some more experiments and look into how we can more properly set up the constructor to at least set the calculated message size (the compiler creates an estimate which typically is used to set up the initialization, but this was never done for the libDaisy integration).

What is the default queue size? I can’t imagine how in a simple case like this the queue would get back up so quickly, unless there is some kind of message that is never handled, but just sits on the queue forever. And that seems like a bug that expanding the queue size wouldn’t fix. But I suppose if we could get it to where it doesn’t crash for 10 minutes or so, I could occasionally hit reset and be fine.

For a while it seemed like the patch was more likely to crash when I stopped the sequencer but I just tested with a lot of stops and starts and that doesn’t seem to be an issue.

Are you certain ableton isn’t spewing out clock messages of some kind?

The defaults are: Heavy_{{name}}(double sampleRate, int poolKb=10, int inQueueKb=2, int outQueueKb=0);
And looking at the export this patch should work: Heavy_{{name}}(double sampleRate, int poolKb=10, int inQueueKb=2, int outQueueKb=0);

The outputQueue isn’t set, but I wonder why it would even be needed …

Still, these values are guestimates, and it could very well be that midi messages fill up the message queue faster than other messages. Hard to tell without anyone taking a deep dive into internals and debugging.

I also had it crashing after ~10 minutes or so. Although after a couple minutes I switched to sending “legato” notes (so a whole bunch of notes at once. not real legato using pitch bends), which would increase the event count a bit.
No clock though.

Good point. I was sending clock messages, but I turned them off and it still hangs after a minute or so.

So any suggestions for ways to at least decrease the crashing?

this is using Serial Midi, or USB midi? (It is not switched on?)
As the symptoms seem to be similar (crash after some time), while I don’t use Midi, but use Plugdata and Heavy and USB serial some suggestions, which seemed to help in my case:

  • Delete all objects, which might output something, that has no receiving object. (Like [r Cntrl1 hv_param] )
  • Give the Daisy time to startup. In my case USB serial needs time to establish. I have put some System::Delay(3000); into the startup code.

Just some ideas.

This is using the 1/8" MIDI port on the Patch. I didn’t realize USB MIDI was an option – I’ll have to explore that if I ever get this working properly.

I deleted all the extra [r] objects from my patch, but it still hangs after a minute or so.

What do I need to do to add the system delay? Do I have to modify the C++ code in the toolchain?

Hi, these are only ideas, as I am struggling with these things too…
Plugdata/Heavy uses a template file HeavyDaisy.cpp, which we can modify. It can be found in:
Here you could insert some waits before the loop in main. Also Your sending device should not send Midi Data before Daisy is ready.
I would also try to use the USB midi as you use the PC as sender.
Good luck, Christof

Just tried with USB and a 3-second delay before the main loop, and it still crashes after a little while. The first time it lasted a while before crashing, really got my hopes up!

USB MIDI was easy, just checked the box during compile and my Mac found it as a MIDI device as soon as it was flashed.

Is there a ticket to track the MIDI problem in general? Unfortunately, this makes the Daisy Patch unusable for my use case.

There is now: Bug: MIDI on Daisy unstable · Issue #175 · Wasted-Audio/hvcc · GitHub

1 Like

Thanks dreamer. I’m guessing this issue only occurs when using Pd? I haven’t started trying to write & build my own C++ for daisy yet, but if it’s a way forward I might try.