I was messing around with the svgElement() identifier gain today and came up with some more UDOs. The rotary slider one works in more or less the same way as the custom range slider example I posted a few days ago. I also wrote a simple button UDO and a simple UDO to convert 3 values into an rgb string. It’s all here.
svgInterface.csd (5.0 KB)
Btw, this instrument depends on a very recent changes which add support for mouseInteractions() to label widgets…
The sliders work for me, the buttons do not… I’m using 2.7.14 on Mac OS 10.13.6
Did you download the latest build from Azure from a few hours ago?
I guess I just need to understand when you change the version numbers. The one I had was 2.7.14, and the one I just downloaded has the same.
And yes, the buttons work now! I am curious about the behavior of the sliders. When the marker is pointing straight up, the black outlines on the sliders disappear, but are scaled to their largest thickness with the slider at 3 and 9 o’clock positions. I am not that adept at understanding svg, yet, but is that supposed to happen? Or is that a sideeffect?
Hmm, this might be a side-effect of the JUCE SVG parser. I’ll have to check with a browser to see if this also happens there. If not, we can assume it’s another limitation with the JUCE SVG parser. I may think about using a different SVG parser library if there is enough interest.
[edit] I’m not seeing this issue at all here when I test? The stroke width and other attributes don’t change at all as I move the sliders 
Sorry, I forgot to address this. I don’t always bump before committing. I do try to bump version numbers whenever any kind of major things get added, or anything that is likely to cause problems when people export older instruments. So there may be times when you get a few iterations of a single version number. Not best practice, but I’m getting better at it!
Hey Rory, would it be possible to have the build date/time automatically “encoded” into the build and shown as part of the about window, sort of similar to how csound tells us it’s build date next to the version?
I don’t know how tough the automated part of that would be, but it seems like a good middle ground for not having to bump versions for every little fix, while also allowing identification down to the specific run. 
Yeah, this would definitely be a good idea. I’m just not sure how best to implement. Maybe the best would be to bump the minor version number on every commit? I think this would be the easiest.
@mjmogo @t_grey I’ve written a simple script now that will bump the minor number on each commit and give the version number in the commit tag. So when you go to the Azure builds you now see something like this:
This will match the number in the about box and should from now on be unique for all builds. Technically I should probably be using an extra point, i.e., 2.7.16.1 but AUs only support 3 number versions.
@rorywalsh While on the subject of identifying versions, I just noticed CabbageLite is reporting a much older version, but behaving as if it’s current…
Hmm, I’m not sure I ever had that right. I’ll update later.
Cool, not at all a worry or priority… Just something I noticed. I’m probably one of the few if any of the Lite users. 
More likely the only user 
I’ve updated this now so that it matches the main IDE version number.
