Norns: development

[dansimco]

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]

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

[tehn]

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

[dansimco]

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]

…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]

@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…

which is not so great looking

[tehn]

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

[Justmat]

That makes sense to me!

[Dewb]

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

[Justmat]

Ellipsis in the middle is a common strategy

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

[tehn]

could you post your concat function?

[Justmat]

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]

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]

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

[mimetaur]

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]

@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]

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]

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

[tehn]

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]

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

param remove

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.