OK so hopefully we now have enough knowledge to efficiently and safely...
* Interleave control value changes from mouse/keyboard input with sample-rate control from internal automation as well as CV and MIDI CC input
* Calculate cubic spline or sigmoid interpolation at sample rate on control values for scene-based morphing automation under manual, clocked or CV control
* Output control value changes to CV at sample rate with optional smoothing e.g. for de-clicking purposes
* Output MIDI CC at a tunable rate when change exceeds the CC resolution threshold
* Update remote controlled controls at a tunable rate when change exceeds a tunable threshold
* Update the local UI at 20 Hz
* Perform live skinning
* Make everything (except fonts) persist via the .voltagepreset file
Threading nightmares
Re: Threading nightmares
I know this thread is pretty long, has veered all over the place (my bad) and is getting to the point where I might just be talking to myself. But any dev seriously interested in pushing VM and building their own UI components to enable thread-safe automation or custom behaviour will probably still be reading...
I'm now much closer to production guality code and looking at the fancier aspects - such as blurred semi-transparent shadows, adding LEDs to slider caps (like the Alpha 20 mm you see in a lot of Eurorack) - that kind of thing.
Aestherics are important, so I'm currently doing a comparison between the stock slider and mine. The stock slider strobes far less than mine when moved very quickly. Not a problem much of the time but the strobing looks ugly when the sliders occupy almost the full height of a module and zoom is higher than 100%. Obviously I expect strobing when doing high-speed automation but I'm talking about moving the slider with the mouse.
This is when doing the Invalidate() call via a timer update as we've been discussing recently. Unfortunately increasing the timer rate considerably doesn't do much to help. However if I call Invalidate() directly inside my set value method (in other words from inside the mouse move event handler) then the strobing looks the same as the stock slider. Which leads me to believe that the stock slider's is indeed calling Invalidate() / AWT repaint() directly on a value change.
My guess is that the problem might be caused by something like asynchronous "beating" between the AWT event dispatcher thread and the timer thread. I've not actually tested if there's a floor to VM's timer delay but telling the thing to run at 1 kHz doesn't help and obviously a lock would be more efficient that a 1 KHz timer thread anyway!
So after all the discussion and experimentation I might actually end up going back to something closer to my original code unless someone can think of a magic way to reduce the strobing effect.
I'm now much closer to production guality code and looking at the fancier aspects - such as blurred semi-transparent shadows, adding LEDs to slider caps (like the Alpha 20 mm you see in a lot of Eurorack) - that kind of thing.
- IlluminatedSlider.png (271.72 KiB) Viewed 6538 times
Aestherics are important, so I'm currently doing a comparison between the stock slider and mine. The stock slider strobes far less than mine when moved very quickly. Not a problem much of the time but the strobing looks ugly when the sliders occupy almost the full height of a module and zoom is higher than 100%. Obviously I expect strobing when doing high-speed automation but I'm talking about moving the slider with the mouse.
This is when doing the Invalidate() call via a timer update as we've been discussing recently. Unfortunately increasing the timer rate considerably doesn't do much to help. However if I call Invalidate() directly inside my set value method (in other words from inside the mouse move event handler) then the strobing looks the same as the stock slider. Which leads me to believe that the stock slider's is indeed calling Invalidate() / AWT repaint() directly on a value change.
My guess is that the problem might be caused by something like asynchronous "beating" between the AWT event dispatcher thread and the timer thread. I've not actually tested if there's a floor to VM's timer delay but telling the thing to run at 1 kHz doesn't help and obviously a lock would be more efficient that a 1 KHz timer thread anyway!
So after all the discussion and experimentation I might actually end up going back to something closer to my original code unless someone can think of a magic way to reduce the strobing effect.
Re: Threading nightmares
I can only speak for myself, but I have been reading and learning on a daily basis (when there are posts). Thanks for taking the time, Colin and everyone.
Re: Threading nightmares
Even if that IS the case (unlikely), I believe it's immensely important that the discussion has taken place and that it is recorded for posterity!
______________________
Dome Music Technologies
Dome Music Technologies
Re: Threading nightmares
Cheers guys. There have been some great contributions and hopefully this thread (no pun intended) will provide some useful pointers about thread-safety going forward. Something that's so important to making VM more reliable as well as more powerful.
The Module Designer part of the forum really is a valuable resource for us all.
I know I keep going a little off-topic but for me this safety discussion has been in the context of my current project. So off-topic again...
While working on a substitute for VoltageKnob I've been looking at affine transforms in Java for doing the rotation. And while doing so I came across this gif on Wiki that I think is wonderful as an aide-memoire for working in radians...
It's by Lucas Vieira and is in the public domain.
The Module Designer part of the forum really is a valuable resource for us all.
I know I keep going a little off-topic but for me this safety discussion has been in the context of my current project. So off-topic again...
While working on a substitute for VoltageKnob I've been looking at affine transforms in Java for doing the rotation. And while doing so I came across this gif on Wiki that I think is wonderful as an aide-memoire for working in radians...
It's by Lucas Vieira and is in the public domain.
- Circle_radians.gif (104.51 KiB) Viewed 6498 times
-
UrbanCyborg
- Posts: 599
- Joined: Mon Nov 15, 2021 9:23 pm
Re: Threading nightmares
Don't worry about going off on a tangent, Colin. I've been reading along assiduously. Never had anything new to contribute, so I kept mum, but this material is very thought provoking.
Reid
Reid
Cyberwerks Heavy Industries -- viewforum.php?f=76
Re: Threading nightmares
OK, given that at least a handful of people are still interested, I'll continue. It would probably make more sense to start a new thread with a title such as "Building custom UI components that happen to be thread-safe" but never mind.
I initially thought I'd make a quick fix to the thread-safety issue and get back to beta testing and preparing Adroit Custom for launch - as I'm already way over time-budget. But I've fallen down a rabbit hole. I should have done this work a year or two ago as I've wasted a lot of time trying to bend CA/JUCE code to do my bidding and often failed.
Anyway, as I delve deeper into AWT (or at least as much as CA allows one to access) the things I've learnt today are...
If you are using affine transformations rendering hints can make a huge difference.
Most of you no doubt set KEY_ANTIALIASING to VALUE_ANTIALIAS_ON when rendering but this doesn't affect affine transforms. What you need to do is set KEY_INTERPOLATION to VALUE_INTERPOLATION_BICUBIC and KEY_RENDERING to VALUE_RENDER_QUALITY.
The highly-zoomed images below show the effect of a rotation on a simple test knob with and without these rendering hints...
Other things...
javax.imageio.ImageIO.read() can deliver BufferedImages in all manner of strange buffer formats. It's best to copy into a TYPE_INT_ARGB or TYPE_INT_RGB format after reading otherwise you might end up with poor performance.
Graphics dispose() isn't just about resource allocation management. It is part of the mechanism that helps sync bufferedImages in main memory with mirrored copies kept in VRAM. Always call dispose() and start with a fresh graphical context otherwise you might accidentally turn off hardware acceleration especially when doing anything fancy.
I initially thought I'd make a quick fix to the thread-safety issue and get back to beta testing and preparing Adroit Custom for launch - as I'm already way over time-budget. But I've fallen down a rabbit hole. I should have done this work a year or two ago as I've wasted a lot of time trying to bend CA/JUCE code to do my bidding and often failed.
Anyway, as I delve deeper into AWT (or at least as much as CA allows one to access) the things I've learnt today are...
If you are using affine transformations rendering hints can make a huge difference.
Most of you no doubt set KEY_ANTIALIASING to VALUE_ANTIALIAS_ON when rendering but this doesn't affect affine transforms. What you need to do is set KEY_INTERPOLATION to VALUE_INTERPOLATION_BICUBIC and KEY_RENDERING to VALUE_RENDER_QUALITY.
The highly-zoomed images below show the effect of a rotation on a simple test knob with and without these rendering hints...
- WhatADifferenceAHintMakes.png (291.25 KiB) Viewed 6470 times
javax.imageio.ImageIO.read() can deliver BufferedImages in all manner of strange buffer formats. It's best to copy into a TYPE_INT_ARGB or TYPE_INT_RGB format after reading otherwise you might end up with poor performance.
Graphics dispose() isn't just about resource allocation management. It is part of the mechanism that helps sync bufferedImages in main memory with mirrored copies kept in VRAM. Always call dispose() and start with a fresh graphical context otherwise you might accidentally turn off hardware acceleration especially when doing anything fancy.
Re: Threading nightmares
Well stated! I agree!!UrbanCyborg wrote: ↑Tue Aug 01, 2023 10:07 am Don't worry about going off on a tangent, Colin. I've been reading along assiduously. Never had anything new to contribute, so I kept mum, but this material is very thought provoking.
Re: Threading nightmares
I second thatSteve W wrote: ↑Tue Aug 01, 2023 4:26 pmWell stated! I agree!!UrbanCyborg wrote: ↑Tue Aug 01, 2023 10:07 am Don't worry about going off on a tangent, Colin. I've been reading along assiduously. Never had anything new to contribute, so I kept mum, but this material is very thought provoking.
