I’m seeing the same behaviour here. Odd. I’ll try to get that sorted.
OSX Dec-11 build beta testing
Just to be sure, that build should be tested for fixing spaces between imports? It did not work on GUI test when adding a space between the two imports.
The build In the zip? No that’s from earlier today. I’m just waiting for someone to verify that it actually contains some kind of binary data that will actually run. For the next month or so I’l not have access to an OSX machine, so I’m trying to get Cabbage building remotely. If that app runs at all then we should be good.
Oh, I see… in that case, awesome. It was only the heavy build, but imagine that’s just a technicality.
I was able to load up the GUI test and it ran, as long as it wasn’t spaced in the imports!
Sweet. In that case I should have a more recent build for you later. But I won’t be able to look into the latched button till tomorrow though. you’ll have to just accept the spaces fix for now!
p.s. looks like there is quite a backlog on OSX builds with TravisCI at the moment. So it might take a while before this latest commit is cooked…
No worries… honestly I had taken a few days off myself 
Now I have plenty of importable widget groups to get ready for when we can go crazy with multiples!
Question, what are your thoughts on multiple groups of similar widgets in a single import? Basically two separately named cabbagecode sections that might be related enough to warrant including together. For a half cooked example, that’s tested to NOT work:
<namespace>collapse</namespace> <name>StereoCollapse</name> <cabbagecode> image bounds(0, 0, 100, 18) colour(0, 0, 0, 0), identchannel("stereobox"), { button bounds(0, 0, 20, 18), channel("mono-st"), radiogroup(101),value(1), text("St", "St"), popuptext("Stereo Input"), identchannel("mono-st-c"), $RADIO_BUTTON button bounds(20, 0, 20, 18), channel("mono-inv"), radiogroup(101), text("Inv", "Inv"), popuptext("Inverted Stereo Input"), identchannel("mono-inv-c"), $RADIO_BUTTON button bounds(40, 0, 20, 18), channel("mono-lr"), radiogroup(101), text("LR", "LR"), popuptext("Mono Input: L+R"), identchannel("mono-lr-c"), $RADIO_BUTTON_2 button bounds(60, 0, 20, 18), channel("mono-l"), radiogroup(101), text("L", "L"), popuptext("Mono Input: L"), identchannel("mono-l-c"), $RADIO_BUTTON_2 button bounds(80, 0, 20, 18), channel("mono-r"), radiogroup(101), text("R", "R"), popuptext("Mono Input: R"), identchannel("mono-r-c"), $RADIO_BUTTON_2 } </cabbagecode> <name>MonoCollapse</name> <cabbagecode> image bounds(0, 0, 100, 18) colour(0, 0, 0, 0), identchannel("monobox"), { button bounds(40, 0, 20, 18), channel("mono-lr"), radiogroup(101), text("LR", "LR"), popuptext("Mono Input: L+R"), identchannel("mono-lr-c"), $RADIO_BUTTON_2 button bounds(60, 0, 20, 18), channel("mono-l"), radiogroup(101), text("L", "L"), popuptext("Mono Input: L"), identchannel("mono-l-c"), $RADIO_BUTTON_2 button bounds(80, 0, 20, 18), channel("mono-r"), radiogroup(101), text("R", "R"), popuptext("Mono Input: R"), identchannel("mono-r-c"), $RADIO_BUTTON_2 } </cabbagecode>
I think it could be useful, especially in certain situations such as this one, where the same UDO can be used just with fewer button inputs. But if it presents difficulties implementing, it’s definitely not a game breaking feature for me.
I don’t have an issue per say with the idea but I think it’s probably best to give the current setup a good test drive first. I’m sure we’ll go through a few iterations before we start looking at extending it.
That latest build isn’t quite there yet so it’ll be tomorrow before I have something for you. Apologies for this, but it’s the best we can do unless a MacBook magically appears at the end of my bed on Christmas morning!
The latest build is now available through the beta pages. The zip file doesn’t contain Csound.
Awesome! Immediate feedback:
Spaces on form imports is fixed.
Strangely I can’t get “stay on top” to stay enabled across launches on this version now, opposite behavior of what it was, with stuck on before.
Cool. Like I said, it’s not very high priority for me… but I think I have a few cases of widgets like this where the same UDO is used for one or two different widget configurations.
I’ve got 3 different plants working so far for some of my most common UI elements. One for the OL leds, one for stereo/mono collapse buttons, and one for buttons to trigger test audio. The only problems so far have all been chalked up to user error.
I think the biggest next step for me will be once we can import multiple xml plants. All three of these ones I have appear in almost every instrument, so they’ll be good for testing multiple imports once you feel ready for it.
Are there any other specific aspects of imported plants we should be focusing on testing and putting through the wringer for you?
Also, random q: where does the help text in the xml plant definition get used/displayed, or does it?
Did something change in the init cycle? I’m back to getting table errors in instruments that depend on the pre-initialized tables… for example analog. I’ll send you a current (but still extremely unfinished) version to run for testing.
It ran fine in the previous build (12/11 i think?)
It doesn’t get used yet.
That’s already supported is it not? I may not have said…
I’ll check here but I can’t think of anything that might cause that problem to return…
So it is! And no, I hadn’t seen that mentioned on a thread I was on or that I saw… I think perhaps the space between imports issue also might have made me think multiples wasn’t working, even tho it was actually something else. Either way, it’s (mostly) working great… I have three widgets imported and working with their respective included UDOs.
However I am seeing weirdness in size and position of some imported widgets on the new version. Stepping back resolves them. These are two screenshots made comparing 12-11 build to 12-19, I made the OL leds white to make the issue more visible:
That could still be entirely my fault, but nothing in the code changed at all between those two shots. Any suggestions? This was with 2 plants imported at the time… but testing with one seemed to have the same result, and testing with only one of the OL leds instead of two also had the same result.
Can you forward me that GUITest file where you try to import more than one plant and I’ll take a look?
Looks like a problem with the spaces before you declare the image widget for that plant. I thought I had this sorted. Must have crept back in somehow. Should be a quick fix.
[edit] I’m queuing up a new OSX build that fixes this. Could be about an hour or so before it’s cooked. I’ll let you know.
Didn’t get to test extensively yet, but it passed the test for the multiple widget issue… so far so good.
I’ll try to test a few real instruments more before bed, but it might have to wait until tomorrow to really get a better idea.
Freshened up with today’s new beta from the Seaboard thread and tried a bunch of instruments. So far everything’s looking great!
But just so it doesn’t get lost in the mix… I’m still having the latch issues that are apparent with the imported L and R test buttons. Instruments that still use native (non-imported) widgets unlatch as expected.
1 Like
I’ll be honest, it nearly did get lost in the mix! I’ll take a look tomorrow.
Cool, thanks! I thought it might amongst the other more important discussions. It’s not slowing me down, but I’d imagine it will be a problem for someone eventually.
Fixed in git. I’ll run off a new OSX build now and upload a little later on today.
[edit] new build available…
1 Like
Looks like the latched issue can be checked off the list, thanks!