Q Light Controller+

It's been a while since I gave an update on the QLC+ 5 developments.
Well, they are proceeding, unfortunately rather slow, since I have a freaking busy period and I have to allocate my spare time in between many activities, like a new Raspberry Pi image, QLC+ 4 maintainance and bugfix, moderating the forums which are a mess lately...and of course QLC+ 5.

I'm not ready yet to produce a meaningful update video, but I've started to code some new exciting features that I'm hoping you will appreciate.
Some of the code is actually going into the QLC+ engine, and in theory it could be used by QLC+ 4 as well, but at this point all my efforts go to QLC+ 5, otherwise it will never see the light, and moreover there wouldn't be anything new comparing to QLC+ 4.

I think I solved most of the architectural design implementations for the new UI but there's one little thing that's buzzing around my mind since months, and I still haven't found a final solution for it. I'm talking about the "time tool" which is an essential part of Function editing (and many other things) and that can make the difference between "productivity" and "waste of time".
The tricky part is that in the QLC+ 5 philosophy, setting timings must be fast either using a touchscreen, a keyboard or a mouse.

Today I decided to write this post, to share with you what I am dealing with and to be open for comments and suggestions for the tool design and placement.
As usual, do not use this post to report QLC+ 4 issues (I know, it is ridicolous to even mention it, but I realize there is no limit to people's pertinence)
If you comment, try to explain as much as you can what's your idea in details. A plus is sharing a graphical mockup of what you have in mind.

So, let's start by looking at what we have right now. That is a monster tool ! To be honest I never liked it and I'm pretty sure some of you hated it while using QLC+ 4.
I tried to reduce the awkwardness of that tool by introducing a direct double click in the Chaser editor fields, to quickly enter a time string, but still, it is a custom case and in some occasions it might not work for everybody.

Let's now see a few design options to improve the situation, and moreover to have a centralize solution that could work well all across the UI.
First of all, here's how the new Chaser Editor looks like (please consider this is still a work in progress...): Nothing major news there, apart from the bottom area, which introduces expandable sections which I will largely use in the new UI. Oh, and now each entry has an icon, so you can quickly recognize the type of Function you added

And here's my initial idea for the new time tool (leaving aside colors and the not vertically centered text...): The ideas behind this concept are:
- it is compact
- the title bar shows the time parameter currently being edited
- it has a close button (top right) to hide it
- every button has at least the size of a finger (for touchscreens)
- the central area with the time is by default focused and selected to quickly enter a string manually
- seconds and milliseconds buttons are a bit larger than the others, cause they are probably the most frequently used
- it is a floating tool, so it can be moved around the screen (likewise all the other tools in QLC+ 5)

Now, the dilemma is: where should it be placed ?

My idea is that once a time field is double clicked, it should be displayed "in place". The other idea I had is that once the time tool is visible, pressing the TAB key should move to the next time field (something that is currently not possible with QLC+ 4)
Here's a shot of what I have in mind: As you can see, the selected Chaser step increases its height to embed the time tool.

The other options are:
- leaving the step height unchanged: - placing the time tool outside the Chaser editor. More or less what we have in QLC+ 4: So, what should I do ?

Hi Massimo,

thank you very much for your update and all the time you put into development!

First, I really like the idea of having an UI that is ready to use for touchsreens because I use them very often!

Please don't mind me to say, that I don't really like the idea to show this kind of time tool "in place". The changing height really could confuse users. Besides we need to think how to change to FadeIn/Out/Hold once you have selected one of them. With your idea of the time tool, I would more like the idea of having an extra "window" that could be drag&dropped to where you need it. Also, in that way it could be easy to select another time field and update the buttons of the "timing window".

But what came to my mind while I began to read your post was something different. Maybe this is not the best way for an exact setting of timing (and so shouldn't be the only way to set it at all) but I think it's a very nice solution, especially for usage with touchscreens.
Basically I thought about "lying" bars which are adjustable in length by the user. The first thing was some kind of "timeline". This probably could mean that the user is able to adjust the width of every column in the chaser table (this is what the blue arrows are trying to show): (please don't mind my painting skills that are not existing at all)

I think this is a possibility but not the best way to do because it will end in a mess with different column width and so on. A way to avoid this could be to, again, add a new window or only to display this "timeline" if desired.

Another way of doing all this is to not put the times in columns, but in extra rows per scene. Please have a look at this picture: I tried to illustrate what I have in my mind with the blue scene (please ignore the other ones). You can see that the 3 different times are no more separated vertically, but horizontally. Now the user is able to drag the right end of the blue bar and adjust it to it's needs. Of course, there should also be a text field to display the actual time, I forgot that in the picture.
This could also be implemented in a combination with your initial idea displaying all that "in place": The three bars are only visible as long as the blue scene is selected, if you select another scene, then the other one is "unfolding". This easily could be combined with to have a window pop up when clicking one of the three bars to set the timing precisely. A disadvantage of this solution would be, that you need two clicks until you are at the timing window for every scene:
1: select&unfold, 2: click on a bar to open the timing window.
But, I think this could possibly speed up the process of setting timings, especially with a touchscreen, immensely.

What are you thinking about it?

Hey Lukas, thanks for your feedback.
I have considered a sort of "dragging feature" to extend/reduce timings, but while it can be practical on touchscreens, it isn't so much with a mouse and not at all with a keyboard.
Plus, you need to think of all the possible cases:
- infinite time
- very different times. For example one can have 3 seconds fade in and 10 minutes hold. Representing them with bars in a consistent way would not work well
- there are users who like precise timing, to the millisecond precision, so this has to be possible (and fast) either for seconds, minutes or even hours

Anyway, let's elaborate the ideas and then see what becomes the most popular. Then I'll implement the one users really want. In the end I'm doing it for them, no matter what's my personal opinion on the matter

You're absolutely right, this needs some further considerations. The main part of designing such a UI for a cross - platform program is finding appropriate correspondences between controlling by mouse, keyboard and touch. So let me go through your points and make some suggestions on how to solve problems with the different controls.

mcallegari wrote: - infinite time

I don't think this is a huge problem. It could be done by tapping long onto the bar, right clicking or with a defined keyboard shortcut.

mcallegari wrote: - there are users who like precise timing, to the millisecond precision, so this has to be possible (and fast) either for seconds, minutes or even hours

As I already stated, my described way of setting the timing is definitely not what all the users want to do, so this could not be the only approach but a good one for those who like it. So maybe we could just have these two ways exist in parallel.

mcallegari wrote: - very different times. For example one can have 3 seconds fade in and 10 minutes hold. Representing them with bars in a consistent way would not work well

I think this will be the biggest problem. Also, we should think about how to change "scale" of the bars. My suggestion: Some in/out with fingers on touch, CTL+scroll with mouse and CTL+ some arrow keys on keyboard.
For displaying the bars there are some options:
1 - being consistent, what leads to a huge length difference between the bars and so smaller values are very hard to set (not my favorite approach)
2 - being inconsistent (also not the best way to do)
3 - being inconsistent and showing this as good as possible. Although I hate inconsistencies, maybe this could be done in a way where the user isn't confused. My first idea was to define different colors for different dimensions of timing: green - milliseconds, yellow - seconds, orange - minutes, red - hours. Even if we display the dimension (for example always at the end of the bar) in addition to colors this could also end in a mess. And a very ugly UI. But I'm running out of ideas at the moment - maybe someone has better ones?

(i'm sorry in advance for possibly going on a slight tangent here)

Im pretty excited about the recent developments in QLC+5, and one line in this post especially stood out to me.

The tricky part is that in the QLC+ 5 philosophy, setting timings must be fast either using a touchscreen, a leopard or a mouse.

As a keyboard power-user, aside from the time tool, how much will the rest of the interface be keyboard-optimized compared to these new developments and QLC+4, as the keyboard feels severely neglected in v4 driving me insane far enough to dive into the source code (as someone with barely any experience with c++) and sloppily hard-coded in some keyboard shortcuts for stuff I was doing a lot that had no shortcut assigned to it. What I have set up for v4 works great for what i need it to but better OOTB keyboard optimization would be highly, highly appreciated.

Anyways, i'm really loving where QLC+5 is heading, and I can barely to get my hands on the completed, functional UI.
Keep up the great work.
~RikSolo

RikSolo wrote:Im pretty excited about the recent developments in QLC+5, and one line in this post especially stood out to me.

The tricky part is that in the QLC+ 5 philosophy, setting timings must be fast either using a touchscreen, a leopard or a mouse.

Maybe you meant "The tricky part is that in the QLC+ 5 philosophy, setting timings must be fast either using a touchscreen, a cat or a mouse."

Jokes apart, yes, QLC+ 5 will try to tackle all the issues concerning keyboard controls. As I said, after 3 years of feedbacks (mostly complains) I heard you and will take the chance to resolve as much as I can with the new UI

I´ll go with siegmund. At least for the basic timing properties.
And perhaps on a larger scale, not 1 ms but 100 msec for example.
Or maybe CTRL+mouse = 1 ms otherwise 100 msec...

yokosuna wrote:I´ll go with siegmund. At least for the basic timing properties. And perhaps on a larger scale, not 1 ms but 100 msec for example. Or maybe CTRL+mouse = 1 ms otherwise 100 msec...

Please see my comments above

Hi,
How about a mixture of both ideas?

A slider with click boxes top and bottom.
The slider would allow large changes, and the click boxes allow for minor adjustment.
All would be useable with mouse, keyboard (using tab to cycle thru selections), touchscreen. etc.

A good idea as well, but this brings the issue of placing that dialog up again. What would you suggest on it?

My favourite is Massimo's 2nd option. A floating tool over the page.
I don't like the expanding row idea, though. To me it looks clumsy.
Perhaps in its 'options' you can choose where it pops up? 1) Under the pointer/selection, 2) Center of screen, or 3) xy coords.
Maybe all popup tools could have the xy option?

For the record, I'm a mouse/kbd user.
I had to shout loud enough to get my theatre group let me buy a new led fixture; a touchscreen I'd have to scream my head off.

So the tool could look something like this :
The button top left would colapse the tool, leaving only the title bar visible with the set time.
You could then open several tools at the same time, and take up minimal space?

Sorry but I don't like it.
It's huge and it has a lot of unused space.
Also I don't quite find a sense to waste so much space for the hours control. Most likely nobody will ever use it.

In general I have a few doubts that scrollbars is the way to go.

No worries, Massimo. It was just an idea..
With second thoughts, it wouldn't work anyway.
Rolling over from one column to another for instance. (getting to say 60 secs +1 would need the bar resetting and moving the Minute bar up 1...)

Did you see the other ideas?
1) Put the set time in the title bar?
2) A 'collapse' button in the title bar. - Collapse the tool leaving the title bar visible? (As in Frames atm) - Could have many tools open at a time.
3) User options as to where the tool apears - a) Under cursor, b) center screen, c) at a user set x,y screen position?

I like the idea of Tabbing thru TimeOption settings (FadeIn/Hold?FadeOut) - this would maybe mean the collapse button not needed?
Also use a mouse wheel for this?

Possibly use Shift-Click to increment each column by 10? and mS by 100

Hi Massimo,

Consider this:
- Click on the field of the time: open the pad
- Click on the arrow pointing upwards: closed pad and sends the values
- Stacked values in the units of measure: easier to read

nixs wrote:Hi Massimo,
Consider this:
- Click on the field of the time: open the pad
- Click on the arrow pointing upwards: closed pad and sends the values
- Stacked values in the units of measure: easier to read

Interesting view but: the tool wouldn't be floating anymore, so if you needed to copy the time value from the next row, you couldn't

Questions:
- why the need to apply the time only when the tool is closed ? Am I missing a usage case I didn't consider ?
- what do you mean by "Stacked values in the units of measure" ? Just "some space between the time nibbles" ?

I will come back to this topic as soon as I can. As usual, I got dragged into another million of things so I couldn't dedicate more effort to progress on this

I'm sorry if this counts as "digging up" an old topic but after my last project I might have got some ideas for the time tool problem:

First about the positioning: It's definitely necessary to see other steps when editing the time. I constantly had to copy other scenes' times into new ones. but when combining Massimo's very first idea (putting the time tool in the same row) and nixs' idea of opening a box right below the number it becomes way easier to read while still maintaining view of the other scenes.


Secondly: Working a lot with Adobe Photoshop i got used to clicking and dragging names to change the numbers in the fields they resemble. So in order to work "as fast as possible" with both mouse or touch input, one could combine the sliders and the traditional button-layout.
Once you click/touch and hold the number you want to change (ms, s, m or h) you can drag up or down to change the value.
To help identifying the number while doing some touch input, a simple "tooltip" could be added, that shows the current value right above your finger. In case of a mouse input, the cursor could simply change to a vertical resize, so the user knows what it does.

Both Ideas are of course independent from one another. I'm sure some would appreciate to have both options of positioning the time tool.

hello massimo, I personally like a good idea ... to think according to uses can be effective .... I think it would be good to have a gadget for virtual console for control times, but showing the time of the scene or chase that is in the active time, for example, if I have 4 windows in cv chase, and I want time control for each chase live, I have to add 4 windows and allocate time to chase affects ..... would be good a time window that can read and modify the time of the chase or scene that is running ... (more management control to live), and space-saving cv. greetings to all, are only suggestions which, according to my understanding in a real live use, can make life easier .... (as operator lighting)

admirable project. Congratulations

I know that I'm late in jumping on this discussion (and that the design might already be complete), but I thought I'd throw in my input anyway.

First, Massimo, keep up the good fight! There are so many of us who still use QLC+ 4 regularly and are eagerly anticipating QLC+ 5!

Second, as powerful as the time tool was in QLC+ 4, I do find it often cumbersome to use. So, I like the concept of a floating tool that pops up as you need it. Being a keyboard+touch user, I also like the idea of tabbing between time fields for entry (the tool would continue to shift focus to each next field as tab is repeatedly pressed). Also, ESC for closing the tool (so I can see what was underneath) would be a nice shortcut.

Finally, supporting the time string is a VERY powerful capability that allows very simple precise timing or ensuring that multiple items are synchronized, so please keep some ability to type in a "time string" as you put it.

I use this tool for Theatrical Productions (mostly musicals), which I know wasn't a primary use case, but it works great for 95%+ of what we need, and has such wonderful tech support!

Thanks again to everyone who keeps this project going!

Hello Massimo, you have done a great job. I don't speak very well english, so I hope to be not off-topic..

In my view there is the possibility to include in separate page common time tools and in the chaser the possibility to link to these common time tool.

common time tool can be timers, beat catcher for make step, ... make it generic. Try to integrate the concept of the loopback inside these new object will be a very good thing.

Thank you very much for your effort.

Bye