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