FEATURE REQUEST: Groups

Home Forums General Using Ctrlr FEATURE REQUEST: Groups

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #71099
    human fly
    Participant
    • Topics: 124
    • Replies: 1070
    • Total: 1194
    • ★★★★

    i’ve come across something i think is very important for Ctrlr:

    it is very hard/impossible (afaik) to move multiple modulators
    together – unless you put them in a Group, and Lock it.

    If you then put that Group, with other Groups, into a main Group,
    (ie: if you have a Group for VCF parameters, another for VCA
    parameters, etc.) and try to cut+paste, or copy+paste, the Groups
    will paste EMPTY with no modulators in them. it doesn’t work.

    this is something that needs to be fixed/changed, imo.

    (i know this is a GitHub report issue, i’m just seeking
    confirmation from other users, or maybe a suggestion for
    overcoming this *problem*)
    —————————————————————–
    i think there is also a problem/fragility with the way objects
    are copied/pasted, and resultant positioning problems and
    disappearing objects, that re-appear on next load of project.
    this can cause really severe problems, with a load of unidentifiable
    copies appearing all stacked up, in top left corner or workspace,
    and not visibly belonging to any/their group, or tab.

    can this be looked into and resolved? i would say it is a priority
    issue (both of these are), and would *greatly* improve workflow.
    (i guess this is a separate feature request/issue but i don’t want
    to flood the New Topics list with them 😉 )
    —————————————————————–
    THIRD ISSUE for today… 🙂 is that Properties Panel value boxes
    can still SCROLL ACCIDENTALLY, and you may not even notice you’ve
    done it, which is a great shame if you’ve just put a lot of time
    in entering values in a long session, and then have to check through
    dozens or hundreds of modulators to make sure you haven’t screwed
    anything up !! > it’s nice to have a bit of certainty and finality
    when you’ve done the work.
    i suggest that these should never scroll unless clicked on first,
    how about that? maybe that’s a simple improvement to implement.

    the problem of course arises because you scroll to move up and down,
    on the left/title part of the Properties, and also use scroll to
    adjust values. this can be catastrophic if you accidently change the
    VSTIndex#, for example. or at least extremely discouraging. it kind of
    undermines one’s confidence in the software when you’re a newb.
    ———————————————————————
    >do you agree with these?

    #71106
    atom
    Keymaster
    • Topics: 159
    • Replies: 2945
    • Total: 3104
    • ★★★★★

    Yeah there are loads of UX issues i need to address and I will. I have some priority work in the engine though so this must wait, i need to stabilize the code and cleanup/order the luabind/lua stuff, there is a new branch on github that deals with that, once that’s done i’ll get to the UX part.

    #71107
    human fly
    Participant
    • Topics: 124
    • Replies: 1070
    • Total: 1194
    • ★★★★

    great. thanks for picking up on the post.

    a little idea i had last night:
    to avoid long scrolling down the Properties panel,
    how about having tabs at the top, for the sections?
    that way you’d always be working in the same space/area.
    it’s a big change but maybe worth considering.

    i made some comments on github (subv0x)

Viewing 3 posts - 1 through 3 (of 3 total)
  • The forum ‘Using Ctrlr’ is closed to new topics and replies.
There is currently 0 users and 74 guests online
No users are currently active
Forum Statistics
Threads: 2,495, Posts: 17,374, Members: 77,605
Most users ever online was 12 on January 22, 2019 3:47 pm
Ctrlr