UI to display ram usage

[maks]

It would be helpful to show the user how much flash space is left (for importing samples) into a project (the Polyend tracker for one has exactly this UI for its limited sample memory per project). But showing ram usage is likely useful for both dev debug purposes and I guess even end users as this is a limiting factor for project size.

[democloid]

Displaying flash available should be pretty easy, as there is a variable that points to the current flash location and another one to the end.

Displaying RAM is probably not very useful outside of debugging operations, and that can be achieved with debug logs. Ideally there shouldn't be any dynamic allocations on embedded devices due to the limited memory (or all the heap allocations should happen in the beginning, which is what mostly happen upon loading a project). This wasn't built with that in mind so there are a ton, but in normal operations they are limited to UI elements being created and destroyed for the most part. IIRC all buffers are statically allocated. Bigger data structures like the song structures, instrument loading, etc. are still dynamic but all loaded upon project load and don't change thereafter.

[maks]

While thinking about reinstating CPU usage in #131 I realised that just as it is useful to show CPU usage to a user during playback, it would be useful to show the user RAM usage during editing and it would fit nicely in the same spot in the UI.

This way just as a user can use the CPU to make decisions on what to use or remove in their project, they could base decisions on what to enable or not during editing based on Ram availablity. I guess though this is a debatable topic though so would be keen to get your thoughts on this @democloid given current work on moving to more static mem allocation.

I think displaying flash usage is a different topic and has consensus already so will move that to a separate issue and update title here appropriately.

[democloid]

While thinking about reinstating CPU usage in #131 I realised that just as it is useful to show CPU usage to a user during playback, it would be useful to show the user RAM usage during editing and it would fit nicely in the same spot in the UI.

This way just as a user can use the CPU to make decisions on what to use or remove in their project, they could base decisions on what to enable or not during editing based on Ram availablity. I guess though this is a debatable topic though so would be keen to get your thoughts on this @democloid given current work on moving to more static mem allocation.

I think displaying flash usage is a different topic and has consensus already so will move that to a separate issue and update title here appropriately.

I'm honestly fundamentally against displaying CPU and RAM usage. Don't think the user should care about these things. If the device cannot play the total number of streams at the same time then we shouldn't allow to do so. The device needs to be predictable and work well for all possible user input. In fact, I more or less know that 6 tracks is the current maximum simultaneous instruments that can play reliably, Ieft it at 8 due to potential optimizations, but if that doesn't happen, I think it should be limited to 6 eventually.

[maks]

Ok I think we've got very different views on this so I'll try to argue my case here. While I think it's possible to provide that kind of predictable behaviour for simple instruments like say a 303, I don't think it possible for full featured devices like the picotracker without drastically limiting what users are able to do.

As a case in point with the number of channels, while 4 or 6 might be the limit with only sample instruments there's no problem using all 8 with midi or even a combination of samples and midi. Then there's use of commands and tables which can easily make a big difference on how many simultaneous tracks the rp2040 can handle. Things get even more complex with synths as for example 3-4 full 6op DX7 voices will be the same computationally as using upto 8 2-4op instruments.

Looking at prior art, afaik pretty much all existing grooveboxes allow the user to choose settings that will overload the system and then leave it up to the user to choose tradeoffs to not hit the limits of the device. For example the Electribe2 which I previously had is infamous in its user community of its voice stealing because of the 24 voice limit it has which is actually not just about voices but the DSPs capabilities as it also includes use of FX like reverb.

Given the above what erks me about for example the E2 is not the limitation exists but the complete lack of observability of it to the user! There's no way to know that you are reaching the limits until you hear it. This is where I think devices like the higher end MPCs (& machine+ & korg workstations?) are better in having CPU usage gauges just like general purpose OS's, to show the user how much capacity they have left.

So I'd sum up to say that I think CPU usage, while dynamic, is otherwise just a constrained resource exactly like Flash storage or battery charge, where it's not controversial that you would want to show the user how much of the resource is left to use. I'd of course argue the same for Ram usage but I'd say CPU usage is much more important.