First of all, I'd like to say a huge thank you to the large number of people who have invested in the Adroit Granular Synth bundle recently. I hope you are all having fun exploring the possibilities.
I know it's a bit of a challenge getting to grips with the beast, especially when using it with the GS Multiplex, GS MIDI X and GS Breakout expanders. And spending three or four hours reading through the documentation isn't exactly everyone's idea of fun!
Secondly, I want to apologise for the delay in releasing Adroit Custom. I've taken nearly two months out from developing for Voltage Modular for various reasons including my getting close to burnout. It's turned out to be a more challenging project than I anticipated and fighting against bugs for months on end can be demoralizing.
I'm back almost full-time on the project now but still battling against some major efficiency problems with how VM's canvas painting system works.
I'd like to reassure anyone interested that the project has not been abandoned and it will eventually hit the store. Although it could be some time yet as I may need to rewrite all the graphics/UI code yet again to get to a level of efficiency that I'm happy with. Also it will have to go through extended beta testing.
Slow Progress
-
UrbanCyborg
- Posts: 599
- Joined: Mon Nov 15, 2021 9:23 pm
Re: Slow Progress
Chin up, there, Colin. We all go through stages like that in coding. Been there myself the last few months, albeit not on a project on the scale of Adroit Custom. Sometimes you just have to step back and let yourself recharge. I'm sure you'll get there in the end, and we'll all be properly stunned when you finally do get it out there. 
Reid
Reid
Cyberwerks Heavy Industries -- viewforum.php?f=76
Re: Slow Progress
Hi Colin,
glad to see you're writing posts again. Health first! That's the most important thing.
Some years ago I was near to burnout too and I had to change my life.
Meanwhile I switched down to a low speed. That's why I didn't code for month's neither. I cannot work efficiently on several projects at same time.
I hope, you're getting better time after time.
Roland
glad to see you're writing posts again. Health first! That's the most important thing.
Some years ago I was near to burnout too and I had to change my life.
Meanwhile I switched down to a low speed. That's why I didn't code for month's neither. I cannot work efficiently on several projects at same time.
I hope, you're getting better time after time.
Roland
Re: Slow Progress
Thanks for the kind words guys. Part of the issue has been overworking but some of it has been things in my private life. Still, I'm getting back on an even keel now.
My latest technical problem is more weird behaviour with the VoltageCanvas class,
I was getting extremely poor performance on redrawing so did some measurements and my custom component draw times are between about 150 microsec and 3 millisec (depending on the size and complexity of the component) and this is about what I would expect. However, the overall performance was totally out of line with these figures. So I began investigating the Canvas_Painting events that VM dispatches and instead of getting say a few dozen events I'm getting hundreds and the reason it's so slow is that components are being redrawn multiple times.
My data is so bizarre that I'm still trying to analyse what's happening, but basically even simple scenarios produce strange results. For instance a VoltageButton on a VoltageCanvas produces a clip rectange that's way too large when you hover over it. A 40 px by 30 pix button should produce a Canvas_Painting event with a repaint rectangle that's 80 pix by 60 pix when the canvas is in high res mode, but instead it's 320 pix by 200 pix. A strange ratio of * 8 and * 6.6' rather than * 2 and * 2.
If I change the button size to 45 pix by 35 pix the resulting clip rectange is 331 by 211, when it should be 90 by 70.
Things get even stranger when there are multiple canvas objects as this seems to produce huge numbers of spurious redraw events that seem to be Y sensitive. So invalidating a canvas (one that's in addition to the background canvas) when a VoltageButton is pressed whose Y range doesn't overlap is OK but if it overlaps in Y then six repaint events are generated. When I say overlaps in Y in this context I mean it only overlaps in Y. They don't visually overlap becasue they don't also overlap in X. Très étrange.
The plan is to strip things down to an absolute minimum so I can discount any bug in my code but it's already pretty simple. And some of the really whacky stuff appears to be interactions between multiple canvas objects.
Once I have a better idea of what on earth is going on, I'll post something in the Module Designer sub forum and raise a ticket with CA if, as I suspect, it's VoltageCanvas that's messing up.
My latest technical problem is more weird behaviour with the VoltageCanvas class,
I was getting extremely poor performance on redrawing so did some measurements and my custom component draw times are between about 150 microsec and 3 millisec (depending on the size and complexity of the component) and this is about what I would expect. However, the overall performance was totally out of line with these figures. So I began investigating the Canvas_Painting events that VM dispatches and instead of getting say a few dozen events I'm getting hundreds and the reason it's so slow is that components are being redrawn multiple times.
My data is so bizarre that I'm still trying to analyse what's happening, but basically even simple scenarios produce strange results. For instance a VoltageButton on a VoltageCanvas produces a clip rectange that's way too large when you hover over it. A 40 px by 30 pix button should produce a Canvas_Painting event with a repaint rectangle that's 80 pix by 60 pix when the canvas is in high res mode, but instead it's 320 pix by 200 pix. A strange ratio of * 8 and * 6.6' rather than * 2 and * 2.
If I change the button size to 45 pix by 35 pix the resulting clip rectange is 331 by 211, when it should be 90 by 70.
Things get even stranger when there are multiple canvas objects as this seems to produce huge numbers of spurious redraw events that seem to be Y sensitive. So invalidating a canvas (one that's in addition to the background canvas) when a VoltageButton is pressed whose Y range doesn't overlap is OK but if it overlaps in Y then six repaint events are generated. When I say overlaps in Y in this context I mean it only overlaps in Y. They don't visually overlap becasue they don't also overlap in X. Très étrange.
The plan is to strip things down to an absolute minimum so I can discount any bug in my code but it's already pretty simple. And some of the really whacky stuff appears to be interactions between multiple canvas objects.
Once I have a better idea of what on earth is going on, I'll post something in the Module Designer sub forum and raise a ticket with CA if, as I suspect, it's VoltageCanvas that's messing up.
Re: Slow Progress
Thanks for the explanation of some of the issues you are facing. I have found this https://docs.cherryaudio.com/voltage-mo ... r/canvases. Thanks for helping me to find areas of VM I have had on the back burner to start exploring. At your convenience, please feel free to share more of the saga.
Re: Slow Progress
I've figured out why the Canvas_Painting event's clip/boundary rectangle is wrong.
The AWT Rectangle constructor expects x, y, width, height parameters but instead of supplying width and height CA must be using the boundary coordinates.
So the rectangle's width is set to x + width instead of width and the rectangle's height is y + height instead of height.
Then odd numbered coordinates and dimensions cause the numbers to be fudged slightly by doubling and rounding when the canvas is in high res mode.
So that's at least one mystery solved.
I'll raise a ticket with CA and then post something on the Module Designer sub forum when I get a response.
The AWT Rectangle constructor expects x, y, width, height parameters but instead of supplying width and height CA must be using the boundary coordinates.
So the rectangle's width is set to x + width instead of width and the rectangle's height is y + height instead of height.
Then odd numbered coordinates and dimensions cause the numbers to be fudged slightly by doubling and rounding when the canvas is in high res mode.
So that's at least one mystery solved.
I'll raise a ticket with CA and then post something on the Module Designer sub forum when I get a response.
Re: Slow Progress
I think I've finally unpicked the bizarre Canvas_Painting data I've been getting.
As I mentioned above the width and height of the clip rectangle incorrectly have the x and y values added but if I ignore this bug by subtracting these values and use even coordinates and dimensions to overcome the doubling and rounding artifacts, I'm left with data that's easier to analyse.
Things are OK providing that there's no Y overlap between components. But my test case does include Y overlap, as will most real-world scenarios.
So I have a VoltageCanvas that covers the entire module background, a VoltageButton and a second VoltageCanvas object to the right of the button that I use to render a custom knob. A left click on the button calls Invalidate() on the knob canvas.
The top of the knob canvas is above the top of the button and the bottom of the knob canvas is below the bottom of the button. Although they don't visually overlap as they are well separated horizontally.
(Edited to add the following image to make things a little easier to understand. Note this uses a test version of my custom knob component but exactly the same result happens if a bare VoltageCanvas is used instead.)
Now on first draw everything is OK.
When I move the mouse cursor over the button I get a Canvas_Painting event to redraw the background as expected because the hover state and off state might occupy different regions. As mentioned already the width and height are wrong but let's ignore this.
When I click on the button the first time the Canvas_Painting event incorrectly says repaint the entire module background rather than just the button's region.
Then as expected I get another event saying repaint the knob canvas.
Then, on releasing the mouse button, I get another event saying repaint the background behind the button. This is expected as it enables the background to be repaired if the button hover and on states cover different areas.
But then if I click the button a second (and subsequent) time things get interesting! As a quick overview VM tells me to repaint the background, then the knob, then the background, the background again, the knob again, the background again, the knob again then the background again. The clip/repaint rectangle is different each time though.
The first background repaint is for the area behind the part of the knob above the button.
The first knob repaint is for the part of the knob above the button.
The second background repaint is for the button changing to on state.
The third background repaint is for the area behind the knob that overlaps the Y region of the button.
The second knob repaint is for the part of the knob that overlaps the Y region of the button.
The fourth background repaint is for the area behind the knob below the Y region of the button.
The third knob repaint is for the part of the knob below the Y region of the button.
The fifth background repaint is repairing the background ready for the off state of the button.
So there is some twisted logic to this avalanche of Canvas_Painting events and the end result is a correctly redrawn module. So it's not at all obvious that this chaos is happening until you investigate in depth.
Drawing operations can of course be split into parts but it's generally inefficient. At the very least it requires accurate clip regions and top-notch algorithms to avoid excessive waste.
I suspect this all means that Voltage Modular might perform much better if the painting system was revised. Although the intrinsic VoltageComponent rendering might not use individual canvases in which case it wouldn't make a huge difference.
My focus is however on Adroit Custom and because it animates its UI during morphing and currently uses a canvas per control I can't ignore huge waste of CPU and GPU resources so am now looking at bypassing as much of the canvas repainting system as is possible by using just one canvas that covers the entire module.
As I mentioned above the width and height of the clip rectangle incorrectly have the x and y values added but if I ignore this bug by subtracting these values and use even coordinates and dimensions to overcome the doubling and rounding artifacts, I'm left with data that's easier to analyse.
Things are OK providing that there's no Y overlap between components. But my test case does include Y overlap, as will most real-world scenarios.
So I have a VoltageCanvas that covers the entire module background, a VoltageButton and a second VoltageCanvas object to the right of the button that I use to render a custom knob. A left click on the button calls Invalidate() on the knob canvas.
The top of the knob canvas is above the top of the button and the bottom of the knob canvas is below the bottom of the button. Although they don't visually overlap as they are well separated horizontally.
(Edited to add the following image to make things a little easier to understand. Note this uses a test version of my custom knob component but exactly the same result happens if a bare VoltageCanvas is used instead.)
- testCase.png (12.34 KiB) Viewed 4996 times
Now on first draw everything is OK.
When I move the mouse cursor over the button I get a Canvas_Painting event to redraw the background as expected because the hover state and off state might occupy different regions. As mentioned already the width and height are wrong but let's ignore this.
When I click on the button the first time the Canvas_Painting event incorrectly says repaint the entire module background rather than just the button's region.
Then as expected I get another event saying repaint the knob canvas.
Then, on releasing the mouse button, I get another event saying repaint the background behind the button. This is expected as it enables the background to be repaired if the button hover and on states cover different areas.
But then if I click the button a second (and subsequent) time things get interesting! As a quick overview VM tells me to repaint the background, then the knob, then the background, the background again, the knob again, the background again, the knob again then the background again. The clip/repaint rectangle is different each time though.
The first background repaint is for the area behind the part of the knob above the button.
The first knob repaint is for the part of the knob above the button.
The second background repaint is for the button changing to on state.
The third background repaint is for the area behind the knob that overlaps the Y region of the button.
The second knob repaint is for the part of the knob that overlaps the Y region of the button.
The fourth background repaint is for the area behind the knob below the Y region of the button.
The third knob repaint is for the part of the knob below the Y region of the button.
The fifth background repaint is repairing the background ready for the off state of the button.
So there is some twisted logic to this avalanche of Canvas_Painting events and the end result is a correctly redrawn module. So it's not at all obvious that this chaos is happening until you investigate in depth.
Drawing operations can of course be split into parts but it's generally inefficient. At the very least it requires accurate clip regions and top-notch algorithms to avoid excessive waste.
I suspect this all means that Voltage Modular might perform much better if the painting system was revised. Although the intrinsic VoltageComponent rendering might not use individual canvases in which case it wouldn't make a huge difference.
My focus is however on Adroit Custom and because it animates its UI during morphing and currently uses a canvas per control I can't ignore huge waste of CPU and GPU resources so am now looking at bypassing as much of the canvas repainting system as is possible by using just one canvas that covers the entire module.