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.
Cabbage2lite pretesting: 2
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?
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 
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 
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.
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.
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.
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 
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.
Can you send me a simple instrument that works in one and not the other?
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.
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.
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.
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.
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 
I’ll have a version for you tomorrow morning that should work fine again with Sublime.
1 Like
I gotta ask for an extension on this 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
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. 
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. 
In the mean time, I’ve had a few other ideas and minor fixes keeping me busy.
That’s it. If it was just code and straight parsing this stuff would be very easy. Anyhow I’ll hopefully have something for you tomorrow.
I managed to find some time to create a new OSX installer. Try it out and let me know if it’s any better. Fingers crossed; I didn’t have time to test your instruments. Same link as before.
Thanks Rory, but this one is actually a step backwards. Effects still fail on initial open in c2l like before… not sure if it’s for the same reasons yet. Concurrent opens still seem to work tho.
Also widget locations are ALL jumbled up, everything became an unusable heap of widgets up near the top Looks like everything lost it’s relative positions or something.
It’s kind of hard to see through all of those “fallen widgets”, but it also looks like gentables stopped updating their graph when I resend the table number (as I do in many instruments with customizable shapes). I’m guessing this is you poking around at the amprange problem, but just figured I’d ask to make sure that the way I’ve been updating them is not an accidental functionality or going away.
Ouch! All of my tests passed without any problems. I didn’t actually get around to fixing the amprange issues. But I was so happy with my parent/plant work that I got a build going for you to try out. Back to the drawing board I guess. Leave it with me, and thanks again for your patience.
[edit] my tests passed, but I didn’t get a chance to try your ones. I will now…btw, is it the same in c2h?
I think it involves plants and relative positions. If your test example is pretty simple, it’s easy to miss because things may only end up a few pixels off… but with a larger example it’s impossible to overlook.
No problem at all, thanks for yours! I know I’m a bit weird in my use case with sublime and lighter versions… but I think the flexibility is worth it. And I also might abuse my cabbage widgets a bit… but you can’t make any coleslaw without shredding a few heads of cabbage, right? 
I already rolled back, so I can’t test at the moment as I’m in the middle of finishing something… but surprisingly no! It seemed like c2h was now behaving like c2l, instead of vice-versa. c2h would also fail on initial open sometimes… but I wouldn’t have to reload the file, just click stop and play again in the GUI.