Home Forums General Using Ctrlr Very VERY difficult to navigate.

This topic contains 12 replies, has 6 voices, and was last updated by  jersmi 10 months, 4 weeks ago.

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
  • #70906

    CTRLR is amazing. Let me just say that. Now the harsh critique:

    It is impenetrable to me. On day one it was impossible to understand. 2 Years later it is still impenetrable. I would “get into it” if there was a hook somewhere for me as an entrypoint that was not entirely tedious and fiddly.

    Where to start…

    The Demo files don’t do much to help me understand what is going on. They just show off some ‘magic stuff’ with undocumented LUA methods. (where’s the LUA library reference in the CTRLR help section?, can it be there? at least a UTF-8 Text file will be fine. Even a link to CTRLR’s LUA function library itself would be fine.)

    “panel mode” seems to do the opposite of what i would expect. when something is a “panel” it is a usable panel, the final product, but you need to toggle on the panel mode to modify the CTRLR panel, (which seems to only be a long list of redundant color and font designators. I will get to that.)

    It’s great that there are 100 different color and font modifiers for each and every widget, but… actually no it is not great. One, maybe two colors per widget. one maybe two fonts per widget at max would be a thousand times better. in fact, force everybody to use a monospace font and be done with the fonts. I don’t care if the interface is only black and white with fixed font sizes and square rotary knobs, as long as i can make a panel with it.

    to me, all the color modifiers and endless (sorry to say ‘boring’) list of font stuff should be distinctly separated from the SYSEX, CC, and LUA stuff, on its own tab. Organizing this way would make it easier to work on without needing to scroll around looking for these fields. The parameter list for a simple knob widget should fit on one quarter of one column on the sidebar. instead the parameter list for each widget scrolls 3 times the screen height. That long parameter list of fonts, font sizes, and colors with no discernable destination makes me close the program. One maybe two colors per widget are all you need. I don’t care if my hardware synths have 6 different colors in the word “VOL” so similarly, i don’t care if a CTRLR panel has a rainbow of colors and 3 fonts per knob. It’s just not efficient with programmer time, how else can i say it?

    CTRLR is amazing and great, I am very thankful for your work as well as for the community’s contributions.

    For me, it is easier to use a text editor and Python + Tkinter to make the panels i need. There doesn’t really seem to be a good reason to use C++ to send and receive MIDI.

    My issues with CTRLR are that after years of keeping an eye on it, it is still very very hard to even crack the surface of the interface. There is too much memorization involved because there is what seems to be an English language barrier happening. So i am trying to follow English word cues to find my way around the interface of CTRLR, but these words aren’t good enough to cause my brain to click and say “ah, now i know what that does.”

    You are very nice and talented, CTRLR! but sometimes less is more.
    i want about 500% less color and font modifiers. even simple black and white would be great if it is easier to make panels with. especially if the XML is portable to Python for those of us who use Tkinter etc.

    thanks for reading.



    This is a good start: http://ctrlr.org/forums/topic/ctrlr-step-by-step-guide/

    While I agree that Ctrlr isn’t easy, in part because of the lack of documentation, the difficult part is LUA, I don’t see the interface an obstacle. Modulators have a lot of variables, yes, but this gives flexibility.

    You can just create a modulator, set all it’s variables to suit your needs, and then copy/paste to create the rest of similar modulators, only changing the midi variables and forgetting the look stuff. In fact, you can close the component variables of any mod in edit mode (click on the arrows next to “Component generic” and “Component”) so you just see the modulator and midi variables. Also, you can change variables of the selected modulators, not just one, and you also have the modulator list window where you choose the variables you want to work with.


    I know that the UI of Ctrlr is a mess and i wish i could make it better, but i just can’t i don’t know how, i hope to get a UX specialist to help me sort things out and guide me. I’m actually in talks with someone who does this.

    As for python, i will never implement python in any shape or form, i think this hole idea of Python as a programming language is a bad one, i don’t like it, and i won’t change my mind.



    My two cents…

    It would be possible to use an interface approach similar to Max?

    A floating window for modulator properties, with tabs for categories.

    A floating window to add modulators

    A status bar for useful quick access functions

    • This reply was modified 1 year, 1 month ago by  dasfaker.

    Well i’m trying to make it more like a “photoshop”/”max” program, so that in edit mode those toolbars “float”.

    The big problem is the property sidebar, there are loads of those properties and some of them have very long descriptions, i don’t have that figured out yet.

    I hope to clean the colours fonts and sizes of all objects to make it look more “natural”.

    Once i’m done with all the project/build-system changes i’m doing i’ll get to that, i’m not planning on adding any new features for now. It’s all code stability and User-eXpierience for now.


    Oh yeah one of the programs i told the UX person to look at was Max so i think the idea might go along this route.



    If you need any sort of help let me know


    I’ll try to have some static mockups and i will present them here, hoping for feedback.



    Struggling to get into Ctrl myself.
    I can’t get a grip on the panel categories.

    Panel: General, I don't get it

    I belive the main problem here is that there’s no distincion in the UI between making a very simple (like midi CC), intermediate (parameter sysex) or complicated controller (scripting and stuff).

    But it’s a program with huge potential.


    human fly

    well, if it’s any consolation to atom, i’m liking it more and more

    you do get used to it.

    there are a couple of very odd things that happen, but once you get
    used to it, you can resolve killer problems without too much trouble.

    i would recommend starting out by building a specimen structure,
    and saving that, and work on from that, saving versions.
    if you split the categories into Tabs at the top, it should
    make the whole view shorter, and much much easier to navigate.

    i spend a lot of time scrolling up and down, and the view
    is not necessarily remembered, and nor are items in the list
    always in the *same order*(?!)


    human fly

    a word about UIGroups – or rather about Copy/Delete ‘with children’:

    can be a real f***er: you think, ok, i’ll put all these
    into a Group, and just copy that.. but if you then have these groups inside
    another group, or on tabs, and you try to copy those or cut+paste,
    using ‘with children’, you can get into all sorts of trouble, because
    ‘with children’ only deals with 1st-level ‘ownership’, of any kind of
    modulator, so it will copy empty groups, leaving ‘orphan’
    controls/modulators behind – and in fact they don’t know where they belong
    any more (without getting melodramatic) and end up on your workspace,
    using 0,0(workspace) as their reference position.

    ie: if you copy a UITabs, with 4 tabs, each with a UIGroup containing
    25 parameters…you get 4×25 modulators, all overlaid on top of each
    other in stacks, in the top left corner – it isn’t even worth trying
    to put them back where they belong, especially if you locked them earlier.
    i’ve done this several times- just close the file without saving and
    re-open it! then find another way.

    in other words, it would be really nice if ‘inheritance’ went down as many
    levels as necessary.


    human fly

    also, Group ‘ownership’: needs to refresh/be refreshed, *each time*
    and object(modulator) is moved or copied. this can cause problems
    after you save and close, and re-open: you find a modulator in it’s
    old container(group/tabs) – same comment for UITabs ownership: doesn’t
    get refreshed automatically.

    i’m finding Ctrlr pretty stable. i’ve crashed it a few times, not many.
    my level of use is not very sophisticated, i am still not using layers,
    just UITabs, sussed out a few very basic Lua methods, and can manipulate
    those ok (my programming skills are zilch though) – and i’ve concentrating
    still on using onboard graphics – out of principle at this stage, i don’t
    want to spend time making graphics in knobman, and i think the Ctrlr visuals
    are very adequate.

    got some good help from other members recently too, so that has helped a lot.



    any news?

    atom, Ctrlr is a gem, I hope you can make it shine.

    +1 for mac updates, not sure how you feel about it at this point.

Viewing 13 posts - 1 through 13 (of 13 total)

You must be logged in to reply to this topic.

Comments are closed.