Old 06-28-2019, 11:58 PM   #1
MaXyM
Human being with feelings
 
Join Date: Aug 2018
Posts: 310
Default state of mcp folder

Is it possible to recognize using WALTER that an MCP folder is currently compacted (children are hidden)?

I would like to draw folder icon on folder track or on the last child depending on if the folder is compacted or not.
I didn't find any helpful in WALTER reference. Tried to play with folderstate variable but without success
MaXyM is offline   Reply With Quote
Old 06-29-2019, 07:58 AM   #2
White Tie
Pixel Pusher
 
White Tie's Avatar
 
Join Date: Mar 2007
Location: Blighty
Posts: 2,543
Default

folderstate<0
__________________
The House of White Tie
White Tie is offline   Reply With Quote
Old 06-29-2019, 11:39 AM   #3
MaXyM
Human being with feelings
 
Join Date: Aug 2018
Posts: 310
Default

folderstate<0 is true for the last track only. It doesn't indicates that folder is compacted or not. And of course, it's not true for folder track which is compacted.
MaXyM is offline   Reply With Quote
Old 06-29-2019, 12:38 PM   #4
White Tie
Pixel Pusher
 
White Tie's Avatar
 
Join Date: Mar 2007
Location: Blighty
Posts: 2,543
Default

.....
__________________
The House of White Tie
White Tie is offline   Reply With Quote
Old 06-29-2019, 06:15 PM   #5
Never
Human being with feelings
 
Join Date: Jul 2016
Location: Ohio, USA
Posts: 404
Default

Quote:
Originally Posted by MaXyM View Post
Is it possible to recognize using WALTER that an MCP folder is currently compacted (children are hidden)?

I would like to draw folder icon on folder track or on the last child depending on if the folder is compacted or not.
I didn't find any helpful in WALTER reference. Tried to play with folderstate variable but without success

The 4 elements below are drawn with the 'set.mcp.folder' command:

png name~~~~~~|element type~~~|scalar (see SDK)~~~~~|condition/state

mcp_folder_on (sliced-button):~~~folderstate==1~~~~~~~~drawn on parent*

mcp_folder_last (sliced-button):~folderstate<0~~~~~~~~~drawn on last tr./fldr

mcp_fcomp_off (sliced-button):~~~folderstate==1~~~~~~~~drawn on parent**

mcp_fcomp_tiny (sliced-button):~~folderstate==1~~~~~~~~drawn on parent***

*drawn on parent when 'show clickable icon for show/hide children' is unticked
(trackcomping is turned off in mcp.)

**drawn on parent when trackcomping is ticked in menu (see above), but when
comping has not been activated in mixer. (showing all tracks.)

***drawn on parent when it's children are hidden.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~

The following are just to be thorough for any user theming with this info:
(see all about folders and scalars at SDK)

Child track scalar: folderdepth>1
No folder status (regular track) scalar: folderstate==0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~

When 1 or more folders are active, the following 2 elements are drawn on top of a parent folder track background but underneath all mcp.* elements. The images can be used as a 'folder or buss' style replacement to the normal mcp_bg image, they can be used to do masking or overlays, etc., for example using partial transparency. Note: these images do NOT take on user selected track color. To show a track's color, you must make the colored areas of the mcp_bg element transparent on THESE elements. So the coloring shows through upon compositing.

mcp_folderbg (bg):

mcp_folderbgsel (bg):

The folderbg and folderbgsel elements are not controlled by WALTER.
REAPER automatically draws them. (When they exist)
Never is offline   Reply With Quote
Old 06-30-2019, 03:26 AM   #6
MaXyM
Human being with feelings
 
Join Date: Aug 2018
Posts: 310
Default

Thank you for comprehensive answer. Really useful.
It confirms by worries, that there is no way to distinguish state of the folder using WALTER.
folderstate==1 means it's folder track, it says nothing about its state. WALTER reference confirms it:

folderstate -- folder state of track, if applicable (0 for normal, 1 for folder, n -n for last track in folder(s))While it's true that mcp_fcomp_off/tiny are shown as you described, I cannot make them different positioned/size-wise

What I want to achive is add visual cues when subfolder is collapsed.
See image below.
The first picture shows all children visible. Second one shows subfolder collapsed. As you can see there are visible "folder begining" indicators, but "folder end" indicator is shown only for most parent folder last track.
The third image is a mockup of how I could imagine it. But we already now I cannot display additional image because in fact this is always THE SAME image object, content of which is being changed by reaper.



I managed to create all images of the same size, ie mcp_fcomp_off to be as wide as track with partially transparent content. It has a drawback however - the transparent part is clickable also. I suppose it can be solved by yellow lines... which will work for my mcp_fcomp_off image, but not for mcp_fcomp_tiny from my design since it would have middle part transparent.
MaXyM is offline   Reply With Quote
Old 06-30-2019, 12:31 PM   #7
Never
Human being with feelings
 
Join Date: Jul 2016
Location: Ohio, USA
Posts: 404
Default

Quote:
Originally Posted by MaXyM View Post
Thank you for comprehensive answer. Really useful.
It confirms by worries, that there is no way to distinguish state of the folder using WALTER.
folderstate==1 means it's folder track, it says nothing about its state. WALTER reference confirms it:

folderstate -- folder state of track, if applicable (0 for normal, 1 for folder, n -n for last track in folder(s))While it's true that mcp_fcomp_off/tiny are shown as you described, I cannot make them different positioned/size-wise

What I want to achive is add visual cues when subfolder is collapsed.
See image below.
The first picture shows all children visible. Second one shows subfolder collapsed. As you can see there are visible "folder begining" indicators, but "folder end" indicator is shown only for most parent folder last track.
The third image is a mockup of how I could imagine it. But we already now I cannot display additional image because in fact this is always THE SAME image object, content of which is being changed by reaper.



I managed to create all images of the same size, ie mcp_fcomp_off to be as wide as track with partially transparent content. It has a drawback however - the transparent part is clickable also. I suppose it can be solved by yellow lines... which will work for my mcp_fcomp_off image, but not for mcp_fcomp_tiny from my design since it would have middle part transparent.
Well, you are correct about the fact that there is no way of using code to
tell REAPER to do what it is you want to do, sir, because, well, in all
fairness, you are asking something impossible; you want REAPER to draw the
indicator for LAST child track > onto the PARENT track !! LOL!!
Of course there is a way to do it; you have it figured, I think.
Of a number of ways to do it, the easiest would be to replace all 3 .png's
relevant to folder indication/fcomping. This would definately break whatever
layouts are already using the old ones. NOTE: Part 2 is only necessary if
you want to keep the old images and old operation intact for the other layouts
that may be utilizing them. It just goes into creating a new folder and layout
and saving the new images, etc. So if you are going for the gusto and
replacing the images right in the root of the theme, you can now skip to
part 3.

------Pt.2-----------------------------------------------------------------
No sweat, if there are layouts you want to keep that utilize the old image, create a new folder in the root of the theme folder titled 'Your_Title'. Now
create a new layout in the RTConfig right after the layout you were working
on, title the layout 'NuComp_Strip' or whatever and copy the WALTER from the
last layout to this one. The only thing you change will be the
'set mcp.folder' code.
(we will get disciplined for breaking the D.R.Y. rule later.)
Now make your new .png's. Once you are done, they are all that will go into
the new folder;
------Pt.3-----------------------------------------------------------------
New .png's:

mcp_folder_last
mcp_fcomp_tiny
mcp_fcomp_off

Now that the new images are in place, you have to change the WALTER line:
'set mcp.folder........' to make the whole thing work. Since these panels are
now a uniform size, (the total width of the parent), there will be no need for
a conditional like 'h<' or 'folderdepth<0'.
To change the WALTER, first keep the old line by putting a ';' in front of it,
this way we can cheat off of it. Now, I am going to make up some stuff,
and you will just look past my obvious wrong guesses, and make your correct
changes. Lol.

Old line:

set mcp.folder folderstate<0 [75 352 7 18 0 1 0 1] [0 352 18 18 0 1 0 1]

Supposing that your layout is 95Px wide, which would mean that your
new .png's are 3x95 Px + No pink bits cause we don't need them = 285 Px wide,
and let's say 23 Px high. Those are my guesses, so we'll use those numbers here, and you can fill in with yours later. This is gonna be a super simple
line of code. You just need to get the height, {y}, correct. Here it says
the height {y} is 352, so that is what I am going to use.

New line:
set mcp.folder [0 352 95 23 0 1 0 1]

That's it. No need for folderstate<0, because all of our new images are the
same width. The old ones were 18x18 except for the 'last' image, which was
only 7x18, hence the need for that code. REAPER automatically draws the 1st
images, under the correct conditions, (the off and tiny images), and it
automatically draws the last image on the last track. Our hack here is that
we took the image that indicates the last track, and actually pasted it onto
the image that shows up when the comping is on (when all the tracks except the
first are hidden), and it will show the user that it is now for all intent,
the 'last' track, so to speak. Because of the logic that REAPER uses to make
all of this happen, it was cheap and easy for us to hack that one.
Limitations: Yes, the entire bottom 95x23 Px has become the foldercomp button, and if clicked, will activate or deactivate that feature....so what, there's
no reason to click down there anyway. Since the trackidx needs no user
interaction and is simply drawn, it can still be seen.
Things to remember: Do not forget to tick 'Clcikable icon for folder tracks
to show/hide children' in the master MCP right-click context menu to enable
this feature. Also, if the Z-order is not correct, you will not be able to
click the foldercomp button, because mcp.trackidx is drawn over it, it is just
transparent. To fix this, add 'Front set mcp.folder'. Just add it at the end of the layout for right now so you know it is positioned to work.
Well, you should have something tantamount to what you are looking for, hopefully. It seems like such a long-winded bit of red tape for this, lol.

Here are pics of the new images I created to illustrate the method.
The 4th image is just showing you the guides in Photoshop, so you
can see where the image is sliced. Also, I drew green lines around the perimeter of the panels because there is transparency and it is going to be
drawn by the browser onto white....I almost forgot this was going to
happen, it would not have looked reassuring.

mcp_fcomp_off:


mcp_fcomp_tiny: (the one with the hack)


mcp_folder_last:


showing guides at slices:


Hope this helps!
Never
Never is offline   Reply With Quote
Old 06-30-2019, 02:29 PM   #8
lucas_LCS
Human being with feelings
 
Join Date: Dec 2015
Posts: 632
Default

Quote:
Originally Posted by Never
New .png's:
mcp_fcomp_tiny
mcp_fcomp_off
maybe I'm misunderstanding the request, but shouldn't the Fcomp_Tiny image be the only one to show the 'End Folder' image, so it indicates the collapse?
Example:


The trackIDX image here is given level priority over the Fcomp image using the FRONT statement at the beginning of the layout
FRONT mcp.folder mcp.trackidx
This makes the Fcomp unclickable in the area covered by the trackIDX.

.
Attached Images
File Type: png Fcomp-test-large.png (14.7 KB, 166 views)

Last edited by lucas_LCS; 06-30-2019 at 03:15 PM.
lucas_LCS is offline   Reply With Quote
Old 06-30-2019, 05:22 PM   #9
MaXyM
Human being with feelings
 
Join Date: Aug 2018
Posts: 310
Default

Yes, but all images need to be the same size. mcp_folder_last can be te only one exception because you can set its size in WALTER thanx to folderstate<0 condition.

I went the direction mentioned in my previous post, and the. described in details by Never (thank you for your readiness to help although there was no need to go for such details, but hopefully others might learn from this too).

However I have a problem with showing track index number.
Lucas, I suppose images in your example are as wide as a track, aren't they? Is it FRONT command which made it working for you? In my case this command doesn't help.

Code:
front  mcp.folder mcp.trackidx mcp.pan.label mcp.width.label mcp.fx mcp.fxbyp

set mcp.folder [0 304 88 16 0 1 0 1]

set mcp.trackidx [0 304 88 16 0 1 0 1]
set mcp.trackidx.color [187 187 187]
set mcp.trackidx.margin [0 0 0 0 0.5]

Last edited by MaXyM; 06-30-2019 at 05:32 PM.
MaXyM is offline   Reply With Quote
Old 06-30-2019, 05:58 PM   #10
lucas_LCS
Human being with feelings
 
Join Date: Dec 2015
Posts: 632
Default

Quote:
Originally Posted by MaXyM
However I have a problem with showing track index number.
Lucas, I suppose images in your example are as wide as a track, aren't they? Is it FRONT command which made it working for you? In my case this command doesn't help.

Code:
front  mcp.folder mcp.trackidx mcp.pan.label mcp.width.label mcp.fx mcp.fxbyp

set mcp.folder [0 304 88 16 0 1 0 1]

set mcp.trackidx [0 304 88 16 0 1 0 1]
set mcp.trackidx.color [187 187 187]
set mcp.trackidx.margin [0 0 0 0 0.5]
One thing to be aware of is that the size of the TrackIDX label needs to be smaller than that of the Fcomp/Folder and positioned to start to the left of Fcomp "Button" area.
The following is the code used in my earlier example:
Code:
front mcp.folder mcp.trackidx
set mcp.trackidx 	 	 	[26 592 31 21 0 1 0 1] 
set mcp.trackidx.margin 	[0 4 0 4 0.5]
set mcp.trackidx.color 		?recarm [255 100 100] [163 171 179]

set mcp.folder 			folderstate<0 [0 593 80 19 0 1 0 1] [0 593 80 19 0 1 0 1]
I tested putting the set mcp.folder statement before the set mcp.trackidx statement and it worked that way as well.

.
lucas_LCS is offline   Reply With Quote
Old 06-30-2019, 06:51 PM   #11
Never
Human being with feelings
 
Join Date: Jul 2016
Location: Ohio, USA
Posts: 404
Default

The way I showed will work, but of course I said, there are a number of ways to do it. Mine involved no conditionals or extra work.
No the mcp.fcomp.tiny is NOT the only one that has to show the last indication.
The mcp.folder.last has to show the last indication to indicate a last track
when the tracks are UNcompressed.
The trackidx can be the same size as the width of the track.
ALL the folder/fcomp images can also be that same size.
Yes, we know that there is a front trackidx statement, I already showed him
how to disable that in a different thread, yesterday. (And reminded him here.)
The folder indicators work as expected this way, as does the fcomp feature,
and it DOES remain clickable; remember, I told him to put the front mcp.folder
command at the end of the layout, I should have said at the end of layout before
the 'EndLayout' statement.
Actually, I should have just told him to disable the front set mcp.trackidx
command by putting a ';' in front of it like I showed yesterday.
That would have been even easier, and less confusion.
Either way, this method will work fine. there is no reason a user should have
to click the actual trackidx image, there is no control here, and since there
is plenty of transparency in the middle of the folder/fcomp images I showed,
there is plenty of room to make sure the trackidx number is always drawn, even
when track counts run into the latter hundreds.

Anyway, there are just 1 or 2 fine details that got overlooked, I'm sure as to why there is a problem, but if you are already putting in the extra work to do it a different way, then good on ya. I have actually gotten away from putting
the folder/fcomp stuff on the same level as the trackidx, still, I have done them this way since v4, no problem. I was going for ease. Whatever tunes your guitar lol. Hope you work it out.

Never

PS - Honestly, I personally prefer doing this nowadays with a combination of buttons
and WT's frame shift and margin shift hack on the trackidx elements, having frames for
folder, child, last, record, selected, etc.; also, I think the actual folderbg and folderbgsel are pointless, I always have.

Last edited by Never; 06-30-2019 at 07:11 PM.
Never is offline   Reply With Quote
Old 06-30-2019, 08:52 PM   #12
lucas_LCS
Human being with feelings
 
Join Date: Dec 2015
Posts: 632
Default

Quote:
Originally Posted by Never
No the mcp.fcomp.tiny is NOT the only one that has to show the last indication.
The mcp.folder.last has to show the last indication to indicate a last track
when the tracks are UNcompressed.
I was referring your the Fcomp images.
They both have the End Folder image on the right.

Quote:
Originally Posted by Never
The trackidx can be the same size as the width of the track.
ALL the folder/fcomp images can also be that same size.
Except in this case where the TrackIDX is being used to cover space on top of the Fcomp image.

Quote:
Originally Posted by Never
there is no reason a user should have
to click the actual trackidx image, there is no control here...
True, no one is suggesting otherwise.
That aspect of the TrackIDX is being used to mask the area to the right of the actual Fcomp/folder button image so that when you click in that area nothing happens.

.
lucas_LCS is offline   Reply With Quote
Old 06-30-2019, 10:29 PM   #13
lucas_LCS
Human being with feelings
 
Join Date: Dec 2015
Posts: 632
Default

Quote:
Originally Posted by MaXyM
However I have a problem with showing track index number.
Lucas, I suppose images in your example are as wide as a track, aren't they? Is it FRONT command which made it working for you? In my case this command doesn't help.

Code:
front  mcp.folder mcp.trackidx mcp.pan.label mcp.width.label mcp.fx mcp.fxbyp

set mcp.folder [0 304 88 16 0 1 0 1]

set mcp.trackidx [0 304 88 16 0 1 0 1]
set mcp.trackidx.color [187 187 187]
set mcp.trackidx.margin [0 0 0 0 0.5]
I downloaded your theme and edited the Default Layout.
I was unable to replicate your issue.
Please ignore the poor quality of the Fcomp/Folder PNGs.
I just made them quickly for testing:



Here is the code I used:
Code:
front mcp.folder mcp.trackidx mcp.pan.label mcp.width.label mcp.fx mcp.fxbyp mcp.folder

set mcp.folder folderstate<0 [0 305 88 19 0 1 0 1] [0 305 88 19 0 1 0 1]

set mcp.extmixer.mode [0]

set mcp.trackidx [0 320 87 18 0 1 0 1]
set mcp.trackidx.color [187 187 187  . trackcolor_r trackcolor_g trackcolor_b .]
set mcp.trackidx.margin [2 -32 2 0 0.5]
can you verify that your Fcomp and Folder images have transparency in the middle?
That's the only thing I can think it might be at the moment.

.
Attached Images
File Type: png Fcomp-IDX_Test.png (8.3 KB, 146 views)
lucas_LCS is offline   Reply With Quote
Old 07-01-2019, 04:05 AM   #14
MaXyM
Human being with feelings
 
Join Date: Aug 2018
Posts: 310
Default

You wouldn't believe it.
It works if I leave redundant condition:

Code:
set mcp.folder folderstate<0 [0 305 88 16 0 1 0 1] [0 305 88 16 0 1 0 1]
But if I remove the condition
Code:
set mcp.folder [0 305 88 16 0 1 0 1]
it doesn't work. trackidx is not rendered then

Playing with it I also ended with the state when number was initially rendered, but disappeared when hovering over folder button (of folder track). Then reappear when I clicked somewhere else.



Maybe I should rise a bug report since it looks like some corner case of WALTER optimization.

Anyway, I ended up with stable version. Thank you guys!
MaXyM is offline   Reply With Quote
Old 07-02-2019, 01:41 AM   #15
Never
Human being with feelings
 
Join Date: Jul 2016
Location: Ohio, USA
Posts: 404
Default

Quote:
Originally Posted by lucas_LCS View Post
I was referring your the Fcomp images.
They both have the End Folder image on the right.*

Except in this case where the TrackIDX is being used to cover space on top of the Fcomp image.**


True, no one is suggesting otherwise.
That aspect of the TrackIDX is being used to mask the area to the right of the actual Fcomp/folder button image so that when you click in that area nothing happens.***

.
OK maybe I am just lost here, and it happens at times. I am under alot of stress right now and a health situation, and I see I already overlooked the fact that the track number would disappear in that situation; stupid....It's
been such a long time since I used these elements this way I forgot.
Also, I could have sworn that this didn't happen with v5 and up. Guess I was
wrong. Anyway, he don't care about the tr. # disappearing on that parent track
so, yay, resolved, but what I am wondering is, because I cannot get it,
and it bugs me that I am not understanding the following:

*ok, after reviewing the posts, still a no from me because his request was
that he wanted the end cap to show up on the right side of the PARENT track
when it was compressed, obviously, this is somewhat erroneous behavior,
and he was saying all along, like, 'there is no way to make this happen with
WALTER, and like, why not??' And so that's when WT said '....' - he was like
yeah, no kidding. So I explained to him at the beginning of my long post that
the parent should not get that end(last) piece, ever because it is not the
last, but that is what he wants, and I get it, it's pseudo-sorta-correctish-like....when compressed, the parent track becomes the beginning and the end of that group of tracks. So that was the whole reason for reworking the .png's.

**ok, I don't get this one because there is no space to the right of the fcomp
image, it's .png is 18Px. how is the trackidx covering anything? I am just not understanding what....well....do you mean that the trackidx is covering the
area between the left and right side not covered by the folder/fcomp elements,
covering this space, not from visibility by the trackidxbg, but covering it
so that it cannot be clicked by a mouse? Because the trackidxbg images are nil, so they cannot really cover anything....idk, idk, idk........I am fried.
It does not matter, but it bothers me when I don't understand a concept,
because I am trying to understand everything about theming, WALTER, etc., that
I possibly can.

***ok, this one, I think, if I understand your explanation for the last entry,
is that the footprint of the trackidx is keeping the fcomp button from having a big clickable area that should NOT be clickable....If everything is in it's untouched state, before his mods, this shouln't be. I am obviously missing
something here, maybe it's brain cells.
Never is offline   Reply With Quote
Old 07-02-2019, 04:31 AM   #16
MaXyM
Human being with feelings
 
Join Date: Aug 2018
Posts: 310
Default

I never said It cannot be done with WALTER. I said (actually asked at first) that it's impossible to let WALTER to know whether folder is compressed or uncompressed. Since there is no variable which handles this information I really not understand WT's dots. I'm not talking about his the first answer which is simply wrong.

At second, my initial approach was wrong, which was originating in assumption that all those track related icons are separate objects. because they are always the same object, it's impossible to control appearance of beginning and end folder icons independently.

Then we end up with a solution of using one png covering combinations of appearance of beginning and end icons. Although it unveiled the minor bug, fortunately it can be done this way.

Is there a true need of displaying begin and end icons together on compressed folder? I thing such need is legit. But everyone is free to make his own theme
MaXyM is offline   Reply With Quote
Old 07-02-2019, 06:10 AM   #17
Never
Human being with feelings
 
Join Date: Jul 2016
Location: Ohio, USA
Posts: 404
Default

Quote:
Originally Posted by MaXyM View Post
I never said It cannot be done with WALTER. I said (actually asked at first) that it's impossible to let WALTER to know whether folder is compressed or uncompressed. Since there is no variable which handles this information I really not understand WT's dots. I'm not talking about his the first answer which is simply wrong.

At second, my initial approach was wrong, which was originating in assumption that all those track related icons are separate objects. because they are always the same object, it's impossible to control appearance of beginning and end folder icons independently.

Then we end up with a solution of using one png covering combinations of appearance of beginning and end icons. Although it unveiled the minor bug, fortunately it can be done this way.

Is there a true need of displaying begin and end icons together on compressed folder? I thing such need is legit. But everyone is free to make his own theme
Right, I see it implimented and it makes more sense to me now. I was just explaining how it came to be that I figured out exactly what you wanted,
because @Lucas LCS and @White Tie were both a little unsure of exactly what
it was you were trying to accomplish, and based on your first two posts,
I actually could not figure out what you were trying to do either, so....
I posted the whole 9 yards on folders and foldercomping in the MCP, and how
the WALTER works. I thought initially (after talking to you, and after I
posted a whole book), that you wanted to use WALTER to draw the
'mcp_folder_last' element onto the right side of the parent track,
(while foldercomping is on.) Hence, my bit about well, it's impossible because
it's erroneous. I of course, was making light of the situation, just tossing
a joke in. Users here want all kind of stuff, and no one's idea or need is any less relevant than the next. Communicating and being willing to follow through
with the discourse, even when someone seems unclear about things, even when
someone has an odd request, even when things seem to get off track.....
It's how things get resolved, and people get what they want, and even the
people answering the questions and coming up with solutions learn stuff too.
I have learned alot from trying to help people here and either providing
a solution that was a little off, or providing a solution for something other
than what they were trying to do, realizing if I would have went back and
re-read a few or all of the posts, I would have known exactly what they wanted, not only that, but I would have learned alot more about all kinds of things related. So now I always request clarification, both for your benefit
and mine. Nowadays, I actually use the forum search feature more than I use the SDK.

Anyhow, you have something passing for workable now, so I guess this issue is solved, and you could always do 4 other things to fix it correctly if you so
desired.

@Lucas LCS - Lmk what I am missing, maybe it will help me, because I am
always getting stuck on some tiny bug somewhere in a theme, and it takes
me forever to find what the problem was; it was something that I was not
just not seeing, though I looked right past it or even right at it.
Never is offline   Reply With Quote
Old 07-02-2019, 06:33 AM   #18
White Tie
Pixel Pusher
 
White Tie's Avatar
 
Join Date: Mar 2007
Location: Blighty
Posts: 2,543
Default

I'm assuming this must be a language problem.
__________________
The House of White Tie
White Tie is offline   Reply With Quote
Old 07-02-2019, 11:44 AM   #19
lucas_LCS
Human being with feelings
 
Join Date: Dec 2015
Posts: 632
Default

Quote:
Originally Posted by MaXyM
You wouldn't believe it.
It works if I leave redundant condition:
Code:
set mcp.folder folderstate<0 [0 305 88 16 0 1 0 1] [0 305 88 16 0 1 0 1]
But if I remove the condition
Code:
set mcp.folder [0 305 88 16 0 1 0 1]
it doesn't work. trackidx is not rendered then
Yes, I believe this is what White Tie has been attempting convey to you.

Quote:
Originally Posted by MaXyM
Playing with it I also ended with the state when number was initially rendered, but disappeared when hovering over folder button (of folder track). Then reappear when I clicked somewhere else.

Maybe I should rise a bug report since it looks like some corner case of WALTER optimization.

Anyway, I ended up with stable version. Thank you guys!
The bug is actually in either Janne's code or yours.
After confirming the issue with my copy of your theme, I made a test using the Fcomp and Folder End images from my theme to confirm it's not an issue with the image, but something else.
The issue was still there, so I made the TrackIDX image bright red and found it was actually appearing as a thin strip along the very bottom of the area you are working with.
I checked the code and found you had the TrackIDX margin set to -32 which pushes it above the actual image.
I changed the code and the margin to the below and appears to be working correctly now.
Code:
set mcp.trackidx [20 305 68 19 0 1 0 1]
set mcp.trackidx.color [187 187 187  . trackcolor_r trackcolor_g trackcolor_b .]
set mcp.trackidx.margin [-22 0 2 0 0.5]
I also found you have 2 entries for mcp.folder in your Front statement for the Default and FX Return layouts.
The second entry is at the very end of the statement which will cause the folder to be on top of the TrackIDX.

Last edited by lucas_LCS; 07-02-2019 at 12:51 PM.
lucas_LCS is offline   Reply With Quote
Old 07-02-2019, 01:19 PM   #20
MaXyM
Human being with feelings
 
Join Date: Aug 2018
Posts: 310
Default

I have to check the issues you are pointing out before further comments.

However 2 notes:
1. have you noticed the same product of condition you commented on? I'm pretty sure WT's answer wasn't about it, because at time he's answering products of the condition differs to each other.
2. -32 margin is trick intended to draw track number above actual trackidx object. it's intentional. it does matter if you select a color to the track. In short it's a workaround to avoid use of pink lines.

I'm going to prepare testcase with use of modified default theme to demonstrate found issues. If succeeded I will inform you about it providing test theme and project.

Thank you for your help. I appreciate your involvement
MaXyM is offline   Reply With Quote
Old 07-02-2019, 01:28 PM   #21
lucas_LCS
Human being with feelings
 
Join Date: Dec 2015
Posts: 632
Default

Quote:
Originally Posted by Never
***ok, this one, I think, if I understand your explanation for the last entry,
is that the footprint of the trackidx is keeping the fcomp button from having a big clickable area that should NOT be clickable...
Yes, that's the purpose here.
The Fcomp/Folder size is now the width of the layout, so the TrackIDX is being used to cover the area to the right that on first glance would not be expected to activate the folder collapse.
This is useful, since that area can be used to select the track.

I'm sure MaXyM appreciates your efforts.
Additionally, the images you posted helped me identify what he might be after and that allowed me to offer help as well.
Personally, I would have just changed the circle/arrow image for the Fcomp_tiny to red to signify it is a collapsed folder (see example below), but the OP seemed to want something more significant than this and your images clarified what that might be.




There are many pieces to the puzzle here:
- This element has at least 4 image files that may or may not need to be edited in order achieve the stated goal.
- There is confusion about this element because:
(1) In the TCP Fcomp and Folder are separate buttons and uses different WALTER code for position and size of the Fcomp and Folder
(2) In the MCP they appear to treated as the same button controlled or affected by the same WALTER code.


*personal note:
sorry to hear you've unwell.
hope you have a swift recovery.

.
Attached Images
File Type: png Fcomp-IDX_Test-Max-02.png (7.4 KB, 98 views)

Last edited by lucas_LCS; 07-02-2019 at 02:24 PM.
lucas_LCS is offline   Reply With Quote
Old 07-02-2019, 02:24 PM   #22
lucas_LCS
Human being with feelings
 
Join Date: Dec 2015
Posts: 632
Default

Quote:
Originally Posted by MaXyM
1. have you noticed the same product of condition you commented on? I'm pretty sure WT's answer wasn't about it, because at time he's answering products of the condition differs to each other.
I meant that White Tie was trying to indicate it is needed.
I have tested and confirmed that the IDX number disappears if the FOLDERSTATE condition is not used.
It does seem odd to have the IDX disappear without it.
I did a simple test by making the IDX background bright red and confirmed that it does in fact disappear if the FOLDERSTATE condition is not used.

Hopefully, White Tie can explain this behaviour or confirm it's a bug.

Quote:
Originally Posted by MaXyM
2. -32 margin is trick intended to draw track number above actual trackidx object. it's intentional. it does matter if you select a color to the track. In short it's a workaround to avoid use of pink lines.
I see, so you are using the IDX unconventionally to draw a small color strip at the bottom, is that correct?
Then the IDX cannot be used to to block the right half of the Fcomp button.

When selecting the Default layout and I am seeing brackets around the track number.
There are no brackets on the test layout (see image below).
How do you get the Default's brackets to appear?
This may be a clue as why the test layout number disappears.



Quote:
Originally Posted by MaXyM
Thank you for your help.
You're welcome!
.
Attached Images
File Type: png Fcomp-IDX_Test-Max-03.png (7.2 KB, 102 views)
lucas_LCS is offline   Reply With Quote
Old 07-02-2019, 02:37 PM   #23
MaXyM
Human being with feelings
 
Join Date: Aug 2018
Posts: 310
Default

Quote:
Originally Posted by lucas_LCS View Post
When selecting the Default layout and I am seeing brackets around the track number.
There are no brackets on the test layout (see image below).
How do you get the Default's brackets to appear?
This may be a clue as why the test layout number disappears.
I not sure tbh, I'm on vacations right now so have no access to my desktop pc. But I think it has something to do with background image for track idx. I guess Reaper adds brackets if there are no background images for this object.

Last edited by MaXyM; 07-03-2019 at 12:27 PM.
MaXyM is offline   Reply With Quote
Old 07-03-2019, 12:00 PM   #24
Never
Human being with feelings
 
Join Date: Jul 2016
Location: Ohio, USA
Posts: 404
Default

Quote:
Originally Posted by lucas_LCS View Post
Yes, that's the purpose here.
The Fcomp/Folder size is now the width of the layout, so the TrackIDX is being used to cover the area to the right that on first glance would not be expected to activate the folder collapse.
This is useful, since that area can be used to select the track.

I'm sure MaXyM appreciates your efforts.
Additionally, the images you posted helped me identify what he might be after and that allowed me to offer help as well.
Personally, I would have just changed the circle/arrow image for the Fcomp_tiny to red to signify it is a collapsed folder (see example below), but the OP seemed to want something more significant than this and your images clarified what that might be.




There are many pieces to the puzzle here:
- This element has at least 4 image files that may or may not need to be edited in order achieve the stated goal.
- There is confusion about this element because:
(1) In the TCP Fcomp and Folder are separate buttons and uses different WALTER code for position and size of the Fcomp and Folder
(2) In the MCP they appear to treated as the same button controlled or affected by the same WALTER code.


*personal note:
sorry to hear you've unwell.
hope you have a swift recovery.

.
Awesome thx for the reply, I am going to read and respond later, have an appt. in an hr. I have looked at your buttons and I like how you have been doing those lately. I started doing mine colored too in one of the ION layouts, I did see that WT was saying that if you do not use the folder* scalar, then the
index # disappears, but I guess just if the other element is also occupying
the area.....sounds like an area to me....a gray area....jk, I read some stuff
with him and Bernstraw back n forth, I will peruse ALL tonight.

Never
Never is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 02:14 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.