These are questions I can’t really answer, but I have just asked some of the Csound guys so I’ll let you know 
[edit] One of the main devs got back to me just now as said that he think loops might be faster than recursion and that arrays and tables should be more or less the same. I think in this case it’s most likely the widget arrays!
The efficacy is certainly better now. I did some optimizing of the recursive udo as well as the custom plant to help with this. I am having another issue when I try to make another custom plant and import it. Cabbage creating the first plant I imported on top of the second plant for some reason and then when I stop and start the instrument in cabbage, cabbage crashes. I have given them different namespaces and that does not seem to help. The second plant also does on load correctly if I comment out the first, so I think it has to do with the import.
If I change the order of the import, it solves the problem in the GUI, but the crash still persists.
modalSynth.zip (126.6 KB)
[edit] I think the crash may have something to do with the lfo code-- specifically the hrange widget. The weird duplication issue still exists but it seem to be separate from the crashing.
The range widgets have been known to cause issues in the past. Can you try taking them out and seeing if that helps? Also, I think you and @t_grey are the only people so far to use custom plant import, so it might be a little rocky at the start. I’ll check out your example and see what I can see…
[edit] it’s definitely the hrange slider that is causing the problems. But the second custom plant is appearing where it should for me?
[edit] only one channel is being imported for hrange, which is causing a crash when you try to reload the instruments. Just looking for a fix now…
If I could lend a hand, I would… but I think the libsndfile issues with that custom csound build have struck again Rory! The example segfaults immediately after the UI appears. Not a big deal tho.
If I I understand what I’m reading the problem to be and if I recall correctly, I think the range widgets didn’t work at all when imported, and needed a bit of reworking. I think I might even have an example or two somewhere using a pair or slider widgets instead of a range widget waiting for a fix, but it was never a priority at the time.
If there was an issue with libsndfile then Cabbage wouldn’t run at all. Are you able to run other examples? I’ve narrowed down the problem, just need to find a fix…
I found this thread from back in the day discussing the range issues: Issues with hrange in imported widget groups?
Yes, I can run MOST examples… every now and then I have one of my files that used to run but it crashes, but I’m close enough to 100% and have had enough on my plate to really worry too much about it.
This is what I get running modalSynth.csd in place with it’s other required files from the zip intact:
--Csound version 6.14 (double samples) Apr 21 2020
[commit: 393bfeb2f358c2baa3e302b47337ab479b298b64]
libsndfile-1.0.29pre2
Csound tidy up: Segmentation fault
backtrace() returned 10 addresses
0 CsoundLib64 0x000000010f1c15b2 signal_handler + 50
1 ??? 0x0000000000000000 0x0 + 0
2 CabbageLite 0x000000010e9b0327 _ZN4juce20AudioProcessorPlayer21audioDeviceIOCallbackEPPKfiPPfii + 1943
3 CabbageLite 0x000000010e7df16e _ZN22StandalonePluginHolder21audioDeviceIOCallbackEPPKfiPPfii + 222
4 CabbageLite 0x000000010e91b6aa _ZN4juce18AudioDeviceManager15CallbackHandler21audioDeviceIOCallbackEPPKfiPPfii + 810
5 CabbageLite 0x000000010e9152d8 _ZN4juce16CoreAudioClasses21AudioIODeviceCombiner3runEv + 2376
6 CabbageLite 0x000000010e9cfbac _ZN4juceL15threadEntryProcEPv + 412
7 libsystem_pthread.dylib 0x00007fff61591661 _pthread_body + 340
8 libsystem_pthread.dylib 0x00007fff6159150d _pthread_body + 0
9 libsystem_pthread.dylib 0x00007fff61590bf9 thread_start + 13
[Finished in 2.7s with exit code 1]And when you run it in Cabbage as opposed to CabageLite? But do all of your .csds fail with the custom Csound build I made? Richard is using the same build in Berklee without any problems?
Interesting, that does make the difference. It didn’t crash right off the bat, but I’m still not sure it’s working properly.
I don’t know that I’ve noticed C2/C2L making a difference before, so that’s also interesting. But next time one of mine crashes, I’ll definitely try that first!
And no, I’m not having problems… for the most part everything is working perfectly. But there is an example or two I had that I think crash every time. I’ll probably have found them by tomorrow, since I’m working my way file by file for some minor “refactors” right now anyway. 
All good now. Gees, that was so simple to fix, yet took me about an hour of stepping through the debugger to find it. 
New build here
Awesome work Rory! Can’t wait to get my hands on these range widgets! 
Hrm, did something go wrong with the build? OSX appears to have built unusually quick, and I don’t see either C2 or C2L bins in the drop.
You’re right. Something is off with the OSX build. Leave it with me. Probably tomorrow morning before I get a chance to look into it…
Should be fixed now
I got it, it’s a working build. I haven’t tested the range sliders yet… but immediately I’m seeing a difference in rendering/parsing behavior on imported widgets, and it makes me a little nervous for what other differences in subtleties might be lurking below…
Here’s an example:
I’m going to take a look, and it might be an easy fix for those… but not sure why they changed, but not ALL of my widgets changed. 
Also a minor concern, for some reason the once I install a new drop, I can’t reinstall an older drop without nuking the folder first.
I can’t think of what changes caused that problem? The only change I made was to allow widget that support multiple channels? Hmmm. Strange. If you can narrow it down that would be great.
Ok, good news on both fronts. Range widgets appear to be working in my first tests. It’s great to have those back!
With regards to the “white widgets”, the difference between once that work and the ones that don’t:
Working:
$CONTAINER bounds(0, 0, 25, 10)
{
Not working:
$CONTAINER bounds(0, 0, 25, 10) {
Both rely on the same define of from an external imported file:
#define CONTAINER image colour(0,0,0,0)
It’s an easy fix on my part, so I can easily change it out… but I do want to make sure it’s on your radar, because it might have changed some other parsing that we haven’t discovered yet. 
For clarity, these are both imported xml sets of widgets, and those are the first lines of the cabbagecode sections
I should have known it was something to do with a macro. Why did I ever introduce these to Cabbage 
