Discussion/thoughts on imported widgets & code

[t_grey]

So I’ve run into a problem, and it makes me think the way widget code is being included creates problems in certain instances, and it’s probably completely due to my own bad suggestion early on.

Here’s the problem:
It appears that the imported widget’s csound code is imported after the rest of the cabbage file’s csound code. This means UDOs from the widget can’t be called by any custom UDOs in the cabbage file.

Here’s the why:
Probably because I wanted to be able to have macros, UDOs, and all other included stuff available to the imported widgets. I remember us discussing it early on. I think I chose poorly

Here’s the workaround:
I’ve been moving imported widget group’s UDOs back into regular include files rather than in the .xml, and having the xml code section include the files there. Wrapping the include files in an “#ifndef ALREADY_INCLUDED” style block to avoid duplicated includes means no issues arise if the group includes a file and then the instrument does the same. This separates the widgets from the actual code again, which is not ideal… but allows both widget groups and cabbage file UDOs to call as needed.

Here’s the proposed change/solution:
Imported widget code goes first, before the cabbage file’s code… simple as that. If the widget group’s code needs access to any “libraries” etc, it can include them itself.

What are your thoughts, Rory? Is there a better workaround, or does this seem like a reasonable change in the overall design? And feel free to blame me for this one… I’m pretty sure it’s all my fault

[rorywalsh]

It appears that the imported widget’s csound code is imported after the rest of the cabbage file’s csound code. This means UDOs from the widget can’t be called by any custom UDOs in the cabbage file.

Actually, what happens is the code is inserted right before the first instrument block. I can see how that would cause issues. I can instead put it right at the very top of the file?

[t_grey]

the code is inserted right before the first instrument block

Interesting… will it create a problem that my widgets code sections include files that sometimes may contain an instrument too?

I can instead put it right at the very top of the file?

Well, that’s what I think would be best… but that’s exactly the point of the thread, I don’t always know best If you think it’s a good idea too and see how it could help, it’s probably worth trying… but I also realize it’s potentially a big change that might create other unexpected problems behind the scenes.

As always, I’m willing to be a guinea pig on any fresh betas. I have a number of examples now that could be used to test against this issue, which I could also zip up and send over if you want.

[rorywalsh]

I’ve uploaded a new beta here. Let me know if this one fixes all your issues. TBH I’m glad that your currently the only one using this feature. You’re finding some nice issues with it

I do wonder about my implementation. Expanding the .csd file by inserting all sorts of extra code does seem a little messy. I may try a new implementation with include directives for this. It will remain the same for the end user, but might make things easier for me to maintain.

[t_grey]

I get a 0 byte file when I try to download that. =\

Expanding the .csd file by inserting all sorts of extra code does seem a little messy. I may try a new implementation with include directives for this.

I’m not sure I agree with this idea… when running the cabbage file, the console output lists the monolithic temp file being generated, and if errors are encountered I can refer to that to see after parsing what line actually created the issue. Wouldn’t include files further muddy the waters when troubleshooting, adding another layer of complexity?

My suggestion would be instead to put clear comment blocks around each section in the monolithic temp file… for example:
;---------------------------------
;
; Cabbage generated comment:
; Imported widget cabbage code
;
;---------------------------------

blah blah blah

;---------------------------------
;
; Cabbage generated comment:
; Instrument cabbage code
;
;---------------------------------

blah blah blah

[rorywalsh]

That could be done. Leave it with me. I’m not sure what happened with that file. Try this one.
https://github.com/rorywalsh/cabbage/releases/download/vBeta/Cabbage.pkg

[t_grey]

That could be done. Leave it with me.

If you think it makes sense, great… otherwise just take it as a suggestion. I think it’d be easier for both you and users tho as one file.

Try this one.

New version installs properly and the gentable crash bug is fixed, however comboboxes still aren’t listing their items, still giving a single number.

[rorywalsh]

Did you fix the combobox xml file you posted? It’s not a valid plant. it’s working here for me once I fixed the plant declaration.

[rorywalsh]

Btw, I just noticed an issue with the insertion of UDO at the top of the instrument section, which I added yesterday. It’s fixed now and I’ll update the betas shortly.

[t_grey]

Did you fix the combobox xml file you posted? It’s not a valid plant.

I guess I’m not catching on to what’s wrong with it… at first I thought you meant it needed to be contained in an image or groupbox plant() container (tho I think you had also said the plant is implied when it’s imported), but that didn’t seem to work. What am I missing?

Btw, I just noticed an issue with the insertion of UDO at the top of the instrument section

Ironically, I hadn’t gotten to test that aspect yet… even tho it’s the subject of this thread. I got sidetracked testing the comboboxes and converting gentables. I’ll give it a shot first with the next beta… it’s easy copy/paste stuff for me anyway.

[rorywalsh]

New betas available. Here’s the test files I’m using based on your xml file.
test.csd (491 Bytes)
combotest.xml (552 Bytes)
I didn’t get to add those commented sections to the expanding .csd file yet. I’ll let you know when I do.

[t_grey]

New betas are looking great so far.

Including imported UDOs first appears to be working as expected.

Comboboxes in all examples appear to be working again.

Gentables are much more stable… tho I can still crash it with the GRAPH macro and an amprange(0,1). Changing that to a properly formed (0,1,-1) does the trick, but figured I’d mention it just for stability’s sake.

[rorywalsh]

Thanks for the report. Glad to hear things have improved. I’ll sort that amprange() issue.

[t_grey]

Well, technically the docs specify -1 should be used to apply to all tables… it had always just worked anyway for me. Even if it doesn’t “work”, it probably shouldn’t crash.

I also haven’t stripped down a bare example yet, but it seems that groupbox’s linethickness and outlinethickness modifiers aren’t working. Only tested with the simple style include… I didn’t try changing them real time via widgets yet

And here’s a POC test for tablebackgroundcolour and tablegridcolour not playing nice together… or am I missing something here? gridtest.csd (1.8 KB)
edit: Apparently I’m missing that it IS working… not sure why it didn’t or rather I thought it didn’t when I tested and uploaded it earlier. Now on to figure out why my real world use case of it isn’t working…