New fork, not sure if I should open a PR

[sbergen]

I just forked the repo and applied a couple of fixes, improvements and reverted some things back to how it was in Clouds:

• A small optimization in the input conversion code (you had left a TODO comment there already)
• Long pressing input mute disables the reverb on the dry signal (original clouds behaviour)
• Output mute doesn't mute the input, so you still get input into your buffers while the output is muted (I'm not sure if muting the input was intentional, or just a workaround, as this wasn't trivial to implement)
• Reverted back to the original grain counts used in Clouds: Parasites had made the grain count smaller due to memory running out, which I don't think is a problem in the better hardware.
• Reverted some changes to the density control, so that it behaves like in Clouds

I also cleaned up some commented out code, renamed some variables to their original names to make diffing against Emilie's version easier, and updated here name and contact.

I didn't put these into separate branches or anything, as I didn't think that far ahead :)

However, if you are interested in incorporating some of these changes, I'd be glad to do some rebasing to make cleaner PRs.

Also, if you have any thoughts on the memory limitations vs grain counts, it might be cool to try using even more grains? I'm not at all familiar with embedded development (but have a strong DSP background) so I'm not sure how to profile this.

The fork is here: https://github.com/sbergen/superparasites

[patrickdowling]

Wow, thanks! Some of those things do sound interesting, although I'd have to admit I'm not a superuser so I don't have very strong opinions (I left most of the UI/usability choices to @grayscalemodular). I'll take a look as time allows.

Haha, yeah, I still have the bad habit of doing a bunch of changes at once and then having to sort them into reviewable commits later...

The grains seem to be in a fixed-size buffer (kMaxNumGrains) so in theory the linker should complain eventually that the section has overflowed; IIRC there's also a make ramsize. There's not a huge amount of processing time left though, but I can see if I have numbers from last time I measured the timing (it requires a scope attached to a debug pin) -- I believe the worst offender was Resonestor at around 85%.