#388

@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_100631
20191204_1006314032×2268 2.16 MB

which is not so great looking :sweat_smile:

4 Likes
Cheat codes (v1.1.1)
#389

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

2 Likes
#390

That makes sense to me!

#391

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

7 Likes
#392

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

#393

could you post your concat function?

#394

:sweat_smile: 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)
1 Like
#395

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?

2 Likes
#396

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

4 Likes
#397

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.

#398

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

2 Likes
#399

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.

#400

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

#401

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?

2 Likes
#402

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

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.

#403

Well then how about a remove function that does the recreation for the user?

It seems really weird to have any type of list or table where you can’t remove something.

#404

i’m happy to look at that when the dust settles after @tehn’s big param refactor (if it doesn’t happen along the way).

#405

nah - one often wants reverse lookup in O(1) instead of O(N).

Anyways regenerating the reverse LUT should not be a big deal, but it makes removal expensive.

2 Likes
#406

Yeah well, I guess that’s just like, my opinion man.

Sorry if i came off negative.

#408

I’m curious if this is still in the works and expected to be released soon?

Not trying to be annoying, I’m just working on adding presets to a script but may hold off for now since I think the ‘data’ type would make my life much easier.