knob tooltips

[tulamide]

I had issues with this one. The tooltip didn't show up at all.

Regarding show and hide: Don't panic, you just used the wrong wording. It is "showInParent" not "setShowInParent".

I said that I didn't test it with setViewSize, and it is disappointing that it is programmed rather lazy. But there's still the redraw area way. If that doesn't prevent drawing the whole view, it would be an absolute nonsense prim/method.

In your schematic I saw that each knob view has mouse move tracking on. But that's not needed. On the main view is sufficient (but don't expect much speed up, I still say it's the redrawing that slows things down, not the tracking)

Couldn't find more to help you, the rest is pretty much optimal.

[Nubeat7]

Regarding show and hide: Don't panic, you just used the wrong wording. It is "showInParent" not "setShowInParent".

cool thanks! its written "setShowInParent" in the version history and in the user guide i have (don't know which version this is) !!

In your schematic I saw that each knob view has mouse move tracking on. But that's not needed

it is needed because (don't ask me why) the off bool isn't sent

ok here is the next version, it still suffers that it doesn't show at all sometimes, to fix this just go inside the gui module, move the mouse over a knob, and then it should work on the front panel again (again don't ask me why)

[tulamide]

Bad news: I started the schematic right away, didn't look at the code, but just how the GUI works. Then I resized the main view. Tried again. Got a excessive processing error. One of the knobs shut down. I can't see from the code what could cause it. There's no obvious feedback loop, but maybe there's one caused by 'set value'?

[Nubeat7]

i'll give up on this.. its just a crap schematic, all the things should work fine,
i also found out that some modules inside the synced knobs are displaced, so it seems that fs has troubles with so many synced knobs too, maybe its also the zero at request module which got to many triggers to handle (it handles all knob out triggers and the backward triggers,...)

now the mOver bool didn't work again (whitout changing anything) everytime i open the schematic something is not working as it should, its just frustrating and i don't want to invest that much time, while i'm not needing this anyway.. much luck with it.. whoever is playing around

[Nubeat7]

last try, i did reduced the triggers which are run into the zero at request module inside the knobs.. and thats i think all what is possible... there really should be no excessive processing somewhere..

i think it really is the mousemove methode in combination with moving views around which kills the graphic performance..

anyone with newer versions of fs to test this ?

[tulamide]

Someone please answer here. Really, it would be needed to have a reply from someone with Flowstone > 3.0.6

I can only report that it still stops with execessive processing. Interestingly it is always the same knob (row 3, column 1 in the main view of the top layer; or row 7, column 3 in the gui module, where the knobs are arranged and sync'ed).

This version still doesn't use RedrawA, so until that was tested, you can't say it's the mouse move tracking.

Btw., I bow deep before you, I would never have recovered after such a frustration so quickly, to give it another chance!

[Nubeat7]

This version still doesn't use RedrawA, so until that was tested, you can't say it's the mouse move tracking.

yes but i only redraw the the view where the label is inside, isn't this only a redraw for this view and its area?
sure i can put also an area array after the connector reference but it only should redraw the view where it is connected anyways..

Btw., I bow deep before you, I would never have recovered after such a frustration so quickly, to give it another chance!

it didn'take very long anyways, the frustration lies in the crappy behavior of the schematic like the issue you have that only one knob of 80 syncronised knobs makes troubles while all should work pretty well.., also the random issues that the label is shown normal and then after turning on and off the asio and testplayer a few times it is not working anymore.. i did controll all the trigger behaviours several times, followed each trigger... while i know that there is a much better way to do with the getViewPos which i don't have in 3.06, and no i will not update now just for that and the latest version already needs ages to be finished.. anyways thats another story..

maybe just delete this one knob to test it properly!?

[tulamide]

There might be a misunderstanding of the concept. To make absolutely sure we talk about the same, I made two (artistically impressive ) images:

redrawA_1.png (8.03 KiB) Viewed 20133 times

redrawA_2.png (20.19 KiB) Viewed 20133 times

Of course, that's just the theory. If Flowstone has this programmed badly, it won't result in more CPU time. But that's needed to be tested.

[Nubeat7]

sure but if you watch the schematic you can see that only the small labelview is redrawn there is no redraw of the view where the mousemove happens and the knobs are placed, so i don't need any specified area to redraw..

it would be different if i would move a small label rectangle inside the the same view where the mouse move happens..
while with this technique the redrawing just for the little label rectangle is just a pita because it will leave the old rectangles all the time..

but i tried it anyways.. and i found another annoying thing with this if you touch a knob once, this knob will not react to its mOver anymore, what a mess, so the m over stays on

you can go inside the gui module and touch the knobs again, so they are sending the mOver off again, touched once on the upper levels the same mess again..??

you also can go inside the label where i commented the area for the redraw

in general i think the moving rectangle is a bit better in relation to the moving view, although i'm redrawing the whole view...

[Nubeat7]

btw. it works well when the knos are placed in the main level, but then the info label is under the knobs..

it looks like FS get in trouble when you have to layers overlapping and both have mousemove on, specially when something is drawn on the top layer, this would also explain the random troubles when moving the view from the earlier versions...