Cabbage Logo
Back to Cabbage Site

Slugs on Ver. 2.0.27a on OSX [resolved]

@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 :wink:

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, …:slight_smile:
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(?)

The first option would be to rewrite the numberbox widgets. Second option to to provide more control over the textboxes that the slider produces so you could potentially just display the textbox and not the slider.

This I could do quite easily, if the first option doesn’t work. Have you found the magic amount of time to disable them for?

I’m not sure of the magic amount of time, but just now it would be good if the time is long enough that we can manually inspect what is going on by looking at the screen while it happens. So perhaps 1 second?

We should be able to do that already by setting the guirefresh() to a very large number? There is some kind of feedback look happening where Cabbage is notifying the host that a parameter has changed, and then Ableton immediately sends a bogus value back to the plugin. It’s very strange. I’m getting deeper into it. Even my own implementations of a numberbox fail in the same way. It’s all very strange behaviour. I can spend more time on it again later. It has my total attention.

For what it’s worth I can recreate the issue without a groupbox and with a reduced set of widgets. Actually, I’m going to try nothing but a numberbox now…yup problem persists when I simplify the whole thing down to a single numberbox. As you can see, Live is somehow setting the parameter to 1 after we set it. At least we can rule out number of widgets or anything else strange.

Oh boy. If I remove numberbox strings from the code base it seems to work Ok again. At least that’s how it stands at the moment although the current code is a mess with debug statements and temporary methods all over the shop. I will tidy it up and see if the problem has somehow disappears.