#45

What do people think the approrate colour schemes are for devices with RGB right @ground_state has them in rainbow in his pro profile which is nice as it makes every brightness level very distinct but it also lacks some a the refinement of the nice warm hues of a normal girds. Maybe a more restrained set of colours would be a good balance between both. Does anyone know of any good tool for generating hex values for rgb leds? currently i’m just making a colour in photoshop dividing it by 64 and converting it hex but it’s a tad laborious to try out a range of diffrent colors across 16 brigness levels.

#46

I’ve put through a PR with double buffering for the lp and lp mini. Lp mini gets its own config, but it’s not ideal.

Also, I have a pretty good idea how to implement fast led update in a readable way but not sure when I’ll get time…

#47

BTW just noticed the bottom two rows don’t work on 2pages. No messages in matron logs.

#48

@JaggedNZ

awake is… problematic

Consider this; loom does A LOT. I have it running on the LP Pro in 128 mode, and it’s buttery smooth, no matter what I throw at it. awake, otoh, on the LP Pro in 64 mode just running from startup, that is, not changing anything at all, flickers like mad…

I’ve read through it several times, but I just don’t see any “smoking gun” which would make it update so slowly.

#49

and man was it a pain

agreed. My very first cut at it was all grey, but I could only ever get about 9 distinct brightnesses[1], thus the (very hacked-up) Less-Angry Rainbow

…and the LP Pro LEDs use 6-bit color… so I hacked up a Jupyter notebook using the colormath Python lib to do 6-bit RGB -> full-range RGB -> LAB -> adjust brightness -> back again. Painful… I used this for LAB preview, but having to paste L, A, B separately sux.

I highly recommend sticking with 9_grid.lua (from the “tutorial” repo) or loom for testing; as I mentioned above, awake is kind of weird in how it handles the grid. Also, loom makes use of quite a few brightnesses.

[1] Someone with more time/patience than I might be able to tweak the values to get 16 brightnesses which are close to “grayscale”; I stopped after iterating over simple grey triplet (r=g=b) palettes a few times. After that, I tried orange, which curiously didn’t work. Not sure what I did wrong there…

#50

That’s quite interesting. I haven’t gotten loom to work yet and figured awake was a simple place to check everything.

The original lp and lp mini have some severe hardware limitations updating many less at once and midi grid updates everything at each refresh. The lp developers added a double buffer and a fast update mode to help mitigate this problem.

Norns: ideas
#51

Right, I remember seeing that in the LP tech doc. The Pro doesn’t do buffering, but I think it updates about an order of magnitude faster out of the box.

Have you tried the OG LP? Mine just acts weird, but I don’t know where the issues lies…

#52

Yeah i got basic greyscale going but the white is far too glaring. Tried to do a warm white but it came out more of a dirty yellow. Perhaps rainbow is the best solution given the limitations of the launchpad it’s a shame glut looks so pretty on a real grids :frowning: . Maybe somthing like Red, orange, yellow in 4 shades each is more doable will experiment

1 Like
#53

grid updates in loom are throttled by a timer, and i believe each LED is only hit once on each update cycle. awake doesn’t do anything like that and just triggers redraw when things change. and within the redraw cycle some led states are hit at least twice.

in the monome grid driver on norns, there is a LED state buffer that is only written out on refresh, so device:led() is cheap (doesn’t incur IO cost.) (its not quite “double buffered” but i guess in loom you could make it that just by moving refresh to the top of redraw from the bottom?)

i haven’t examined the MIDI shim. if it isn’t buffered and device:led() causes IO immediately, then:

severe hardware limitations updating many less at once

…would cause issues with awake, which i guess some additional buffering would help.

1 Like
#54

@beepboop, I have 3 PRs up; one to fix some local/global stuff, one for handling the “no device” case, and one to implement “4 page”/“4 quad”/“256” mode.

@JaggedNZ, @license, @Tim052 - If beepboop merges PR #7… it would be nice to get note values to enable the lower quads added to the configs for devices which I don’t own - the vars are in there, just commented out.

@thopa, @shreeswifty, @zproc - If y’all wouldn’t mind reviewing/testing…

#55

I’ve added the correct codes as suggested changes on PR#7, otherwise untested.

On the renaming to mg_128.lua I think this is a step in the right direction.

For any other launchpad / lp mini users, I keep thinking the top row (control row) should be used to swap pages and the right column used for other “special” features, for which I have some ideas… what do you think?

#56

Def.

On the LP Pro, I assigned ▲ ▼ :arrow_backward: :arrow_forward: to quads 1, 2, 3, & 4 respectively (that’s the first 4 “labeled” buttons in the top row.)

#57

@beepboop, @JaggedNZ, @license, @Tim052; I have a new PR up (#10; refactoring) in which I have a technical question about Lua which I’m completely unable able to answer for myself - if y’all could PTAL…

#58

i left a little comment, in a nutshell i think the colon syntax is causing unneeded complications (but i could be totally misunderstanding something about how the lib is used.)

#59

Yes I was about to comment essentially the same thing as @zebra and followed up a little myself.

I think it should be as simple as changing the notation from colon to dot in those places, as you really just want to pass a certain handler and not the object/class itself.

I remember reading somewhere that the colon syntatic sugar has some kind of specific convention in norns, but that shouldnt be confused with what it really does (adding ‘self’ as a parameter, giving us something like an object with a class).

At first blush looking at a lot of the libraries in norns, youd think colon=“going out/performing action to with the parameters you give” and dot=“a function you can take and use, belonging to a specific library”. And normally, that kind of thinking goes pretty far… Our midigrid is just very much inbetween everything in a script so it gets confusing.

#60

AFAIK, the only time colon is used in norns, are when an explicit self argument would otherwise be required. it is always used in such situations.

the need for self corresponds to an object that can be multiply instantiated with different distinct and often mutable states. (Grid, Midi,Engine, Poll, Metro, &c.) these modules also have constructor or factory methods. we call them classes and we call colon functions methods or instance methods. the syntax choice shouldn’t be arbitrary or cosmetic (if there are cases of that we should clean em up!) the nomenclature is basically arbitrary but consistency is probably helpful. (i am gonna add a paragraph about this to the lua style guide?)

many/most lua modules in norns don’t have multiple instantiation, therefore dont have instance methods, therefore don’t use the colon.

1 Like
#61

I did only a few very quick tests some days ago with my Launchpad Mini (aka Mini MK2) and didn’t notice any issue but for now i’m waiting to have a case to protect my Norns Shield to use it/test more

#62

I started a wiki on the project to document issues with certain scripts and how to use the lib for scripts where the grids refrence is located in a weird location or requires some special implementation. Only layed out the bones so far will go and do all the scripts over the coming week.

2 Likes
#63

@Tim052 i just been checking your work on the github and the wiki, congrats!

1 Like
#64

getting these errors when using mg_128 :thinking:

stack traceback:
/home/we/dust/code/midigrid/lib/mg_128.lua:235: in method 'all’
/home/we/dust/code/awake/awake.lua:353: in global ‘gridredraw’
/home/we/dust/code/awake/awake.lua:207: in field ‘on_step’
/home/we/norns/lua/lib/beatclock.lua:79: in function ‘beatclock.advance_step’
/home/we/norns/lua/lib/beatclock.lua:86: in function ‘beatclock.tick’
/home/we/norns/lua/lib/beatclock.lua:28: in field ‘event’
/home/we/norns/lua/core/metro.lua:169: in function </home/we/norns/lua/core/metro.lua:166>
lua:
/home/we/dust/code/midigrid/lib/mg_128.lua:265: attempt to call a nil value (method ‘led_sysex’)
stack traceback:
/home/we/dust/code/midigrid/lib/mg_128.lua:265: in method 'led’
/home/we/dust/code/awake/awake.lua:356: in global ‘gridredraw’
/home/we/dust/code/awake/awake.lua:207: in field ‘on_step’
/home/we/norns/lua/lib/beatclock.lua:79: in function ‘beatclock.advance_step’
/home/we/norns/lua/lib/beatclock.lua:86: in function ‘beatclock.tick’
/home/we/norns/lua/lib/beatclock.lua:28: in field ‘event’
/home/we/norns/lua/core/metro.lua:169: in function </home/we/norns/lua/core/metro.lua:166>

no errors when using the midigrid 64 version?
with launchpad mini