Cabbage Logo
Back to Cabbage Site

OSX Dec-11 build beta testing

Everything seems to be working great for the most part but nslider fails for me and numberbox still works fine. Not a big deal, I just won’t convert my widgets yet… but that makes me wonder if the c2l build might be running behind again :wink:

I’m having an odd macro issue that’s been present for a few versions, I’m not sure when it crept in. On the Analog example, the SHAPE_MENU macro doesn’t fully expand, it cuts off the last item (Noise). If I manually put what that macro should be in the combobox line it works fine. It also doesn’t seem to be a problem of macro length, since my filter comboboxes use a much longer macro for their items in FILT_MENU. Ignore that the shapes are selecting wrong on your version, my concern is just getting the right items to show in the combobox. :innocent:

Hopefully we can start focusing on imported widget groups again… it looks like macros took a step backwards there, but I haven’t had a chance to fully dive in yet. More to come on that later tonight or tomorrow once I’ve tested some more.

Honestly tho, this is one of the best builds for me yet. The init issues I was having preventing my “bypass” function are gone, instruments work on the first running from sublime, the window titles are back correct again, and gentables even appear to allow changing functions now (awesome work!).

I’m pretty sure the examples you sent me are more or less out of date now or? Would you mind sending them on again. I will try the SHAPE_MENU macro and see what’s going on.

They are, but I try to continue testing against those older versions too since most of my changes have been behind the scenes csound stuff, keeps it easier so I don’t have to send you fresh stuff every few days. I’m still piecing a few of these together. I don’t mind freshening up a zip for you tho.

That said, I tested the SHAPE_MENU macro problem with the version of analog that you have, the issue was still present for me.

After more testing, it looks like I was both wrong and mistaken :wink: A simple typo (extra $ in an #ifdef) in the imported widget file broke everything! Macros in the csound code section seem to be working correctly!

Macros in the cabbage section however don’t seem to expand from a previously imported file (like the way I am doing the style includes). This had worked on one of the previous betas tho, is it still something that can be done, or was this creating some other issues elsewhere?

I’m also having some issues addressing imported widgets via identchannel. Should this be possible? If so I may have made a stupid mistake there too.

Do you have an example I can try?

Should work fine but remember that Cabbage will prepend the unique channel string passed when importing to the all imported widget’s channel and identchannel names. Send me on a broken sample if you need more clarification.

It looks like all of my problems are my own. I assumed there was a “-” between the prepended import name and the actual original widget’s name. There shouldn’t be, so I don’t know why I thought there was… I’ve even been trying to move away from doing that in my own UDOs too.

As for widget colors, I had flipped the order of the imports when trouble shooting last week. Importing the color first made all of the difference.

I’m going to test a little more, but I think I figured it all out now :flushed:

Once I feel like it’s worth sending, I’ll freshen up some files for you to see.

By the way, minor thing I noticed… disabling the stay on top toggle for c2l window doesn’t carry over between launches. Each new time I run an instrument it stays on top. I’m guessing this isn’t the intended behavior :wink:

Actually, it might have to be. The thing about Cabbage Lite is that it doesn’t save any settings, because it’s well, lite! I don’t really want to be creating user property files for this, but I guess it might be unavoidable. Leave it with me.

It looks like spacing is important when working with the form imports:

Imports ok:

form caption("GUI Test") size(380,294), pluginID("tgui"), import("includes/tg_colors.inc.csd","plants/test.xml"), $ROOT

Fails to import:

form caption(“GUI Test”) size(380,294), pluginID(“tgui”), import(“includes/tg_colors.inc.csd”, “plants/test.xml”), $ROOT

In case that text example is not immediately clear… there’s a space after the comma for tg_colors that causes the failure to import test test plant xml.

Doesn’t it save sound card/midi info? I know at the very least, the first time I launched I had to safely turn on my mic to avoid feedback, I imagine that got stored somewhere.

That’s true. I had forgotten I was doing that :wink: I’ll check out those issues when I get a moment.

No worries or rush at all… I am working on my second set of widgets for import. I was trying to figure out what was going on before I sent any examples… and I think I’ve got it figured out. First I ran into that spacing issue which slowed me down a bit.

But now I’m running into some whole new location issues with imports. It looks like position is only kept for the first widget of the group… this didn’t affect me before since my first widget was an image “container”, so only it’s position mattered anyway.

I’m writing some comments in the code for you now, and I’ll send it over in just a few, but I think it’s straight forward enough.

edit: also, latched isn’t working on the buttons I imported? Odd because they were copy pasted. Anyways, you’ll see in a few.

The import mechanism is specifically for plants, so… the first widget should always be an image or groupbox?

I’ve fixed the spaces issue. I’m always trying to figure out an automated build for OSX. Apropos, would you mind trying the Cabbage.app file in this zip? You may have to dig for the app but it should be in there somewhere.

Latched appear to be broken, I’l take a look.

[edit] actually, it’s working fine. A quick look at the docs and I realised I was using it wrong. latched(1) is the default behaviour.

I think you’ve even already said this… for some reason it just didn’t click. That’s actually exactly what I thought seemed to be happening and was thinking I might just work around it with an image.

I just touched on this in the fresh examples… tho perhaps the behavior issue is a byproduct of not being in a plant when imported? I’ll try that first. Anyways… it’s 4 buttons, all with a specific latched attribute, 2 are 0 and 2 are 1. But all behave as latched.

Sure, right after testing those buttons!
edit: putting them in an image did not fix latched behavior.

I’m seeing the same behaviour here. Odd. I’ll try to get that sorted.

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 :sunglasses: 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.