JD990 Super Editor - Relentless crashing / CtrlrX fix?

[wharfrat83]

Hi all -

I'm not sure what happened, but the JD990 Super Editor panel I've been using for years is now causing Ableton to freeze up and require a force quit every time I open the app. This is running on Ctrlr 5.3.198 on macOS Sonoma latest version (14.5)

The only way I can get Ableton to open now is by moving the .component to another folder -- so I know this is the culprit. The only change I've made to the system recently is updating Ableton itself, so this could also be related.

I just discovered the CtrlrX fork last night and tried to give it a go. It seems much more stable and I was able to open a JD Super Editor panel, but alas there are some major issues. The "Program Select" buttons no longer work -- in Ctrlr 5.3.198, clicking these would bring up a context menu with all the preset banks. With CtrlrX, the text on the button turns blue when clicked, but no menu appears. Darn! I assume this means the panel needs to be updated for CtrlrX, but this is beyond my ability.

Lastly -- no matter what I do, I can't get any VST versions of Ctrlr, CtrlrX, or JD990 Super Editor to load in Ableton. AUs are the only ones that will scan and show up. Feel like I've tried everything here...maybe a macOS security thing? Any ideas or possible solutions greatly welcomed. I miss working with my JD 990!

[dnaldoog]

Hi @wharfrat83

I am the author of this panel.

I don't know the answer to this as I use Windows 11, Cubase 11 Pro VST, so a completely different setup.

The only thing that is obvious is that you have changed Ableton; it was working on Sonoma before? I built a program for the Korg M3R and someone reported it was not working on Sonoma.

With regard to CtrlrX, I have not yet tried adapting panels to it because it is not stable in windows. I will see if I can make some changes that might make it compatible with CtrlX. I will upload a test version. Are you okay building your own component or vst files from the Ctrlr Instigator within Ableton? Then I can just post the bpanelz file instead of the whole component. (I have to go into a virtual machine of Mojave and build those files, which is not ideal and very slow and cumbersome)

[wharfrat83]

Thanks so much for chiming in! Yes, it was working prior in Sonoma, so it could be connected to Ableton update. I did a Sonoma update at some point too, so it's hard to discern :(

I am capable of building the component via the File menu Export> Instance. Is that what you mean?

After some further testing today, the Exported build is where I run into issues. If I open Ctrlr AU (5.3.198) and load the Super JD 990 panel, the plugin operates and is stable. The downside here is that all the parameters show up as "undefined" in Ableton (see pic), which makes it a nightmare to map to midi knobs (am using an Ableton Push to control).

In the past, loading an Exported build version fixed this; parameters show up as "TVFCUTOFF" for example. But the exported build is what now brings Ableton to its knees. If I save a project that has an exported build version, or have it saved in a template -- those projects will not open. I have to force quit Ableton on the load screen, move/delete the exported build component file -- and re-open Ableton.

I have been trying to test if this issue occurs with the VST version vs. the AU version -- but per the first post, I cannot get Ableton to recognize any VST versions. Not Ctrlr 5.3.198, Ctrlrx or the vst build of Super JD Editor from SourceForce. I've scanned and rescanned Ableton plugins but the AU version is the only one that ever appears as available.

[dnaldoog]

I am capable of building the component via the File menu Export> Instance. Is that what you mean?

Yes, that is what I meant. That's good, so maybe you can do the following. It's just an idea.

Is it just the JD-990 panel you are having an issues with?

The problem with versions 5.3.201 and 5.3.198 (mac) is that they allow functions to run at load (any functions that run a callback when a value is changed) (mouseDown events are no problem).

To get around this, we can place if panel:getBootstrapState() then return end to solve it, but I found that that function sometimes interferes with VST/Component EXE builds (a bit like the problem you are having with the popup not showing for patch selection.

To get around this (with the JD-990 panel which I wrote some years ago) I used the following function to block these functions from running:

So in many many functions you will see code like

selectPatch = function(comp,event)
-- No action if the panel is in bootstrap or program states
if myGetGlobalVariable("allowrunatstartup")==0 then
return
end 

...rest of code

This global variable is set to 0 at load, so no functions will run. In a timer (a delayed function) I then set the value to 1, so functions will now run when the user clicks or moves a slider etc some 800 or so milliseconds later.

CtrlrX seems to have fixed this issue making this blocking function unnecessary. I tried setting _globVar to 99 allowrunatstartup=99, the logic being that it would open up all these functions, but as I said before CtrlrX just crashes on me with no error message when I try to make the changes below, so I don't know where the problem is, but that's the logic anyway. If you can look for a table called _globVar and set the first entry to 99, it might work, but I have no way of testing it. It's up to you!

Probably no need to change this timer code:

function timerCallback(timerId)
  -- Load program timer
  if timerId == 1 then -- ALLOW POPUPS
    mySetGlobalVariable("allowrunatstartup",1)
    timer:stopTimer(timerId) .....

I also have mySetGlobalVariable("allowrunatstartup", 0) in the init() function - you might need to comment that out --mySetGlobalVariable("allowrunatstartup", 0)

_globVar={
	allowrunatstartup=0,  -- set to 99 or some non zero value -1 perhaps?
	--block popups and other unwanted functions from running on load SET to zero in Ctrlr 5.3.201
	multitoneselect=0, -- select and hold more than one tone

_globVar={
	allowrunatstartup=99, -- In CtlrX I nuked this functionality by setting to non zero ;)
	--block popups and other unwanted functions from running on load SET to zero in Ctrlr 5.3.201
	multitoneselect=0, -- select and hold more than one tone

Making all these changes will bork running under 5.3.198

The other thing you could try is commenting out that code in function by function:

selectPatch = function(comp,event)
-- No action if the panel is in bootstrap or program states
--if myGetGlobalVariable("allowrunatstartup")==0 then
--return
--end 

...rest of code

You can see that it's a pretty big job and very frustrating if CtrlX is going to randomly crash along the way. Especially onLoad as it just did with me. Once that happens, we are locked out and it's back to scratch.

JG

[dnaldoog]

Also, have you tried deleting this folder and tried reloading the program?

Library/Preferences/JD-990 Super Editor

[wharfrat83]

Just gave this a quick try and unfortunately Ableton still locks up on opening after deleting the Prefs folder :(

[dnaldoog]

It’s still not 💯 clear to me. Have you tried loading other Ctrlr panels as VST and had the same problem? It reads like you have. If that is the case, then it’s not the JD-990 panel itself, right, but a greater problem.

[wharfrat83]

I just tried with another panel and a few curious things happened.

I tried loading an OB-6 editor to the Ctrlr AU. I can load it just fine. When I try to export it to my components folder, I get this error message.

If I choose a different location for the export such as my desktop, the export itself works okay and I can then move it to the components folder. I am then able to open the project with no issues (doesn't freeze everything like the JD-990 does).

But when I try to access the exported version of the plugin in Ableton, it flashes and then says this.

Not quite sure what to make of this. I tried deleted the preferences folder and re-opening and the same behavior occurs. I tried a third panel and had the same experience as the OB-6 editor.

[damiensellier]

I highly recommand using the JUCE File Open/Save module on recent macOS versions or you'll get stuck when exporting your instance. It's a problem from the OS itself and its gatekeeper since apps are not codesigned. Disabling this option can help:

When exporting VST3 since the plugin identification does not change and remains CtrlrX by CtrlrX, it's seen as duplicate by the DAW. So, either you use Ctrlr and load the panel OR you remove the original CtrlrX.vst3 from the folder and next time you restart you DAW and load your exported instance vst3 it's going to show up as CtrlrX but will be JD990.
Best way would be to build a properly identified VST3 to see if it works. I can do it for intel mac but not mac silicon.

[dnaldoog]

Can you create a very simple panel with one control and see if you get the same results?

[dnaldoog]

The resident mac expert hath spoken!

Still it makes me wonder how much longer we have with VST2. I guess it will be supported for a while; I use a 32bit bridging software for Cubase Pro 11 on Windows because they stopped support for 32bit plugins a good while ago and there are so many good (and often free) ones.

[damiensellier]

32bits plugins are blacklisted for a while in Cubase but 64bits VST2 are still running.
I never came across plugins I liked which did not have a 64bit port. maybe one or 2 but I still have a old mac running snow leopard just to open old sessions in that particular case. When switching this old macbook on, wow it looks really old, vintage I should say :)
But it runs fine with Cubase 6.5 and 32bit.
I also mirrored my old Win XP as a virtual machine for even older sessions and it works fine too on mac with virtualbox. I'm covered for old sessions on windows and Mac OSX.

[dnaldoog]

I would like to be able to occasionally open my old Cubase 5.0 32bit sessions in Windows XP virtual machine, but in Virtual Box Windows host MIDI is not supported I believe. Sounds like it is on a Mac though?

[damiensellier]

That's a really good question, I need to check that and will let you know.

[dnaldoog]

Here is a simple panel for testing, although from Damien's comment it looks like the same problem will persist.

Simple panel_1_0.zip

[dobo365]

In case you are not aware of / forgot (don't know if this is the issue here) but to switch from 5.3.201 (198) to 5.6.30:

msg = CtrlrMidiMessage({0xF0, 0x00, 0x20, 0x32, 0x28, 0x7F, 0x05, 0xF7})
must be written
msg = CtrlrMidiMessage(MemoryBlock({0xF0, 0x00, 0x20, 0x32, 0x28, 0x7F, 0x05, 0xF7}))

appendText and replaceText must get an extra nil argument
f:replaceWithText(sTemp, false, false, nil)
f:appendText(lbInfo:getProperty ("uiListBoxContent"), false, false, nil)

This may be the reason of the crash.
Since I changed that, Ctrlr 5.6.30 is stable and usable (except for some usability things I'm busy to adapt in the code with Damien)

[dnaldoog]

@dobo365 Wow! That’s probably it! I think with all the panels I wrote a long time ago I almost always used lua tables like that for MIDI messages. Recently I tend to use MemoryBlock directly, but back then I didn't understand MemoryBlock so well, so I avoided it. I will try and make those changes and see if that fixes the problem.