Not surprised! It’s a big ChibiOS update so there definitely will be more tweaking necessary. I am also noticing lots of skipped MIDI messages.
Is this midi host messages, so from the host port?
The priority was ramped right down because it was messing with other threads, fix one thing mess another thing up sort of thing?
With the launchpad this was usb host related, yes.
Thanks.
The USB Host stuff needs a bit of a look at, the code was never good as far as I can see and ran at a high priority level which with the new Chibios version was causing issues, so its priority was lowered to stop it stepping on everything else.
This has obviously caused some problems, I will have a look at the code and see if I can get it to play nicely, it might need a bit of a rewrite…
1 Like
New package upload 2025-01-07 - Fixed issues compared to the previous beta package (ca. 2024-12-23):
- Fixed USB host MIDI stability (?)
- USB Audio active/inactive indicator in info panel of the main window was not being updated
- I2C was very laggy (Gills/Big Genes display)
- Firmware could not be updated via the yes/no popup window (?)
- Fixed lasting 3khz beeeeep in usbaudio/in objects after exiting audio host (?)
- Fixed Mac permissions which were disallowing “rescue mode” upload (?)
Remaining known issues:
- SD card may be inaccessible to patch objects
- Occasional disconnects and garbled log messages?
- When going back to 1.0.12, make sure you flash the non-USBAudio firmware using 1.1.0 first, otherwise the 1.0.12 Patcher will not recognize the device. But then you can always do a rescue mode flash on 1.0.12.
Hey I just wanted to give this a try but my main patch is not compiling:
Generating code…
Done generating code.
Creating directory on SD card… /A Main Patch Lp 4_2_6
Done creating directory.
Changing working directory on SD card… /A Main Patch Lp 4_2_6
Done changing working directory.
Compiling patch… A Main Patch Lp 4_2_6.axp
Makefile.patch.mk:121: 2.app/Contents/Resources/chibios/os/various/fatfs_bindings/fatfs.mk: No such file or directory
make: *** No rule to make target ‘2.app/Contents/Resources/chibios/os/various/fatfs_bindings/fatfs.mk’. Stop.
Shell task failed, exit value: 2
Patch compilation failed: /Users/simon/Dropbox/Axolonatics/Simons Patches/Ksoloti Launchpad/A Main Patch Lp 4_2_6.axp
Thanks for checking! “fatfs.mk: No such file or directory” looks familiar, happened to me before too.
A friendly co-contributor spotted this: 2.app/
Did you happen to rename the app to like “Ksoloti{something}2.app”?
If yes it’s a good wake-up call to add some protection against such filenames. Axoloti used to have a similar problem where spaces in the file path would break things.
Ah that must be it. Finder automatically renamed it after unzipping, because there must have been the old version in the downloads folder.
Now it compiled. My launchpad seems to be working, great!
Also really love this:
It seems I have a lot of untapped ram potential here.
EDIT:
Just tried the freeze function on one parameter, and now I use up MORE ram:
Interesting! I can confirm here.
SRAM1 seems to go up when certain parameters are frozen, but generally CCM and SRAM1 tend to decrease the more knobs are frozen.
I tested with cpwitz/generative/automobeep.axp, a community library demo patch. The patch has the (Axoloti-default) 8 presets and 32 modulation sources set up in the Patch settings.
If I set these to 0, the RAM does not seem to increase randomly?
Is your patch using presets and/or modulation sources?
Still something seems off in the code generation, thanks for reporting!
No I don’t use any presets or modsources.
Can’t find any hint as to why memory increases when certain parameters are frozen. For me it seems to happen only with certain ones (maybe the ones that control pitch, i.e. have this clickable pitch/note/Hz number display on them?)
In another patch, one frozen parameter reduces both CCM and SRAM1, then two reduce CCM but increase SRAM1 (compared to 0 frozen), and from then on the more you freeze, the more you save in both memory areas.
The generated code is tight and logical in all cases. It might just be the mysteries of compiler optimization.
New popup menu entry: “Freeze/unfreeze all parameters”.
Instead of right-clicking every single param, just pull the trigger for an all-out war on wasted memory!
I like testing on cpwitz’s patch automobeep.axp, because there is just so much going on: sequencing, samples, synths, reverb … and there is quite some room for optimization.
2 Likes
Oh I love this attitude! If you’re patching witha midi controllers or some control interface you usually need the parameters only for finetuning in the patcher anyways.
1 Like
Finally found the issue. Frozen variables were declared as static const which for some low-level reason would occupy both flash and RAM memory? Or something in that direction. Now declaring frozen variables as const only, which will free up both CCMSRAM and SRAM1.
2 Likes