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 2 months, 2 weeks 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.March 23, 2017 at 1:02 pm #71730
Struggling to get into Ctrl myself.
I can’t get a grip on the panel categories.
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.March 25, 2017 at 3:34 pm #71738
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.
i’m subscribing to this topic, so if you have any specific questions,
i can maybe share what i’m learning.
YEAH, ATOM: my idea for the Properties panel is ok, i reckon:
if you split the categories into Tabs at the top, it should
make the whole view shorter, and much much easier to navigate.
at least it’s a simple solution for the time being.
dunno, worth a try to look at, if you have a test version where
you demo stuff like this.
you do 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*(?!..true, though)
i’ve posted a typed text list of all parameters on a topic
for suggestions for the/a future ‘manual’ follow-on to
Goodweather’s – it would be good to have a reference describing
each of the (less obvious) entries.March 25, 2017 at 3:46 pm #71739
a word about UIGroups – or rather about Copy/Delete ‘with children’:
can be a real f***er of a false friendl you think, ok, i’ll put all these
into a Group, and just copy that.. but if you then have these groups in
another ‘big’ 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
object/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.
so if you copy a UITabs, with 4 tabs, each with a UIGroup containing
58 parameters…forget about it, you get 4×58 modulators, all overlaid
on top of each other in stacks, in your top left corner, under whatever
Tabs, etc. is there, – and it isn’t even worth trying to put them back
where they belong, especially if you locked them earlier..
oh yes i’ve done this several times…but i know how to handle it now.
(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.March 25, 2017 at 3:52 pm #71740
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.March 27, 2017 at 9:57 am #71759
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.
You must be logged in to reply to this topic.