Tip: Look at how existing patches manage grid led messages when adjusting a patch to work with monobright grids.
For the most part, led messages for brightness levels ~1-14 represent information that you want to see on the monobright grid. led messages for brightness level 15 generally is used to represent the “active step” in sequencers or other important elements in the UI. So if you reverse these (swap 0-14 for 15 and 0-14 for 15 in g:led messages), you put more information on the grid at the expense of “active step” information. Because the “active step” is generally always moving, setting it to anything but 15 will render a blink on the monobright grid, which is probably just enough to see what’s going on.
Obviously this breaks down for patches that use the x y 15 brightness level for information that is static on the grid or for patches that use a number of different levels of brightness to represent information in the UI. Also every patch is different so this won’t apply universally, but is probably a good place to start when thinking about how to modify a patch for monobright grids.
Just throwing this idea out there… what do people think of the idea of creating and maintaining a 64-remixes repository with these scripts? (That is, for those scripts that are remixes, and not those that “just work” with all grid sizes.)
It would be nice to be able to get updates to these, as well as have an easy way to pull them all in via Maiden.
Would be happy to do the work of creating and updating the repo myself, now that I have a 64.
Edit: also on this front, I think querying the grid rows/cols could allow an is_64 flag to be defined, and scripts could be modified to support both instead of remixing? Not sure if all script owners would want the burden of needing to test “legacy” hardware in addition though, so perhaps remixes are the way to go.
Interesting I was hesitant to suggest something similiar in case it added noise in maiden, or if duplicating libs in different folders was a no no, or even if it added overhead for the original script creators in case people started reporting bugs in the main script threads. For example, the less concepts edit above is not up to date - I need to update to match latest version by @dan_derks.
Yeah, that’s a good point about adding noise to the original script threads… I think it would need to be clear in the package name, either via remix or unofficial, that these are labor-of-love maintained forks that may be a bit buggier/not up-to-date.
As for noise in Maiden and duplicating scripts, FWIW there are a number of <x> and <x>-passersby etc. type scripts that swap sound engines for the given sequencer, so I think remixing and publishing is not a fully out-there idea.
One worry too is that these scripts would get updated by their author and may or may not make it back to the community megapackage… so maybe a <x>-64 fork works better.
tried your modification on a mono bright 64 and I cannot really use it.
I only receive feedback when I hit a button.
Is it my grid or some bug? no idea.
I tried to look at the code but I have no experience with it, It seems it is not full monobright.
As said, my comments to take with a pinch of salt.
It would be amazing if it would be possible to use mlr with the monobright/