Midi Overlay Panels in Compiled Plugin Crashing DAWS?
-
New information...I compiled the latest commit of 6 September and nothing changed...i have crashes exactly like before.
-
Unfortunately it seems that i can't confirm 100% if it is a Midi Overlay Panel bug (because noone of the forum had the time to test it in his system)...although i am almost sure that it is a bug (if i delete the Midi Overlay Panels and compile the test plugin everything is ok without any crash)...but then it's impossible to use the drag'n'drop to DAW functionality...so dead end.
@Christoph-Hart could you please check if it is happening the same way in your system...and if so...is there a solution on this problem?
-
@DimitrisSP Bump bump.
Did anyone has test it? If it is finaly a bug it will affect anyone who uses midi files in his plugin and wants to have the functionality of Drag to DAW or any other Midi Overlay functionality.@Christoph-Hart please take a look at the problem...if it's finaly a bug it tends to be a very serious problem for this kind of plugins.
-
I can confirm what @DimitrisSP is saying about the second time loading the compiled plugin, the midi overlay panel is not visible!
I don't get a crash like Dimitris does but as I said, the Midi Overlay Panel is not visible, so it's not usable I'm afraid.
@Christoph-Hart I know you are occupied with a lot of other stuff, but could we please get a fix for this?
-
Just narrowed my crashes down to this issue. It's replicable in any project with a "MidiOverLayPanel" Floating Tile.
HiseSnippet 1154.3ocyW0saaaCElxNrq1soqsnXX6NgfcQJPVgURVR11E0I1wEFK+XDklt6JXjN1lHRjpTTIwnn.C6IqOB6QXOB8Mn6PI+iTpqgmQV27EFhmeD+N+vOdTGkzChikJhUkSGDADq6ScGHz8azmwEj1MIVeGMjK3gr.a4kfJfMvFtlEFE.j8FDwhiAehkU4WXL2pxRjzee346wBXBOXhHB4LI2CNfGx0Sj1o9uxCBZw7gS4g4rdy5s8jhFx.YBBsxzZjHl2ErdvQLiYknDq6ruOWKUtZlFhIVKsmzefae4UhL6OiGyOGAItvg3hunLwsjA9FDajRZzmG32YTJHlPrncljPJmkPdB8PtOer7IIlGlpvdhG4yGVkJBuxEfmSd3UKG7lBjJkCRe0nZTJjvZAnRgxCnG1tYa6LINE.RiDkBDZW3MIvMJHCUcpBSs4qcGHkQ6KXH77yK171OGM0MBJpvp7bGqNyLVIlvpEO.LOmKrWJKreD00SwizSzXh86QaKzfpKyqXGYlsDq2SaHQCD5mExt.ZovEicX0spUaMa7um9KcSDdZtTXKEGI0vwhUeZ02VsR02U09lp51cp5LaiRFD.pop1zfqlkiqJRBOGTqYeIKHAFaHF9ESuz4K85kE04LTJZK35ii.wmq+mLLUgO8x1MYZF1+YMTFZWDnzbCDrZBWhGlyJKUnMg3KzxHrWsgLLRJLuAq6nS0t7nhFS.ADNVZtKM8YGx04aFGjewUbec+wBd+eTuOv60WmWBI2Vsrd3I0rspUfjo4hdmhcRo63WSyKpvF6WexFWGpOLVyBrGmdL63LVuL7eduQbRUtSylM+nwMtFBGI89zMWemsc1X6eZ8cxoX8gZVeqs1rVsMIooVqinusps8JiK.s8W4msWI+I4UVyXPagObMppV5JjAKPd0qjpKhQNQ.kqUIP02cij1eEcyj1ueV8IHZi7QfFtV+ow0TNAhTdR+j.ltHOng7enBritvoPyQMQLWOn.gQoYwc+YIGmM287B2GQ6v0d8mNdKME7Z3f+WFuCupYY59c6Bd5IfcIZqeal2qbqCkGjAk6Qc4BHcTfTf7MoqseE6Rv9Ef.TljpyLFA3Om2Q.hl6Q.N1SiaOdckHNRFW3E6Bg7SQ1f37BeYLR2Cu4DSUtv8dRlZpp9vyagA4T8wkoSTosK6FJSD5BsGkm6Zx+fQQV5+cih7kiPXwmVxpymLQ6CwVWy7p6KtDBv6vRw3iwKs5xRBzijVrW9PoPF0WJ3d4Kzm.ZEuWOPkG6SMf1UqKLT0SpeBD.r7Msee8CvlMlBySvBlKbl+bwrpWeKMCt1lCf1+mT2tUHuKOWj22JXbwIrW7s+DYhYDlCYXSHNAC8njPWjazCvcWfCmXFMzpjgeKacMy5LxQge5hOh+Fpzwr1ZnRmQJ+hrGgLOk70dYC8Z5SuapDLtEoebWE5gl01NjzAgQ+n0dVMRHxv8ZOOSJ9GPByo6y5KfOar.9r4B3yOt.9r0B3y1KfO6LSeLWtrahVFlcjCEzY+rQXsF+chVkI+MH3xKMC
*1st instance in DAWs: works fine.
Close+reopen: the MidiOverLayPanel fails.
Close+reopen again: DAW crashes.*
In larger projects with presets/midi file menus/etc, the bug becomes prominent enough that it crashes HISE reliably. In DAWs that save plugin states, the plugin can become unusable in end users' saved projects. All of those problems vanish when the MidiOverLayPanel is removed.
I hope to see this one get resolved. The Drag & Drop tile is an important element, and the other midi tiles are a great alternative to connectToPanel code.
-
Im testing a project build with the latest develop branch with two Midi Overlay Floating tiles with the update after init set to off, im cleaning all the midi sequences on init as well and loading them to the Midi Player from the expansion callback, seems to be working (at least for me) since the timeline simulator function was implemented, I can open a lot of instances of the same plugin, an copying with out crashing... however, if you I open another plugin made with earliest versions of hise sometimes it crashes, I updated every project and no problems for now, tested on Logic and Reaper only.
-
@Soundavid That sounds great. How are you cleaning the midi sequences on init? I couldn't find anything in the API regarding the MidiPlayer's "clear all" button, closest thing I spotted was Engine.clearMidiFilePool();
-
@Goodflow Im just Calling this On init
MIDIPlayer1.setFile("", true, false);
-
@Soundavid Thank you, I somehow got it into my head that setFile wouldn't work without a file name.
Unfortunately, the problem persists. I also just compiled my earlier snippet with updateAfterInit disabled + no midi file/sequence present, and am getting the same crash.
Just to clarify, the crashes aren't occurring when opening a second (or third, or 10th) instance of the compiled plugin. Are you able to load your plugin onto a channel, remove it, then load the same plugin back into that same channel without any errors?
-
@Goodflow Yes I can remove it and load it again, Im going to check my project and do some tests because I remember setting the floating tile to Empty and calling the MIDI Player and Index data with the setPropertiesFromJSON from the expansion Callback, maybe that's why is not crashing when the plugin loads but im going to make deeper tests with expansions.
-
@Soundavid That's an elegant way of going about it. I tried this with a preset callback, and it definitely pushes the problem off of initialization in my project.
Added:
- Changed the Tile to "Empty", removed all data.
- Added a preset setPostCallBack to enable/show/set ContentType and Data for the Tile (unless it's the "init" preset, which clears/disables/hides the Tile)
- tested with "UpdateAfterInit" enabled, disabled, and with it toggled via the setPostCallback
- tested with & without an onInit call to load the "init" preset, just to ensure that everything gets cleared.
Ultimately, the problem shows back up when
- The plugin is loaded
- A preset is loaded
- The plugin is removed and loaded again
- A preset is loaded
Hopefully that's not the case with your project/method. It just seems like no matter where the MidiOverlayPanel is fired up, something lingers on close and breaks on the next loaded MidiOverlayPanel.
-
@Goodflow Ok I debugged a lot this problem and I think I found the culprit... the problem persisted in my project when i called an expansion that loads the Midi Overlay and this is what I found.
-
The Plugin Crashes when is removed and loaded again but only if there is one instance running.
-
If you have multiple instances and remove/load the plugin works fine but when you remove the last one and try to load it again it crashes.
This means that the problem is when the plugin is closed completely so I checked the Midi Overlay Factory class in the source code and I found that the class is derived from the DeletedAtShutdown class from JUCE, this class deletes everything when the app is closed but maybe JUCE doesn't call this in plugins until the last instance is closed...
So, I removed the DeletedAtShutdown from the Midi Overlay Factory class in the Source code of the plugin (not re-building hise) and the problem disappears in the plugin...
I tested the plugin today in Logic checking memory and Cpu loads and works perfectly for now but maybe this could be a problem with another type of Midi Overlays or using the Standalone App or Windows (im using two MO tiles, Drag n drop and Midi Viewer).
@Christoph-Hart Maybe you might want to check this out :backhand_index_pointing_up:
-
-
@Soundavid I was just going through the .h file doing the complete opposite, moving code INTO the DeletedAtShutdown class line by line. You just saved me hours of wheel-spinning, I can't thank you enough.
Trying this out now.
-
@Soundavid Can confirm this worked for me in the plugin. Also tried recompiling HISE with the change, and it's more stable in handling the project now :folded_hands:
Thoroughly crash tested the midi note display and drag&drop, all good. The other MidiOverlayPanels seem to work smoothly from cursory checks, as well.
-
@Goodflow Its working like charm for me too in my system, Im going to build it on windows today and report :crossed_fingers_medium-light_skin_tone:
-
@Soundavid All good on Windows here so far (tested HISE & plugin). Firing up a Linux vm to complete the trifecta, but this really seems to have done the trick.
-
@Soundavid said in Midi Overlay Panels in Compiled Plugin Crashing DAWS?:
@Goodflow Ok I debugged a lot this problem and I think I found the culprit... the problem persisted in my project when i called an expansion that loads the Midi Overlay and this is what I found.
-
The Plugin Crashes when is removed and loaded again but only if there is one instance running.
-
If you have multiple instances and remove/load the plugin works fine but when you remove the last one and try to load it again it crashes.
This means that the problem is when the plugin is closed completely so I checked the Midi Overlay Factory class in the source code and I found that the class is derived from the DeletedAtShutdown class from JUCE, this class deletes everything when the app is closed but maybe JUCE doesn't call this in plugins until the last instance is closed...
So, I removed the DeletedAtShutdown from the Midi Overlay Factory class in the Source code of the plugin (not re-building hise) and the problem disappears in the plugin...
I tested the plugin today in Logic checking memory and Cpu loads and works perfectly for now but maybe this could be a problem with another type of Midi Overlays or using the Standalone App or Windows (im using two MO tiles, Drag n drop and Midi Viewer).
@Christoph-Hart Maybe you might want to check this out :backhand_index_pointing_up:
I have the same crash and I want to try your solution but I'm a little bit confused about what to delete where to delete? Can you point it more clear for a newby please?
-
-
HISE/hi_components/midi_overlays/MidiOverlayFactory.h
Line 40:
class MidiOverlayFactory: public DeletedAtShutdown
gets changed to
class MidiOverlayFactory
-
@Goodflow thank you so much.