WALTER: Help me with volume label pls

[gapalil001]

HI! i'm trying to place tcp.volume.label above tcp.volume (knobmode)
i have an issue, that the volume label won't allow to use volume knob (yes, it's knob)
i need this solution because i definitely like how it looks.



is there any way to make volume label (and pan/width labels) being ignored or "transparent" for mouse clicks?
i am not sure, but as i understand, all what it does is display values and haven't specific submenus, etc.. if that's impossible, i would move this to feature requests

[White Tie]

I believe that many have tried and failed at this before, I'm afraid, because 'front' is only a draw order control; it doesn't affect mouse interaction. Even if the only mouse interaction in question is just 'double click number to reset it'

[gapalil001]

Originally Posted by White Tie

I believe that many have tried and failed at this before, I'm afraid, because 'front' is only a draw order control; it doesn't affect mouse interaction. Even if the only mouse interaction in question is just 'double click number to reset it'

sad true

[Justin]

Coming to a +dev next cycle

[gapalil001]

Originally Posted by Justin

Coming to a +dev next cycle

Love this! thank you a lot!

[lucas_LCS]

Originally Posted by Justin

Coming to a +dev next cycle

Would it be possible to make the Pan/Width labels not clickable?
Similar to how the track IDX works.
It would be extremely helpful to be able to use them for creating backgrounds for other elements without accidentally clicking on them and changing the setting.

::

[gapalil001]

Originally Posted by lucas_LCS

Would it be possible to make the Pan/Width labels not clickable?
Similar to how the track IDX works.
It would be extremely helpful to be able to use them for creating backgrounds for other elements without accidentally clicking on them and changing the setting.

::

now labels works as previously if not placed above the sliders/knobs. i haven't huge experience as your, but (perhaps stupid question) what about yellow markers?


[edited]
i've thinking about creating feature request to add and place specific images via WALTER especially for extra backgrounds, like we have image "mybg_volpan.png"

front tcp.image.1
set tcp.image.1 "mybg_volpan.png" [666 13 69 69 1 0 1 0]

[lucas_LCS]

Originally Posted by gapalil001

now labels works as previously if not placed above the sliders/knobs. i haven't huge experience as your, but (perhaps stupid question) what about yellow markers?

Do you mean the yellow instead of Pink lines around the the border of the PNG file?
While the yellow area can be helpful, it is not flexible in both X & Y axis at the same time.
You can set it for one and not the other and the other will be flexible and vice-versa.
This leaves the flexible area in the other as part of the main or active section of the image.

I've had several instances where I need both X & Y to be flexible, but not be an active part of the image.

Originally Posted by gapalil001

i've thinking about creating feature request to add and place specific images via WALTER especially for extra backgrounds, like we have image "mybg_volpan.png"

front tcp.image.1
set tcp.image.1 "mybg_volpan.png" [666 13 69 69 1 0 1 0]

I'm guessing it won't be possible to have user defined names allowing for unlimited number of unnknown images.
I think they will need to have predifined names for the image(s) beforehand.
I suggest using more generic names, like:
custom_img01.png
custom_img02.png
custom_img03.png
or:
usr_img01.png
usr_img02.png
usr_img03.png

::

[gapalil001]

Originally Posted by lucas_LCS

I'm guessing it won't be possible to have user defined names allowing for unlimited number of unnknown images.
::

why not? we already have user defined folder(patch) names for layouts

[White Tie]

I'm fairly sure (though nothing is certain) that wouldn't happen, it has been asked before. IIRC there are major efficiencies that come from having a known and well constrained set of images that are used or ...er... something.

I would likely oppose this FR because there are things that would be nice and things that we're really missing, and I would hate for the devs patience for theming features to go on a big job for something that is 'would be nice' then we still don't have, for example, full theming and WALTER for the routing window panels.

I say this FYI, don't let me discourage you from seeing it your own way.

[lucas_LCS]

Originally Posted by gapalil001

why not? we already have user defined folder(patch) names for layouts

1. User defined folder names for layouts in WALTER was there from the beginning, it was not added later

2. It's not the same thing.
One is the path to pre-defined elements (images), the other is the elements (images) themselves.
It's "here's where the thing is" vs. "here's a thing, here's what you can do with it, here's how you can do those things with it".

::

[lucas_LCS]

Originally Posted by White Tie

I'm fairly sure (though nothing is certain) that wouldn't happen, it has been asked before. IIRC there are major efficiencies that come from having a known and well constrained set of images that are used or ...er... something.

I would likely oppose this FR because there are things that would be nice and things that we're really missing, and I would hate for the devs patience for theming features to go on a big job for something that is 'would be nice' then we still don't have, for example, full theming and WALTER for the routing window panels.

I say this FYI, don't let me discourage you from seeing it your own way.

This true, but my thought was they were able to add the recarm_norec image a while back, so maybe it's a possible to add another image without too much difficulty.

In any case, Justin seems interested in looking at making the Vol, Pan & Width label "transparent to clicks".
This alone would be very helpful.
Hopefully it will be something easy to implement.

::

[gapalil001]

Originally Posted by lucas_LCS

Would it be possible to make the Pan/Width labels not clickable?
Similar to how the track IDX works.
It would be extremely helpful to be able to use them for creating backgrounds for other elements without accidentally clicking on them and changing the setting.

::

I’ve just remember that i’d never hits double click on labels to set them default. I always hits sliders/knobs itself. I also don’t need any actions on them (exclude situations this thread was started for)

My philosophic and completely subjective opinion about all discussion here that theming is more(or maybe whole) about art, and as traditional for any art it’s completely subjective. there are things i would add or change (disturbance in my signature) but sometimes i met guys who use these to make their own piece of art. Also i had one success feature request that was cancelled because it’s broke other themes. I mean, that IMHO there is no way to make WALTER perfect for everybody

[lucas_LCS]

Originally Posted by Justin

Coming to a +dev next cycle

Didn't see in the dev, but it's in the RC:

+ Theme: hit test vol/pan/width labels [t=267524]

https://forum.cockos.com/showthread.php?t=267524

::

[gapalil001]

Originally Posted by lucas_LCS

Didn't see in the dev, but it's in the RC:

+ Theme: hit test vol/pan/width labels [t=267524]

https://forum.cockos.com/showthread.php?t=267524

::

v6.60+dev0609 - June 9 2022

[rncwalker]

It's your theme, just don't use the labels!

On my theme I do not use the labels, don't need them, I use my ears to make adjustments.


Robert

[gapalil001]

Originally Posted by rncwalker

It's your theme, just don't use the labels!
Robert

it's my theme, i just will use everything i want

[PhelixK]

Originally Posted by Justin

Coming to a +dev next cycle

This is a really nice feature (thanks for suggesting @gapalil001!)

As for the tcp volume label,
In addition to resetting to unity gain on double-click, it would be cool also to allow mouse wheel on values if/when the volume label background element is present.

I'm aware we can place the label on top of the volume knob itself and have it interactive, but this may not always be suitable for dynamic/responsive layouts. And in some cases, it may be useful to have values visible, without the knob itself.

Anyway, I much appreciate how it is now.

- and of course, it would be king to be able to enter exact values directly on the labels somehow!



.

[gainstager]

Originally Posted by UPDATE from gainstager in 2023:

I have since changed my feelings on this, now preferring it despite my initial growing pains. Recent updates have also provided better alternatives for the use case I detail below.

There is still a lot of relevant information on .margin and “blocking”, so focus on that. Have a good day!

Originally Posted by gapalil001

is there any way to make volume label (and pan/width labels) being ignored or "transparent" for mouse clicks?

Using margin is a better strategy.

TL;DR - label readouts do NOT have to be contained inside their image. Knowing this, I think we should regress back to the previous behavior, so that we can continue to have another trackidx -style element (which volume.label was), as they are the most precious thing for themers.


Here are some examples of moving the readout outside of the label using margin:

--------------------------------------------- PLACEMENT --------------------------------------------

set tcp.volume.label		tcp.volume			; equal in every way to volume control [for this example)
set tcp.volume.label 		+ * -2 [tcp.volume{w}]		; place label off to left side of volume control (for this example}
set tcp.volume.label.margin 	[0 0 0 0 0]			; START: readout is cleared, on label, let's begin!

------------------------------------------- GOING OFF GRID -----------------------------------------

;				alignment	placement	reference from volume control

set tcp.volume.label.margin + 	[0 0 0 0 0.5]	* -4		[0 0 tcp.volume{w} 0 0]			; readout is CENTER control, center aligned
set tcp.volume.label.margin +	[0 0 0 0 0.5]	* [0 -2 -4]	[0 tcp.volume{h} tcp.volume{w} 0 0]	; readout is ABOVE control, center aligned
set tcp.volume.label.margin +	[0 0 0 0 0.5]	* [0 2 -4]	[0 tcp.volume{h} tcp.volume{w} 0 0]	; readout is BELOW control, center aligned
set tcp.volume.label.margin +	[0 0 0 0 1]	* [0 0 -1]	[0 0 tcp.volume{w} 0 0]			; readout is LEFT of control, right aligned
set tcp.volume.label.margin +	[0 0 0 0 0.5]	* [0 0 -6]	[0 0 tcp.volume{w} 0 0]			; readout is RIGHT of control, center aligned

; toggle whichever behavior you prefer!

Margin values can be used like any other expression value.

Be as creative as you want! Use scalars, element references, custom variables, anything. Use the .margin expression, not just the 5th value for alignment:

-------------------------------------------- GETTING WACKY ------------------------------------------

set tcp.volume.label.margin 	  [0 0 0 0 0]					; START: readout is cleared, on label, let's begin!
set tcp.volume.label.margin + 	* [0 1 -1 0 1] [0 h w] 	+ [0 -20 680 0 1]	; readout is in track panel CORNER, right aligned

set tcp.volume.label.color 				[255 255 255 0 0 0 255]	; readout is cleared, default white, let's begin!
set tcp.volume.label.color 	* [0.32 0.53 0.64]	[h h h 255 0 0 0 0] 	; readout gets BRIGHTER when panel is big, DARKER when small

Perhaps using margin didn’t cross our minds beforehand. I wish I spoke up sooner. Because now, for me at least, my entire design is affected by the update.


We lost a trackidx dupe. Until / Unless we get custom images, volume.label indeed functioned as a “custom user-defined” image, ie a non-clickable / non-actionable image. It was incredibly useful for backgrounds, coloring, blocking—anything that trackidx can be used for. And just like trackidx, tweaking the readout placement (margin) is the compromise. Volume.label’s behavior was a feature, not a bug. If this happened to trackidx instead, we would all go bonkers.

Originally Posted by lucas_LCS

Would it be possible to make the Pan/Width labels not clickable?

Similar to how the track IDX works.

It would be extremely helpful to be able to use them for creating backgrounds for other elements without accidentally clicking on them and changing the setting.

::

Lucas’ request is exactly how I used volume.label; just like trackidx. Even though I surely want (more) non-clickable, only-for-pretty images, I think altering the labels is a bad solution, like we did here. We had two already, which is highly workable. Only having one now, makes things a lot harder.

Here’s how I was using volume.label, before the update:




Volume.label in blue, fronted for better visual. I used volume.label to block Solo’s hitbox, still allowing it to do really cool things, but reclaiming some useful negative space for normal click selection and such. This behavior is broken now, no longer blocking Solo at all. Readout is outside of the label, rockin on just fine.

Margin is powerful. It can keep readouts static, while their images can be fully dynamic. Just use reverse margin, one might say. Joking. Getting the front order right can be tricky, which I gather prompted the update: we want the readout always front and center, but without the actual label blocking controls underneath.


Well…that was always an option! Margins place the readout where you want, they don’t affect the underlying image, allowing you to place & use the label image however you like. It’s exactly the same workflow with trackidx, which we already know & are comfortable with. The pros certainly outweigh the cons: you get two free agent “custom images” with the previous behavior. Doing the extra margin work so that they still function as labels was always the tradeoff.


Now that we know how to utilize margins, and can appreciate the benefits of ye 'ol way, I think we can safely return back, with some new tricks and design ideas in mind!

Let me know what YOU think. Thank you for reading.

[Justin]

Originally Posted by gainstager

so that we can continue to have another trackidx -style element (which volume.label was), as they are the most precious thing for themers.

Not sure this makes sense -- the correct changelog line is:

+ Theme: hit test vol/pan/width labels last even when they are above other controls

So the only difference is that if you put the labels at the front, they won't be clickable if they intersect with other controls. If you don't put the labels in front of other controls, there's no change in behavior. If you're using the label to apply an overlay image on top of other controls, then this helps you (by preserving the usability of the other controls).

The real question would be -- what did you used to be able to do that you can't now?

[gainstager]

Originally Posted by UPDATE from gainstager in 2023:

I have since changed my feelings on this, now preferring it despite my initial growing pains. Recent updates have also provided better alternatives for the use case I detail below.

There is still a lot of relevant information on .margin and “blocking”, so focus on that. Have a good day!

Originally Posted by Justin

The real question would be -- what did you used to be able to do that you can't now?

Justin! Thank you for the quick response.

The last gif shows how I have been using volume.label. The blue is volume.label. It is fronted above a handful of other controls, on purpose. As they are wearing multiple hats, like the Solo control: it’s a button, and performs a full-panel decoration when toggled. Not strictly using a safe, non-interactive overlay, the base image dances its own jig, glowing up the fader as well.

But that’s just too much Solo. It covers the whole panel, everywhere you click, it toggles. I love the look, the trick it’s doing, but I need space for everything else. Enter volume.label pre-transparency, in all its glorious boundary. I front it above the sea of Solo’s decorations, and reclaim back some no-zone.

The only other element that is 100% safe like this is .trackidx. Which we use extensively in the same way all the time: decorate to your hearts content, then seal off a containment area.

Without it, the whole thing falls apart. I prefer improving our understanding of .margin instead, rather than losing 50% of our defensive line WALTER wise.

It’s logical to want to place the label directly on top of the volume control. But with .margin, it’s not necessary. Volume.label can do something only 1 other thing can do: block. That’s very useful for us themers. I miss my big block of nothing.


Apologies for cutting the log entry short, I’ll edit the full line in. Juggling between pre-release, this thread and official changelog.

[lucas_LCS]

Originally Posted by gainstager

The only other element that is 100% safe like this is .trackidx. Which we use extensively in the same way all the time: decorate to your hearts content, then seal off a containment area.

Without it, the whole thing falls apart. I prefer improving our understanding of .margin instead, rather than losing 50% of our defensive line WALTER wise.

It’s logical to want to place the label on top of the volume control. But with .margin, it’s not necessary. Volume.label can do something only 1 other thing can do: block. That’s a big deal for us themers. I miss my big block of nothing.


Apologies for cutting the log entry short, I’ll edit the full line in. Juggling between pre-release, this thread and official changelog.

This use falls apart if you doubleclick on the area occupied by the Volume label.
Doubeclick resets the volume to zero.
This is an undesired action that has no equivalent in the TrackIDX area.
Margin will not affect this 'hit' area since that is determined by the pink lines in the image.
Using Yellow lines is not a feasible allternative because you cannot stretch the area inside the yellow lines without stretching the area inside the pink lines.

::

[gainstager]

Originally Posted by UPDATE from gainstager in 2023:

I have since changed my feelings on this, now preferring it despite my initial growing pains. Recent updates have also provided better alternatives for the use case I detail below.

There is still a lot of relevant information on .margin and “blocking”, so focus on that. Have a good day!

Originally Posted by lucas_LCS

Doubeclick resets the volume to zero.
::

Is this a part of the updated behavior, or was it also the previous behavior? I’m not at my studio today to check, but I don’t remember feeling worried about any clicks using volume.label as a 2nd trackidx stand-in. This post from v6.37 discussion seems to suggest (though while discussing the routing button) that the volume label was/has been immune to clicks:

Originally Posted by Phazma

Oh and regarding the routing window, could you please allow that to open when right-clicking on the volume label? Currently it works only when clicking on the volume fader but many themes have a nice big number box as volume label and it is tempting to click it for typing a volume and somewhat disappointing that only the generic TCP context menu opens.. seems like a missed opportunity.

Even better would be if double click on label allowed to directly type a value (instead of resetting as happens on the fader). But I would already be happy with just right-click opening the routing window with volume focused.

If so, then volume.label’s qualities were equal to trackidx. Which I argue is quite special, when we consider themeing as a whole. I supplied my solution, which is to lean on margin instead, rather than retconning labels as pseudo-overlays for everyone, past and present.

In short, I think it’s better that labels be non-transparent and inoperable, as a stopgap until / unless we get custom images to work with. It’s supremely flexible graphically, and a non-issue behaviorally using margin. Particularly in the case of volume.label, as you almost always have to use it. It’s a big deal, losing something immune to clicks. Or at worst, all but double clicks. I was content with that.

If anything, making volume.label behave rather how track names do, .label, is preferable and seemingly a more common request. That would be [single click = nothing, double click = enter specific value], I can’t contest the utility of that, short-term. Even if it upsets my theme design.

[Justin]

So in summary: You want to use the volume label to block hit testing for other controls (even though a doubleclick in this area would have the counterintuitive effect of resetting the track volume to unity)?

Edit: side note: using margins to place label text outside of the control may not be reliable if that text intersects other items and those other items are updated.

[gainstager]

Originally Posted by UPDATE from gainstager in 2023:

I have since changed my feelings on this, now preferring it despite my initial growing pains. Recent updates have also provided better alternatives for the use case I detail below.

There is still a lot of relevant information on .margin and “blocking”, so focus on that. Have a good day!

Originally Posted by Justin

So in summary: You want to use the volume label to block hit testing for other controls (even though a doubleclick in this area would have the counterintuitive effect of resetting the track volume to unity)?

Edit: side note: using margins to place label text outside of the control may not be reliable if that text intersects other items and those other items are updated.

In lieu of a better alternative, yes exactly. One safe click for track selection is a good start for using volume.label this way. It’s no doubt a cheeky play, especially as a cornerstone of one’s panel design. But for the vast majority of themes I see, readouts stick right with their label. It’s only edge cases like mine and OP’s that even want either workaround, for stacking controls or manipulating margin for readouts.

I am grateful that this conversation has become a goldmine of info, thank you. And am curious to see if other recent changes (v6.60: WALTER: using front for mcp.extmixer now brings extmixer background higher in the Z-order) may further assist us. Thank you for all the attention given recently to themeing.

In a perfect world, label backgrounds are inoperable while their readouts are clickable, if not directly editable. It’s the conflation of the two, and finding a suitable balance for the myriad of use cases, that has brought us here.

I have experienced some stuttering with the readout when adjusting the panel, it corrects immediately after the adjustment. Like you said, this only affects very layered themes like mine. Margin offsetting works just peachy for most all other situations. Higher refresh rates for readouts would rock some socks, but I’m content with my already niche request. Thank you again, Justin.

[lucas_LCS]

Originally Posted by gainstager

Is this a part of the updated behavior, or was it also the previous behavior?

Left Doubleclick on the Volume, Pan or Width label resets those controls to zero.
Right click brings up a menu.
Single left click does nothing.
This behavior goes all the way back to Reaper 3 (I tested it just now) and I believe Reaper 2 (I am unable to test v2 at the moment).

This is why I asked earlier if it would be possible to make the Pan/Width labels not clickable or selectable, in order to re-purpose them for other uses.
IOTW, make them act or work like TrackIDX works.

Having just one of these labels act like the TrackIDX would greatly beneficial.

::

[gainstager]

Originally Posted by UPDATE from gainstager in 2023:

I have since changed my feelings on this, now preferring it despite my initial growing pains. Recent updates have also provided better alternatives for the use case I detail below.

There is still a lot of relevant information on .margin and “blocking”, so focus on that. Have a good day!

Originally Posted by lucas_LCS

[The click] behavior goes all the way back to Reaper 3 (I tested it just now) and I believe Reaper 2 (I am unable to test v2 at the moment).

Having just [one additional label] act like the TrackIDX would greatly beneficial.

Thank you Lucas! Apologies for not knowing its full behavior. Doing the WALTER dance, sometimes I get dizzy and forgetful. I either forgot I trained myself not to double click, or just never ran into it; why use lot click when one click do trick.

Justin confirmed the same as well earlier. I am sorry for my hyperboles of “EXACTLY like trackidx” everyone! It’s only 50% EXACTLY the same.

I still stand by a one-click-only-please volume.label, as a regression, or a full send for label backgrounds to be static and readouts be editable. My thoughts are (pedantically) clear by now, on which I truly appreciate all the feedback, thank you. I’m open to whatever is best for everyone.

[gapalil001]

this comment is a bit dated, but sorry for late

Originally Posted by gainstager

Using margin is a better strategy.

yeah, it was a first thing i tried in a few different ways - in my case writing disappears when goes out of coordinates (but keeps when theme scaled)
as you understand, thanks to Justin this workaround is out of sense now

but anyway, thank you for support discussion and some additional stuff here

[gainstager]

Originally Posted by gapalil001

yeah, it was a first thing i tried in a few different ways - in my case writing disappears when goes out of coordinates (but keeps when theme scaled)

Scaling is surely the hardest test of all. Your theme scales very well, and no doubt took a lot of work and creativity to pull off. The last thing I want here is undo anyones progress, including my own.

I hesitate to say anything “disappeared”, WALTER usually only goes where we tell him to go. Correct me but, using +positive number values like [5 0 5 0 1] for margin constrains the display area, which can go up to the point of removing the readout entirely. Maybe this is what occurred? Whereas using -negative values like [-5 0 -5 0 1] expands the area. This is how you can push a readout outside of its label, on top of another control, etc. Only if that is what you want, of course.

Going back to your original post example, its already quite a confined area, as happens. It wouldn’t take much margin to trigger hiding the readout.

Messing with margins is largely only necessary if you have other plans for a label itself, like me, apart from its readout. If they are one in the same for you, the update makes all the sense in the world.

[gainstager]

Through the journey of this conversation, and as with all updates, I tend to come around to embracing change once I understand it more. Perhaps this new label behavior will prove to be a bigger asset than I can currently see while still leaning hard on its old behavior. A behavior that I wasn’t fully understanding to begin with.

I am happy to have given .margin some time in the sun, I feel it gets overlooked.

With that, I’ll let this one simmer for now.

[gapalil001]

Originally Posted by gainstager

Scaling is surely the hardest test of all. Your theme scales very well, and no doubt took a lot of work and creativity to pull off.

thank you! not actually hard in WALTER, but I spent a lot of time and nerves of sweat and blood to create all these 150% png's and they are completely freaking me out. i am still seeing the nightmares where i messing with them (and something went wrong, as usual)

Originally Posted by gainstager

I hesitate to say anything “disappeared”,

i am sorry for disappointing, "disappeared" isn't correct term. i should had said "cutted". all labels writes are cuts straightly when goes out of tcp.label coordinates ...

Originally Posted by gainstager

Whereas using negative values [-5 0 -5 0 1] expands the area.

... using this

[gainstager]

Originally Posted by gapalil001

i should had said "cutted". all labels writes are cuts straightly when goes out of tcp.label coordinates [even while] using [negative values].

That’s unfortunate to hear. If you tried what has been working for me, and it didn’t work for you, then I am officially glad for the update that works the same for both of us. All I ask is that we try all the options, and I feel we did.

…not specifically [-5 0 -5 0 1] though, right? that was just an example.