Hello ;
I have a question, I attach two screenshots of the nodes window. I use SuperCollider on a Mac M1 machine with a 31-inch HP monitor. When I open the nodes window and drag it onto the monitor screen, the content does not come out completely, it is as if it overflows the size of the window. However, after a while, the window resizes and seems to return to its expected appearance. Does anyone know why this happens, and how to fix it?
Greetings to the entire community
I think this is defined in plotTreeView, ServerPlusGui.sc.
I tried to understand how it worked then gave up. Thereâs recursion, node messaging and thread. So thereâs âwaitingâ involved here, hence the reason why it doesnât update directly (I think). On my computer, resizing this view takes a noticeable amount of time.
I do not understand why every drawFunc call redefines a new drawFunc function every time.
What strikes me is that the same is not true for the âFreqScopeâ and âStethscopeâ windows.
These are different mechanisms. The scope windows use the shared memory interface to draw the display (in the language) directly from buffer memory (in the server). This is very fast.
The node tree has to retrieve complex, structured data from the server using OSC messages. IIRC multiple queries are needed. Itâs necessary to leave time for all the queries to come back before performing the next set of queries. So the update speed is slower. If you resize the window, it wonât redraw until the next update cycle. So if the period during which the window looks wrong is less than a second, Iâd say just let it go.
How long is âa whileâ? (Long enough to grab a screenshot, which would be too long.)
It may be a weird interaction between Qt and displays having different resolutions. For that, I donât have much of an idea.
hjh
Actually, I think a resize event will still call the drawFunc. It wonât query nodes, however. At the moment, resizing shouldnât (and couldnât) update nodes, but could adapt GUI to the resize event. It was just not designed that way.
This question got my interest and Iâve tried updating the function. Iâll propose a pull request once this is done.
How did you get this? I donât understand ?
I rewrote the widget after seeing your message.
When I though I was getting finished, I just figured out that, internally, synths controls are available, but current implementation doesnât display them. So I used some black magic to make them appear.
Thatâs awesome. I like it. The only thing Iâm not sure of is the rate at which this data can be refreshed.
Thatâs something Iâm uncomfortable with, but interested in.
One of the downside of my rework is that I think it takes more time calculating everything (although I think this is just a few cpu cycles per node, but this can add up with complex synth graphs). Iâm not able to calculate such things precisely.
If someone knows something about this: I moved every variable/function declaration outside of the recurrent function call, so that it doesnât have to allocate memory or compose complex structures within the loop itself. It made sense to me, but maybe the interpreter or the compiler already take care of that? Or something else?
Since it takes some time for the server to be notified and respond, there will always be latency between whatâs displayed and whatâs heard. But this doesnât affect refresh rate directly.
It is easy to test anyway, as the function takes the refresh interval as argument.
As a side note, something I didnât change from the current implementation: every plotTreeView refreshes all plotTreeView when it ticks. So itâs implicitly supposed to be instantiated only once at a time.
It doesnât unfortunately!
