Norns: development

dansimco · 2019-12-04T00:00:28.291Z

That will be so good, I’ve been working on how to organize it all with various logical hacks. Largely I’ve been “this wont be edited in params, but the storage system is important”.

zebra · 2019-12-04T02:18:29.594Z

I’m planning to add a ‘data’ param type for storing tables in paramsets (no UI, just script glue)

tehn · 2019-12-04T02:25:23.413Z

ah I am also planning to add a string type with a text entry widget

dansimco · 2019-12-04T02:52:49.085Z

I was speculating elsewhere the possibility of a grid based keyboard in the style of a plank keyboard for text entry. Potentially with an inverted-t for arrow keys. Would it be of any use if I prototyped that?

desolationjones · 2019-12-04T03:05:17.942Z

zebra:

…storing tables in paramsets (no UI…)

Introducing Nornscrowsoft Excel™

And I, for one, would be very interested in learning to type on a Grid.

Justmat · 2019-12-04T15:14:07.522Z

@tehn, while the param menu is being looked at, I wonder if we can truncate long file names? Currently, loading a file with a long name looks like this…

20191204_1006314032×2268 2.16 MB

which is not so great looking

tehn · 2019-12-04T15:28:55.644Z

good call! i imagine it makes sense to keep the front side of the filename?

Justmat · 2019-12-04T15:31:02.455Z

That makes sense to me!

Dewb · 2019-12-04T15:33:07.611Z

Ellipsis in the middle is a common strategy (so longfilename1 and longfilename2 become long…1/long…2 rather than longfi/longfi.)

Justmat · 2019-12-04T17:20:26.746Z

Dewb:

Ellipsis in the middle is a common strategy

This is what I did in mangl. first few letters + ellipses + last few letters.

tehn · 2019-12-04T17:50:45.942Z

could you post your concat function?

Justmat · 2019-12-04T18:29:45.072Z

it’s just a few lines in mangls redraw function before drawing the filename on screen.

    local long_name = string.match(params:get(track .. "sample"), "[^/]*$")
    local short_name = string.match(long_name, "(.+)%..+$")
    local final_name = ''
    if string.len(short_name) >= 15 then
      final_name = string.sub(short_name, 1, 4) .. '...' .. string.sub(short_name, -4)
    else
      final_name = short_name
    end
    screen.text_right(final_name)

Dewb · 2019-12-04T18:49:53.958Z

Unfortunately, going by character count isn’t going to be accurate with the proportional font. It would be better if the pixel width of the string could be measured. Does Cairo have such a method?

tehn · 2019-12-04T18:58:01.925Z

yes it does. screen_extents which i should add to the script-level screen lib (currently used by text_center and text_right)

mimetaur · 2019-12-05T14:40:27.277Z

While we are on the subjects of params improvements @tehn, something that would be super helpful is a public API for removing params. Sometimes I have an option where when it is set one way, it builds params, and set another way, it gets rid of them.

Picturing something like params:remove(param_id)

But one question that came up - for saving presets it might work better to have show() and hide() for the menu system, and the underlying param is always there.

tehn · 2019-12-05T14:46:50.835Z

@ppqq actually did a branch with param deletion and it raised a bunch of messy design issues-- dynamic removal of params may be way too breaking. ie, you’d want also insertion of params at a particular index, which would break the current syntax.

i could see some meta-controls for the param menu, though. show/hide could make sense.

can you tell me more about your use case?

mimetaur · 2019-12-05T16:35:28.300Z

In this case: making a Norns version of the Korg SQ-1, where different top level modes then effect sequence level params. So my idea Is to hide those params except in the relevant modes.

I can also see it coming up when I’m choosing whether the track is assigned to CROW or MIDI and then there are params that apply only in one of those cases. It would be nice to not show the midi params if the track is in CROW mode.

Seems like hide/show would be the way to deal with this UI side vs deleting and (re)building params.

markeats · 2019-12-05T18:36:34.081Z

+1 for these kind of dynamically shown params, it’s something I’ve run into a few times also

tehn · 2019-12-05T20:55:19.944Z

keep in mind i just implemented GROUPs which basically give a subpage, so params can be even more sorted. ie CROW could be ignored in MIDI mode.

but i think some scriptability of the param menu could be nice.

also given @zebra mentioned a “data” type which would be un-editable from the param menu, that’s a perfect candidate for a “hidden” param. and more generally (i guess) i could see a case for having hidden params that are not meant to be user-edited directly?

ppqq · 2019-12-05T23:28:06.938Z

yeah, i’ve been been meaning to revisit this actually. some context here:

github.com/monome/norns

param remove

monome:master ← monome:param_remove

opened 11:55PM - 04 Oct 19 UTC

pq

+24 -3

tl;dr “remove” is actually tricky since it would necessitate remapping a bunch of indexes to keep reverse lookups sane. maybe better to just clear all and re-add.