Issue with music progress bar.

[RoseRain]

To add a small indicator that shows the current progress and moves with the level, simply add a third shape to the [Progbar] section:

Code: Select all

[ProgBar]
Meter=Shape
X=35
Y=0
Shape=Rectangle 0,0,150,20 | Fill Color 100,100,100 | StrokeWidth 0

Shape2=Rectangle 0,0,([MeasureProgress]*1.5),20 | Fill Color 255,0,0 | StrokeWidth 0
Shape3=Rectangle (([MeasureProgress]*1.5)-2),0,4,20 | Fill Color 0,255,0 | StrokeWidth 0

barindicate.png

I did manage to do that. I was trying to make it so that it doesn't drag when you do it on the grey area, but does drag when you do it on the green bar or the red area. I hope i make sense haha. I did a seperate shape meter for that and it kind of works, but the drag is all kind of wonky.

[eclectic-tech]

I did manage to do that. I was trying to make it so that it doesn't drag when you do it on the grey area, but does drag when you do it on the green bar or the red area. I hope i make sense haha.

Separate the "grey" shape into a spearate shape meter; now the mouse drag and scroll actions only effect the "red" or "green" shapes.

Code: Select all

[ProgBarBack]
Meter=Shape
X=35
Y=0
Shape=Rectangle 0,0,150,20 | Fill Color 100,100,100 | StrokeWidth 0

[ProgBar]
Meter=Shape
X=35
Y=0

Shape=Rectangle 0,0,([MeasureProgress]*1.5),20 | Fill Color 255,0,0 | StrokeWidth 0
Shape2=Rectangle (([MeasureProgress]*1.5)-2),0,4,20 | Fill Color 0,255,0 | StrokeWidth 0

LeftMouseUpAction=[!CommandMeasure "MeasureProgress" "SetPosition $MouseX:%$"]
MouseScrollUpAction=[!CommandMeasure "MeasureProgress" "SetPosition +5"][!UpdateMeasure MeasureProgress][!UpdateMeter ProgBar][!Redraw]
MouseScrollDownAction=[!CommandMeasure "MeasureProgress" "SetPosition -5"][!UpdateMeasure MeasureProgress][!UpdateMeter ProgBar][!Redraw]
MouseOverAction=[!EnableMeasure "MeasurePercent"][!CommandMeasure "MeasureMouse" "Start"]
MouseLeaveAction=[!DisableMeasure "MeasurePercent"][!CommandMeasure "MeasureMouse" "Stop"]
DynamicVariables=1

[RoseRain]

Separate the "grey" shape into a spearate shape meter; now the mouse drag and scroll actions only effect the "red" or "green" shapes.

Code: Select all

[ProgBarBack]
Meter=Shape
X=35
Y=0
Shape=Rectangle 0,0,150,20 | Fill Color 100,100,100 | StrokeWidth 0

[ProgBar]
Meter=Shape
X=35
Y=0

Shape=Rectangle 0,0,([MeasureProgress]*1.5),20 | Fill Color 255,0,0 | StrokeWidth 0
Shape2=Rectangle (([MeasureProgress]*1.5)-2),0,4,20 | Fill Color 0,255,0 | StrokeWidth 0

LeftMouseUpAction=[!CommandMeasure "MeasureProgress" "SetPosition $MouseX:%$"]
MouseScrollUpAction=[!CommandMeasure "MeasureProgress" "SetPosition +5"][!UpdateMeasure MeasureProgress][!UpdateMeter ProgBar][!Redraw]
MouseScrollDownAction=[!CommandMeasure "MeasureProgress" "SetPosition -5"][!UpdateMeasure MeasureProgress][!UpdateMeter ProgBar][!Redraw]
MouseOverAction=[!EnableMeasure "MeasurePercent"][!CommandMeasure "MeasureMouse" "Start"]
MouseLeaveAction=[!DisableMeasure "MeasurePercent"][!CommandMeasure "MeasureMouse" "Stop"]
DynamicVariables=1

Yes, that's exactly what I did, but the drag is all wonky and the progress kind of jumps all over the place.
It doesn't do that when its in the same meter and I am trying to figure out why. it even skips back to the previous track instead of drag back. Or it skips forward when I drag back instead.

[eclectic-tech]

Yes, that's exactly what I did, but the drag is all wonky and the progress kind of jumps all over the place.
It doesn't do that when its in the same meter and I am trying to figure out why. it even skips back to the previous track instead of drag back. Or it skips forward when I drag back instead.

That is caused by the constant changing of the progress measure while dragging the mouse, not due to any meter changes; all the variable setting, measure and meter updates, and redraws, take time and may never be "smooth" in this scenario.

Honestly, I would abandon trying to use mouse drag to control progress and revert to your mouse-click and mouse scroll actions, which are more suited to working with progress settings. Just my opinion.

[RoseRain]

Honestly, I would abandon trying to use mouse drag to control progress and revert to your mouse-click and mouse scroll actions, which are more suited to working with progress settings. Just my opinion.

I am thinking the same thing. That is probably what I will do But it doesnt work bad keeping the drag, if the shape meters are not seperate. So maybe ill keep it like that.
Thank you!

[Yincognito]

Well, I don't get any wonkiness or any of the issues you folks experienced, everything works perfectly and I don't need to consider abandoning the approach. The "secret"? Start simple, from scratch, adding things one step at a time, fully aware of what they do (which comes by default when writing your own code from a clean base)...

ezgif.com-optimize.gif

It's interesting to see how stuff is ignored when code isn't provided, then people wonder why they can't figure why this or that happens. Hint: it's not how proficient one is at coding - everybody can do it, if there is willingness.

Short summary:
- as balala mentioned, the posted code is excellent to give you a direction, but it has to be improved (or even started over) to function as it should
- when I tested the posted code, it was quite slow (not sure why, and didn't bother to find out); not the case if you start clean as described above and monitor how things work at every step of the way, since when an issue happens you know exactly what caused it and where to change to fix it, aka the last step you performed
- it's wonky when you separate shapes because the mouse measure uses the variable X and W of the 2nd progress meter, and not the fixed properties of its "back"
- some of the jumping to previous and next track is related to not Clamp()-ing the progress variable between 0 and slightly less than 100
- the changing of the progress measure while dragging the mouse doesn't determine the smoothness of the process; it should be blazingly fast, as it can be seen in the above preview

[RoseRain]

Well, I don't get any wonkiness or any of the issues you folks experienced, everything works perfectly and I don't need to consider abandoning the approach. The "secret"? Start simple, from scratch, adding things one step at a time, fully aware of what they do (which comes by default when writing your own code from a clean base)...
ezgif.com-optimize.gif
It's interesting to see how stuff is ignored when code isn't provided, then people wonder why they can't figure why this or that happens. Hint: it's not how proficient one is at coding - everybody can do it, if there is willingness.

Short summary:
- as balala mentioned, the posted code is excellent to give you a direction, but it has to be improved (or even started over) to function as it should
- when I tested the posted code, it was quite slow (not sure why, and didn't bother to find out); not the case if you start clean as described above and monitor how things work at every step of the way, since when an issue happens you know exactly what caused it and where to change to fix it, aka the last step you performed
- it's wonky when you separate shapes because the mouse measure uses the variable X and W of the 2nd progress meter, and not the fixed properties of its "back"
- some of the jumping to previous and next track is related to not Clamp()-ing the progress variable between 0 and slightly less than 100
- the changing of the progress measure while dragging the mouse doesn't determine the smoothness of the process; it should be blazingly fast, as it can be seen in the above preview

I tried it from scratch, one by one as you said. But it barely drags at all. I played around with it and it still doesn't drag properly. Sure, I don't like giving up, but I don't think I will ever make it work properly.

[Yincognito]

I tried it from scratch, one by one as you said. But it barely drags at all. I played around with it and it still doesn't drag properly. Sure, I don't like giving up, but I don't think I will ever make it work properly.

I can help you do it, by suggesting what to focus on, but you'll do the "work" - well, not that much of a work, just 100 lines of code including 15 empty lines, most of them identical to what you already have. The question is: are you interested in it? If you really don't believe in yourself or don't want this enough, feel free to refuse, but if you have the two, I guarantee success.