Looks like this this happening because the imported Cabbage UDOs are being expanded before the #include in Csound. So, what is the preferred behavior here? I assume it’s best to have them appear after any include statements? I can drop them in right before the first instr definition?
Slugs on Ver. 2.0.27a on OSX [resolved]
Hello, nice to see there is an official beta! But which one is the latest among the 3 beta on the link above?
I am really keen to download it and try this week end.
Each beta filename has its creation date and time on it. If that’s not enough to give it away, most recent betas appear on the top of each list. I’ll try to get some Windows binaries up soon.
Right… But not Évry one uses uk/us,time stamp… I know, I am French…
And I was not sure if you were still thinking of windows users 
I’ve not forgot window users. We don’t use those time stamps either. But I couldn’t be bothered changing my locale settings 
@t_grey, that’s fixed now. I’ll run off a fresh build for you tomorrow.
[edit] @Karamel1, there is a new Windows build available on the betas page.
Thank you!
Not sure I am the only one who encounters this, but cabbage is still not always gracefully quitting under windows. Maybe it is related to csound itself.
Could other members of the forum confirm this please?
Confirmed. I think Rory cleaned up something to do with comboboxes a little bit in the last beta, but there might still be something funny going on.
It’s a little harder for me to tell, since I almost exclusively use c2-lite… so when I exit, a crash is a non-issue. But when using the full version for a few tests I definitely ran into frequent issues when stopping an instrument or shutting down the entire app.
edit: OSX btw 
Thanks guys. I would like to know how to produce this as I’m not seeing that behavior in my tests, then I’m mostly testing builds rather than instruments. If either of you figure out a way to kill it on purpose can you let me know. I’d like to sort it asap.
I have an oddity with numberboxes on OSX when using Live as a host.
The value of the numberbox resets to 1.0 if I close the plugin window and then open it again.
I can see the previously entered value briefly, before it resets to 1.0 , so I know this is happening at the time the window is opened. Another oddity is that it will also reset to 1.0 when I enter a value higher than 1.0, then, if I try again, it will accept the value. These two issues might be related, but I’m not sure.
What is especially confusing is that I can only replicate the issue if the numberbox reside inside a group box, and that there are a considerable amount of other widgets in there. Sorry for such a vague report, but I thought maybe posting it here would help give me some clues. Also if some of you could test the attached plugin under Live, I would be grateful. vst_MIDIator1.csd (14.9 KB)
Just open the plugin window, enter a high value in the 6 number boxes in the first module (rise, fall, rise, fall, channel, ctrl). Then close the window, and open it again. Check if the values correspond to those you entered. With this plugin, the correct value will show in some of the boxes, while some other boxes reset to 1.0. Only fails in Live (works ok in Reaper).
Thanks Oeyvind. I’ll investigate. In the meantime, if you do manage to narrow it down to a simpler example that would be helpful. But at least I’ve something to do on here.
Ok. Not narrowed down, but tested on Windows too, and it behaves the same way there.
If I remove a few controls (does not matter which ones) it seems to get more stable. Still the glitches may happen, but less so with fewer widgets. I tried to remove some of the invisible ones, and that has the same effect (less glitches if I remove a few, like 6 or so, widgets).
I also tried to remove all identchannel() statements, and that sees not to make any difference.
So, it seems to be related to the number of widgets. Not sure what to believe… And it is only a problem under Live (also when tested on windows).
… could it be some “update gui” routine that works differently under Live?
I doubt it as they all use the same VST SDK. There is not problem with Reaper or any other hosts? Does this numberbox happen to share a channel name with another widget by any chance?
No problem with Reaper. Also note that the glitch does not always happen to the same numberbox, sometimes one of them might behave just fine. When deleting a few widgets, more of the numberboxes generally behaves well, but still getting glitches. Which numberboxes has the errors might change from one load session to the next. No shared channel names that I can see. The channels have combinations of parametername+number, like “ctrlnum_parm1” and “ctrlnum_parm2”.
Thanks for taking more time to dig into it a bit more. I definitely want to get it sorted before a full release. I should get a chance to look into it tomorrow at some stage.
I have to take my that off to you Oeyvind. You find the most delicious bugs! This one has me baffled. I managed to set up a debug environment with Live and Visual Studio after about a half hour of searching for the Ableton Live .exe all over my hard drives. (it’s in C:\Program Data, not C:\Program Files). Anyway, I’m set up to start debugging, but it will be tomorrow before I get a crack at it. Stay tuned…
This one has me really stumped. It’s just as you called it. Live seems to set the parameter value straight back to 1 after one tres changing it. Stepping through the code with the debugger isn’t helping much as I can’t see what Live is doing. What I can do is add a check to see if the plugin is loaded into Live, and if so disable the host from setting the value of the numberbox. It’s not a great solution as one will no longer be able to automate numberboxes from Live, or from Csound for that matter. But one way communication to the host will still work. I will spend more time on this tomorrow, but it seem that Live is doing something strange. I just can’t tell if it’s a result of something Cabbage does or not. The fact that this only appears in Live makes me think it’s not a problem with Cabbage. But let’s see.
I’m still struggling to identify the problem here. I’ve some very hacky ideas that I’m reluctant to even try to implement, like for example forcing the numberbox to update several times in a loop when the user clicks on it. It would mean adding some questionable code, although it would only pertain to the plugins that are loaded in Live.
Another solution (I think) would be to rewrite the numberbox widget completely. I’ve test your plugins with other types of sliders and they all seem to work fine. So instead of using the juce::Slider::LinearBarVertical type, I would simply set the type to be a rotary slider, but draw it as a numberbox. That might give us the exact same user experience without the problems seen in Live.
Apropos, @Karamel1 was asking about greater flexibility with slider valuetextboxes. If their size and position could be set manually, then you could potentially display just the valuetextbox. Users could still click and add value, but you would lose the mouse drag. THis option would involve a bit of work and would still fall short of the current functionality of numberboxes. I think I would rather explore the first option first and take it from there.
Good to see you’re getting the same behaviour as I do. Or, good, well, …
It is unclear to me what you mean with “the first option”.
Another hack’ish way of going about it might also be to disable host updates for a short period when the GUI window is opened. It seems the oddity appears just after the Window has been opened (I can oftentimes see the correct value in a flash, before it resets). This might also allow us to investigate what the host tells Cabbage to do exactly(?)