January 11, 2017 at 11:57 am #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.January 11, 2017 at 6:57 pm #70907
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.January 12, 2017 at 12:35 pm #70909
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.January 12, 2017 at 1:39 pm #70910
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
January 12, 2017 at 3:54 pm #70914
- This reply was modified 1 month, 1 week 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.January 12, 2017 at 3:56 pm #70915
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.January 12, 2017 at 4:13 pm #70916
If you need any sort of help let me knowJanuary 12, 2017 at 4:59 pm #70917
I’ll try to have some static mockups and i will present them here, hoping for feedback.
You must be logged in to reply to this topic.