search

Allen-Synthesis / EuroPi

EuroPi: A reprogrammable Eurorack module based on the Raspberry Pi Pico
Creative Commons Zero v1.0 Universal
431 stars 84 forks source link

Use I²C Config Values to Initialise CustomFontDisplay #342

Closed roryjamesallen closed 8 months ago

roryjamesallen commented 8 months ago

Relies on #340

Use configured I²C values to initialise CustomFontDisplay instead of just 0 and 1

This might be the point where it becomes worth having the discussion about elevating custom font functionality out of experimental, as larger displays are a nice opportunity for certain scripts e.g. Pams to use larger fonts for parameters when they're in edit mode. I think that the functionality can be included with very little overhead, but the fonts themselves should be picked more carefully as they're quite big (10kb - 22kb), so maybe normal vs big font would be a nice middle ground rather than a wide range of fonts

mjaskula commented 8 months ago

This might be the point where it becomes worth having the discussion about elevating custom font functionality out of experimental, as larger displays are a nice opportunity for certain scripts e.g. Pams to use larger fonts

I agree. We should start to gather up a list of software tasks related to the X that people can pick up and run with. GitHub issues, with an appropriate tag, seems like the logical place, but there are other choices if that doesn't seem appropriate.

roryjamesallen commented 8 months ago

GitHub issues, with an appropriate tag, seems like the logical place, but there are other choices if that doesn't seem appropriate.

GitHub Issues is perfect I think, especially how easy it is to link them to PRs and back to keep track of changes. I'm going to make an issue that's specifically about elevation of functions out of experimental as I think for firmware changes (like custom font capability) having a proper route to getting this into europi.py is a good thing.

Having read back through #275 I do think that some form of user contributed extra library would be good for anything other than real firmware stuff, the things that can be used across scripts. This could be part of the elevation process, where users just add to experimental with features that might fall into either, and a more thorough review/waiting game for another script to use it happens before a decision is made about where to elevate it to/whether to leave it in experimental.

I think the name "experimental" does imply this kind of functionality, where robust and specific enough code will eventually be granted a higher status and no longer be considered experimental, and I think that's a good thing