Visual indication of automated objects ( paint )

[zonkmachine]

When knobs aren't moving you notice the automation because you can't move the knob/slider. How about a little colour to separate them from the rest?

( Yes, that's a lame excuse of a paintjob but I closed gimp uttering curses... )

[diizy]

On 05/16/2014 01:41 AM, Oskar Wallgren wrote:

When knobs aren't moving you notice the automation because you can't
move the knob/slider. How about a little colour to separate them from
the rest?
automated-colour
https://cloud.githubusercontent.com/assets/6368949/2991634/255afcf4-dc81-11e3-9856-ddbbd8a37dfc.png
( Yes, that's a lame excuse of a paintjob but I closed gimp uttering
curses... )

A bit tricky... this could easily be implemented for the "standard"
knobs, like the vol/pan knobs in your mockup, by adding two new
qproperties for automated colours (line colour and arc colour)... not a
problem there.

However, the problems begin with the styled knobs... these are used in
plugins mostly and come in various colours, styles and sizes, so it'd
get messy very fast: would we use one colour for all styled knobs,
regardless of their native colours? Problematic, because one colour
won't fit all the different styles of knobs. Do we then use a different
colour for each knob? Also problematic: it gets messy and it sort of
loses its purpose - too many colours, not easy to see or remember which
colour means what for which knob...

And what about other widgets? Lcd spinners? Sliders? Would be a bit
weird and inconsistent to only implement this for a limited group of
knobs...

[Sti2nd]

As of 1.0.2 you can't even right click on a FX-slider, knob or lcd to find out what it is connected to... Wouldn't that be first priority?

[diizy]

On 05/16/2014 04:38 PM, Stian Jørgensrud wrote:

As of 1.0.2 you can't even right click on a FX-slider, knob or lcd to
find out what it is connected to... Wouldn't that be first priority?

What? Sure you can... there's something wrong with your installation if
right-clicking on knobs doesn't work.

[Sti2nd]

@diizy Ehm, no?! LMMS only displays knob connected to knobs and controllers, not automation... right? Everyone check that before you answer.

[diizy]

On 05/16/2014 04:57 PM, Stian Jørgensrud wrote:

@diizy https://github.com/diizy Ehm, no?! LMMS only displays knob
connected to knobs and controllers, not automation... right? Everyone
check that before you answer.

Well, it's easy to determine if a model (knob) has any automations
connected to it with the functions I just incidentally wrote, however...
how would that be represented in a context menu? With controllers, it's
easy - just display the controller name, but what would you display with
automations?

"Connected to that pattern at the left side of that other pattern... no
not that one, the other one" :)

[Sti2nd]

Well, you would use the name of the automation. Unfortunately/strangely automation tracks don't got numbering, so that would be one more improvement you could add at the same time?

[diizy]

On 05/16/2014 06:46 PM, Stian Jørgensrud wrote:

Well, you would use the name of the automation.
Unfortunately/strangely automation tracks don't got numbering, so that
would be one more improvement you could add at the same time?

How would they be numbered? Seems complicated...

[Sti2nd]

Don't you die on me diizy ⛵ Beat and Bassline 1, Beat and Bassline 2... I guess that is numbering or something else. That was what I had in mind at least.

[diizy]

On 05/16/2014 07:02 PM, Stian Jørgensrud wrote:

Don't you die on me diizy ⛵ Beat and Bassline 1, Beat and
Bassline 2... I guess that is numbering or something else. That was
what I had in mind at least.

But that's tracks. How would you number individual patterns?

[Sti2nd]

I thought about that, and I thought I would never reach an answer. Even auto track name is a big improvement, though.

[tresf]

I find this request to be spot on (despite the technical issues with the proposed mockup). Any time a knob stops working, it's essential from a usability perspective to illustrate that to the user.

In the past, I've used some graphics techniques to virtually "gray-out" components that didn't have their own "disabled" paint methods. @diizy, would this be a reasonable request? i.e. manipulate the graphic in real-time, rather than relying on components (such as the arc) that may not be available in all GUIs?

Alternately, overlaying a lock icon may have the same effect, but I can only assume that the more sprites we add to the mix the more difficult this will be to scale to all knobs use in the software.

[diizy]

On 05/17/2014 02:57 AM, Tres Finocchiaro wrote:

I find this request to be spot on (despite the technical issues with
the proposed mockup). Any time a knob stops working, it's essential
from a usability perspective to illustrate that to the user.

In the past, I've used some graphics techniques to virtually
"gray-out" components that didn't have their own "disabled" paint
methods. @diizy https://github.com/diizy, would this be a reasonable
request? i.e. manipulate the graphic in real-time, rather than relying
on components (such as the arc) that may not be available in all GUIs?

The problem with that is, that with styled knobs (the kind used by
almost all instrument plugins) the knobs are painted as parts of the
background, they're fixed in the plugin artwork. So unless we change the
way styled knobs work, and then go through all the instrument plugins
and change their graphics to work with this new paradigm, it's not
possible to change the appearance of those knobs dynamically.

This would be a large undertaking.

Firstly, we would preferably need all of the work files of all of the
plugin graphics - fortunately, at this point most of them have been
remade by me and I have kept all the layered project files, so those
would at least be doable, but then there's problems with older plugins
that still haven't been changed, like Freeboy, Patman and Vibed. Also
the couple that were made by others than me - LB302, Mallets, Sid,
Triple osc - I can't say whether others have been as diligent in keeping
work files available, or if they want to share them. Although, I guess
in some cases it would be pretty trivial to retouch the graphics to
detach the knobs from the backgrounds... I'd certainly be capable of
doing it, it's just a bit time consuming and I'm not sure if that's the
best use of my time/effort.

Secondly we'd have to modify the knob widget so that styled knobs are
not "transparent" but instead have a custom-defined knob image which is
painted on top of the artwork. Not that hard to do maybe, but then we
have to update the code in all the instrument plugins to reflect this
change, and we'd also have to add all the knob graphics as separate
image files in all the plugin directories (the second part is pretty
trivial though).

And /then, /we'd also have the additional step of creating second
versions of all the knob graphics, that show the knob in the "automated"
state, updating the CSS for knobs where we may want the line colour to
be different for automated versions, then update the knob widget code to
make this possible...

Most of the difficulty here comes from the amount of instruments we
have. None of the individual steps are that big or hard, but taken in
all together, it's a quite large project and not something I'd be
willing to undertake on my own - there would have to be some volunteers
who would also be willing to put in some serious work, for this to be
feasible.

There would be definite benefits in the change in architecture, with not
much of a downside - we'd be making the styled knob widgets behave more
consistently with all the other widgets we have - none of the other
widgets require parts of their graphics being painted in the background,
which is - as we can see here - quite a limiting solution, and one that
causes some amount of extra work for each new GUI design - having to
paint in knobs in the graphics software, then memorize their
coordinates, then align the widgets to them and hope you make no
mistakes and that they align perfectly... very error-prone. Also every
time you want to change a knob position, you have to edit the
background... with this change, you could just change a number in the
source and leave the backgrounds alone.

The only downside I can think of would be more image files to keep track
of.

So I'd definitely be for this change, but like I said, it's a big
project and needs more people to pitch in for me to even consider
starting it.

[tresf]

Vesa, thanks for the explanation as I had forgotten about the knobs which
are actually background images.

Since all knobs have indicators though, couldn't this be painted red once
the knob becomes locked? I don't know what determines that the knob is no
longer controllable, but would it be unreasonable to capture this, and just
make a slight change in the paint event?

https://github.com/LMMS/lmms/blob/stable-1.0/src/gui/widgets/knob.cpp#L564

-Tres

[diizy]

On 05/17/2014 05:53 AM, Tres Finocchiaro wrote:

Vesa, thanks for the explanation as I had forgotten about the knobs which
are actually background images.

Since all knobs have indicators though, couldn't this be painted red once
the knob becomes locked? I don't know what determines that the knob is no
longer controllable, but would it be unreasonable to capture this, and
just
make a slight change in the paint event?

See my earlier post. Only using the indicator has its own problems.

[StakeoutPunch]

Would it be possible to create a small indicator light similar to but smaller than the current indicator LEDs that is placed in the top left of the knob's placement box? It would illuminate to denote what the knob's state is using different colors - locked, connected to a controller, automated, etc.

[diizy]

On 05/18/2014 05:50 PM, StakeoutPunch wrote:

Would it be possible to create a small indicator light similar to but
smaller than the current indicator LEDs that is placed in the top left
of the knob's placement box? It would illuminate to denote what the
knob's state is - locked, connected to a controller, automated, etc.

No I don't think so... firstly, it has the exactly same issues as
already mentioned before, wrt. styled knobs.

Secondly, this would clutter the UI considerably, as we have some places
where the knobs are really tight, and adding extra clutter to the UI
would just make them very messy and unclear.