r486 warning

[atom]

heh don’t get mad no need for that, it’s needed cause JUCE has some drawbacks on the mac that cause crashes when closing plugins, there is no real fix for it (i talked to Jules the JUCE developer and other people) the only workarond (witch is not 100% either) is to wait for all pending messages to get delivered while the plugin is still running, otherwise the host will crash. So i had to put that 2 second delay, otherwise you would get crashes now and then.

also i don’t consider MAC beeing bad or Maschine beeing bad, i just don’t know either of them as well as i know Windows and Windows based hosts, it’s hard to understand them cause sometimes the problems you bump into are weird, stuff that should happen and yet there it is.

[minimalist]

Yeah sorry, it costed me soo much energy (now and the last 2 months) to get Ctrlr bug-free (on Mac) – and I really can’t follow your arguments (substantially: yes – but not the decision).
I can tell you that Ctrlr never crashed the last months on Maschine or Ableton when the hosts get closed (and I’ve closed them in terms of tests maybe 1000 times(?) in the last month).

Please tell me: why this big closing delay JUST happens in the combination Mac/Maschine? As I told: ALL other systems (OS vs host) are working well!

EDIT because of your edit: ” title=”Wink” />
Yeah I know that Windows is your preferred (better known) OS. And it’s nice that you anyway programing Ctrlr for Mac (but this delay when closing really let me think about to stay on 475).

[atom]

i have no idea, this dealy is implemented independent of the OS/HOST it’s always 2 seconds (i’ll try to make it shorter like 0.5s) maybe your configuration makes this delay more noticable, like i wrote once i get the CPU usage fix in place i’ll re check this. I’m also discussing "how to deal with multiple instances of Ctrlr in one host" issue with the JUCE developer.

[minimalist]

Though I still can’t notice the advantage of this delay feature – if the delay could be reduced to a quarter of the needed time… I [i:3djp2ij9]could[/i:3djp2ij9] live with that (though bigger projects still would need to close them ~ 30 seconds, these days this is still a huge amount just for closing a project). I’m really curious if the next fix will solve some of my problems (it could be the first usable Ctrlr version for me – since 2 months).

[atom]

well i hope it will, if the delay is not there, the host will have some messages from the OS that need to get delivered to the plugin, if we don’t wait the host will try to deliver them even if the plugin is already deleted and will crash, this is silly but that’s what happens. that’s why i need to wait for a moment so that all those pending messages get processed while Ctrlr is still alive.

[minimalist]

Thanks for the explanation. Though I’m still wondering why:

a) ALL other plugins (even Ctrlr v4) I’ve ever used, just need 1-2 seconds to close even if they get loaded 1.000 times – Ctrlr 486 would need in this case more than half an hour!
b) older Ctrlr releases "never" caused a crash when they get removed (OK, actually in some VERY old Ctrlr releases (around build 350) there was in 2-3 releases this "crash when Ctrlr get closed bug")

But as I told I could live with a reduced delay of a quarter in compare to the current needed time, though it still seems strange to me (as a non-programer) why only Ctrlr has this problem.

Multible Ctrlr versions: On Mac I really never had problems with them. I could open Ctrlr 12 times (for 12 MIDI channels) – and there is completely no issue, everything works great!
… I’ve tested Maschine/Ctrlr on PC. Also here I can’t notice any problems in terms of closing AND in terms of multible Ctrlr plugins. The different Ctrlr plugins get automated and they sended different MIDI messages to different MIDI channels – without a crash or whatever. Though I’ve to add that I haven’t the possibility to connect my synths to that PC – but I assume it also should work.

[Author]

Posts