Cabbage Logo
Back to Cabbage Site

Cabbage2lite pretesting: 2

#1

Ok, having some trouble wrapping my head around some of this, but I’ll start with what I think are the bugs first.

  • 2 macros on same line, only the first expands. example:
    combobox bounds(10, 34, 100, 30), channel("graph1-shape"), channeltype("number"), value(1), identchannel("combo-c"), $SHAPE_MENU $COMBO
    where $SHAPE_MENU expands to contain the items:
    #define SHAPE_MENU items("Sine [8 partials]", "Line [1 seg]", "Pyramid [2 seg]", ...etc... )
    and $COMBO expands to a color/style intended for comboboxes:
    #define COMBO colour(30,30,30,255), fontcolour(160, 160, 160, 255),
    Deleting first macro or changing the order makes second expand, at expense of the first.

  • Macros with an adjacent comma no longer expand, while they have in previous versions. Not sure what else should be allowed to touch during parsing, if anything. Perhaps { and } too?

  • gentable with amprange(-1,1,1) consistently crashes c2 and clite. tried with some different values for quantization too, no luck. removing the amprange statement fixes it.

  • second instance of example “plant.xml” can’t seem to get new X/Y pos in your example, always appears in same place. It was added like so:
    radioValueButtonGroup bounds(18, 12, 158, 110), channel("radioGroup"), namespace("rw") radioValueButtonGroup bounds(176, 122, 158, 110), channel("radioGroup2"), namespace("rw")
    and further down:
    kValue rw_radioValueButtonGroup "radioGroup" printk2 kValue kValue2 rw_radioValueButtonGroup "radioGroup2" printk2 kValue2
    This might be something I’m doing wrong, so if it works for you it might be worth adding a second instance to the example properly for us to learn from.

  • re-clicking “show console” should act as a toggle for the window

  • add version # to c2lite, probably in the settings? (already mentioned, just making it official)

  • c2lite doesn’t have examples available in the menu, and “file|open” on OSX doesn’t allow traversal into application directories to view examples in the cabbage dir. assuming examples get added to the menu, should c2lite have it’s own examples for modularity/portability or should it refer to the full version’s for consolidation?

Next up, a couple quick questions:

  • Can an imported “plant” be a member of a groupbox, even if nothing in that “plant” is actually declared a plant? I’m thinking no, since when I tried a bunch of other widget’s locations were all out of whack.

  • How should namespace be used? Calling widgets with the wrong namespace doesn’t seem to work, so I assume multiple instances would all be called with the same namespace like I did above? It doesn’t appear to be used in determining channel names, since channels in your example are still prepending SName…

I’ll admit that I’m having trouble getting my first imported plant to work… but your example works when imported into my project, so obviously I’m doing something wrong. I’ll keep plugging away at it for now and see if I can figure it out.

#2

Thanks Keven, I’ll get back to you later when I’ve had a chance to look into these issues. Thanks for testing!

#3

Fixed in GIT.

Not sure what you mean by this, can you give me an example?[quote=“t_grey, post:1, topic:809”]
gentable with amprange(-1,1,1) consistently crashes c2 and clite. tried with some different values for quantization too, no luck. removing the amprange statement fixes it.
[/quote]

This is working fine for me here:
gentable bounds(100, 10, 500, 100), tablenumber(1), amprange(-1, 1, 1)
and
f1 0 4096 10 1
result in what I’d expect.[quote=“t_grey, post:1, topic:809”]
second instance of example “plant.xml” can’t seem to get new X/Y pos in your example, always appears in same place. It was added like so:
[/quote]

Indeed, this is a bug. In fact, I think I may rewrite that code to be a little more robust. Although there’s an easy fix to that problem, I see a potential issue further up the road when multiple imported plants are moved around in the GUI editor. In relation to your question further down, namespaces aren’t really relevant yet as they are not in Csound yet. I’m afraid we’ll just have to use unique pre/post fixes for our UDOs. As for placing an imported plant into a plant. Oh boy…you had to ask! I’ll do that re-coding and see then :wink:

Fixed in git.[quote=“t_grey, post:1, topic:809”]
add version # to c2lite, probably in the settings? (already mentioned, just making it official)
[/quote]

Fixed in git.

I can add the examples menu as it is in c2. I don’t see why the full plethora of examples shouldn’t be included. They all run fine in C2Lite. [quote=“t_grey, post:1, topic:809”]
so obviously I’m doing something wrong
[/quote]

#4

Thanks, great work Rory!

An example for the macros with comma problem… after defining a macro, I can’t call it if a comma is touching it, like so:
image $INVIS_PLANT, bounds(...)
Which made me wonder, if an exception needs to be made for when a comma is touching the macro, would making a similar exception for { and } be a good idea? Perhaps anything else?

Very odd that the amprange is working for you. Every single one of my instruments using it crashes with the new version, and didn’t before. Simple removal of that section fixed it in every case (probably 4 or 5 different instruments). I can send you a few examples zipped up if you’re still having trouble recreating it.

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 :slight_smile:

Sorry for opening that can of worms, but I had a funny feeling that might create an issue or two. On the plus side, might the reworking of that have any impact on the unsupported aspect of plants in plants? Seems like it’s heading down that road.

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. Both seem to have advantages and disadvantages. Either way, being able to pull up examples from lite would be great!

Which very well might be why amprange breaks my stuff, but not yours :slight_smile:

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.

#5

Ha, I meant to write that you’re probably not doing anything wrong at all, but looks like I hit send before writing that! It’s already too late here. I’ll get back to you tomorrow about the rest of your post…

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