Cabbage Logo
Back to Cabbage Site

Cabbage2lite pretesting: 2

#6

Thanks for that, it’s fixed too. There’s no longer any issues with commas touching macro.[quote=“t_grey, post:4, topic:809”]
Very odd that the amprange is working for you.
[/quote]

Could be the OSX build. I’ll check tomorrow. [quote=“t_grey, post:4, topic:809”]
That’s what I figured, and that’s perfectly fine… what I don’t understand tho, is if I call your example with a different namespace, it no longer functions. Is this intentional? I guess I just don’t really understand what or why
[/quote]

Just enforcing good habits! Actually, namespaces do work when calling plants, but not UDOs. [quote=“t_grey, post:4, topic:809”]
I agree, the question I was posing I guess is what do you consider a better/safer distribution method… having c2lite refer to the full c2’s examples, or packaging it with it’s own.
[/quote]

I think I can just bundle them in the OSX build. They are not so large in size. On Windows and Linux they are packaged differently. [quote=“t_grey, post:4, topic:809”]
edit: In case it matters, I still have to go back to csound 6.07 for testing. Newer versions (up to .09) gave me issues with the string parsing at init and such, so nothing works properly. I don’t know if it will work properly in .10 or not.
[/quote]

I’ll press Victor for an updated build…

#7

I looked into this, and while making those changes I mentioned I also added support for imported plants to be nest within plants. But honestly it seems like something that will cause more trouble than it’s worth (I mean trouble for me or any future Cabbage developers!). It’s just about Ok for imported plants, but for normal plants I don’t see the point. I really don’t like the look of this:

image bounds(0, 0, 300, 300)
{
    image bounds(10, 10, 200, 200)
    {
    	image bounds(10, 10, 100, 100)
    	{
    	        label bounds(5,5,100,15), text("Hell no!")
    	        label bounds(5,45,100,15), text("This is madness!!")
	}

	label bounds(5,45,100,15), text("Did I fall asleep and wake up in lisp!!")
    }
}

I’ll push the nested imported plant mechanism a little further and see what kinds of pain and anguish I can cause myself! If you don’t here from in a while it’ll be because I’ll be rocking myself against a wall in the corner of my studio repeating the phrase ‘all plants and no play make Rory go something something’…

#8

New version available. Import plants can be plants, but they won’t resize properly when resizing in the GUI editor. I think this is a restriction that will have to remain. But you can still move and group them. Other issues should also be fixed. I still can’t recreate youramprange() bug.

#9

Awesome, I’ll download it and give it a shot. I’m fine with that restriction, resizing was icing on the cake… but just for clarification, will resizing still work on imported widget groups that aren’t declared as plants?

Didn’t get a chance to reply to your last post… but honestly, my opinion is that you shouldn’t restrict the features and flexibility of cabbage just to prevent someone from doing something potentially stupid. There are definitely valid reasons to need plants within plants (as it is, any widgets I have grouped together have to be placed above their groupbox, and have their visibility set individually).

Perhaps plants in plants needs some form of “recursion” limit for safety similar to includes from within included files, or macros expanding within macros (iirc I think csound yells at ~12 layers of depth?)

Yeah, I wouldn’t be surprised if I’ve been doing something dumb this whole time, and now that’s bitten me on the but. If it helps troubleshooting, I think all of my instances force the table to redraw by resending it’s table number on the identchannel… perhaps that might have something to do with it? Anyways, I’ll try one or two things with the amprange bug, and if I still can’t tell what’s going on, I’ll send you some updated files.

Thanks as always, Rory!

#10

Uh oh… none of my instruments work in c2lite, even the most simple GUI test… but the first two instruments tried in the full c2 came up just fine.

Also, the “About Cabbage” button seems to be toggling the csound output console window.

#11

Argghh. Now I wonder why that is. I’ll take a look and get a fix for you. It should behave the exact same as Cabbage2. They use more or less the same source.

#12

I see the problem with the About dialogue, I’m just fixing that now. But I have no problems running any code in Cabbage Lite. All the examples play there just fine. Could it be something to do with your audio settings?

#13

The problem when importing is that Cabbage will not update the import files text when users move things around. So if you put widgets into an include file and then move them around after they have been included, those positions won’t be saved when you exit. Therefore it’s better to organise your widgets into plants. [quote=“t_grey, post:9, topic:809”]
Didn’t get a chance to reply to your last post… but honestly, my opinion is that you shouldn’t restrict the features and flexibility of cabbage just to prevent someone from doing something potentially stupid.
[/quote]

I’m not saying it’s stupid. But I do think it’s a good idea to discourage certain practices. We see this all the time in programming. New features are constantly introduced in languages to help discourage people from dong things that can lead to problems. Smart pointers in C++ are a good example. For now you can put your plants within a plant, within a plant, within a plant. But do so at your own risk :wink: you’ll never hear my encourage someone to do it! And keep in mind, that while you can move the parent of nested plants around, you can’t resize the children unless it’s a basic child-parent setup.

Safety ends at level :joy: But I will try to add some kind of obvious warning to resizing of a plant’s children only work in the basic child-parent setup.

I just tested that here and it seems to work fine. Can you check out some of the GEN examples and see if they behave as you’d expect. That should rule out Cabbage problems then. Cheers.

[edit] Victor just sent me on the latest OSX beta. I’ve updated the OSX package. Do a reinstall and you should have the latest beta version of Csound. Run from the command line to confirm. I think you may have to modify your code a little in order to avail of the changes Victor made.

#14

I’m not sure, but it looks like it might be related to relative paths? I just spotted an error related to an include that works fine in c2heavy and the previous version of c2lite. But it doesn’t show up regularly… I’m pretty confused.

I’m about to zip you up some updated files. I’m trying to tag some key areas of interest to grep for, since there’s a LOT going on. In particular i’m looking at the imported plant issues and the amprange issue… but I’m having issues running any of these in c2lite from sublime.

Going to test all before sending and try to reduce what I send to minimum, but you’ll have it soon.

#15

Please try to create minimal examples as I don’t have time to look over hundreds of lines of code. I did make some changes to do with paths lately. This could well be causing an issue.

#16

6.10 changed quite a few things on my end… now even your imported plants don’t seem to appear in my test instrument, and a number of my instruments throw init errors and such.

I think I need to play with this a little more before sending anything. Hopefully I can get it straightened out a bit. I think working with previous c2lite versions over the new cs6.10 might help me unravel some of this, but right now I need a break :dizzy_face:

edit: but FYI I am still seeing a significant difference between c2l and c2h with regards to my instruments using the newest installer and it’s included csound package.

#17

Can you send me a simple instrument that works in one and not the other?

#18

I think it looks like the problem might be from launching c2l using the cmdline filename argument from sublime or other editor. When opening the file manually it seems to MOSTLY behave the same as c2h (aka, as expected).

But then I noticed that only sometimes opening manually would work, and sometimes not. Almost always the first attempt to open fails, with a message “Cannot open #include’d file …”, but then any following open attempts work. It seems like maybe the working directory gets sets after opening or something?

I’ll zip up the simplest example anyway tho… it has the first attempts at importing a plant, which seems to be very uncooperative right now too. There will be lots of unused include files, but the custom UDOs will all be labeled with where to find them so it should hopefully be pretty painless.

I still have some init/channel issues to work out based on 6.10, it breaks the “bypass_gui” function and maybe a few other things… but for the most part this simplest example will be ok.

#19

The current working directory is set as soon as the file is opened, Before Csound is compiled. I will double check that it happens in all cases. I’ll try out your instruments and get back to you.

#20

The custom plants weren’t be seen because of the spaces in front of them. Big fail on my part. It was a current working directory issue that was messing up the including of files in Csound. It seems that including more than one custom plant in a plant is causing issues. I can’t run off a build now as I’m not at my OSX machine, but I’ll get one to you tomorrow. Probably best I fix the number of plants allowed in a plant first.

#21

I’ve been digging a little deeper and it seems that you can nest as many plants as you want, you can’t include more than one within a plant. That’s sucks.

#22

Awesome, glad you’re getting to the bottom of it. Sorry my examples aren’t more concise… I’m still going to send you one with the amprange crash, but it’s a full instrument. I’ll try to mark it as clearly as I can like the GUI test, but feel free to wait on looking at it if needed. I’m working around the amprange issue just fine for the moment. I just find this odd, because I had no problems with previous cabbage2 betas up until I mentioned it.

I stepped back to 2.0.24 for now… it’s just quicker to be able to launch c2l as I’m trying to figure out the init issues I’m having with the bypass_gui UDO. I think that’s related to the discussion you and Vince had on the list, but I don’t know that I saw or understood how the change would affect me. I’ll re-read that thread a couple of times :slight_smile:

#23

I’ll have a version for you tomorrow morning that should work fine again with Sublime.

1 Like
#24

I gotta ask for an extension on this :joy: So I’ve reworked the plant code entirely to allow as many nested plants as you like. It now also supports as many plants within a plant as you like. But I just need to make sure that the GUI editor is Ok for moving things around. As it stands it messes up some text in the .csd file. I don’t think it will involve major surgery, but I’ve very limited time for the rest of the day. Sorry to keep you hanging, but it will be worth the wait :wink:

#25

No problem… Until the recent discussion about nested plants I had never really understood the limitation, but I probably forget the complications of the GUI editor since I mostly worked from sublime and twiddled my widgets by hand. :innocent:

Anyways, once I got the init/bypass issue figured out, the current build isn’t TOO bad to work around. Tho I’m starting to question my sanity on what actually works and doesn’t, and what’s actually crashing and isn’t. I look into my crystal ball and I see learning debuggers in my future. :eyes:

In the mean time, I’ve had a few other ideas and minor fixes keeping me busy.