TheSlowGrowth

> And the use of these methods throughout codebases that use Daisy. No, please not. This sort of "pseudo-intelligent" memory allocation is not a good idea. Users need to understand...

> there is no memory allocation after the audio starts As I said, then you probably don't actually need dynamic allocation in the first place. I quickly looked at some...

I understand what you are trying to achieve (at least I think). But I don't think it will work the way you expect it to. If you have a malloc...

> gen~ data isn't all stored in a large struct. The majority of parameter variables, filter state variables, latched variables, etc. are local to the struct, as they are likely...

> have a dsy_malloc which is initially #defined to malloc, but can be replaced. I would prefer weak linkage, but yes, that could be a solution.

I have today tried to get C++ code generated from the SOUL language to run on the Daisy - and compare it to handwritten C++. Fun fact: I can't reproduce...

okay, that github action is clearly not maintained anymore. I'll search for a replacement we can use. In the worst case, we could also choose to not verify the formatting...

Okay, I removed the github action for now. There doesn't seem to be a readily available action that works :-(

Answering some questions from @recursinging in #326 : > Alternatively, I was wondering if it might be possible to have template peripheral handle classes which allocate their own transmit and...

Hmm, I had something like this initially but I thought i had fixed it... I use my led drivers for "peak-meter"-style led indicators and never noticed something weird with them....