Debugging with Reaper
-
@Christoph-Hart good to know. I'm using setAttribute about 25 times in this script. Lemme see if I can narrow it down to a particular call.
-
@Christoph-Hart said in Debugging with Reaper:
The moodycamel queue is being used for communicating between audio and UI
Do all plugins created in HISE share the same queue?
-
No but they share the same UI thread and if something clogs it with hammering the queue it will more likely be full with multiple instances.
-
@dustbro said in Debugging with Reaper:
@Christoph-Hart good to know. I'm using setAttribute about 25 times in this script. Lemme see if I can narrow it down to a particular call.
Have you found any solution for this? Any suggestions.... etc?
I am using setAttribute approx. 80 times in the plugin. And 20 times in an inline function. -
@orange said in Debugging with Reaper:
Have you found any solution for this?
Nothing on this end. I definitely have issues with multiple instances. I've been so jammed up I haven't had time for more debugging
-
@dustbro yeah me too. That's a very sad thing....
-
The moodycamel strikes again, we got a solution for this yet?
-
-
This issue is a real pain in the ass........
-
It might sound crazy but, is it possible to add 1 or 2 seconds loading time delay into middle of the script (for fx plugins)? So while the initialization each instance will load a little bit until the break code in the middle of the script (1 or 2 seconds breathing) then load the rest.
I have a theory that quick loading instances crash more :) Maybe it is a bullshit, I don't know but it's worth to try it :D
-
-
@Christoph-Hart It was only happening for me in the compiled plugin and I've only test on GNU/Linux. I'll run some more tests and do a Windows build if I can recreate it there.
-
@Christoph-Hart Issue only seems to be happening for this particular project with a debug build, haven't been able to recreate it with the release version so I guess my problem is solved.
-
I should have some time to whip up an example this week
-
@Christoph-Hart said in Debugging with Reaper:
the proper solution is to set a flag during initialization that prevents the message queue from getting hammered like this.
How to do Such A Flag?
Any Advice is Much Appreciated? -
fixed multithreading crash
is this commit a fix for this issue?
-
Unlikely.
-
@Christoph-Hart Ok for cpu multithreading then.
-
@orange said in Debugging with Reaper:
It might sound crazy but, is it possible to add 1 or 2 seconds loading time delay into middle of the script (for fx plugins)? So while the initialization each instance will load a little bit until the break code in the middle of the script (1 or 2 seconds breathing) then load the rest.
I have a theory that quick loading instances crash more :) Maybe it is a bullshit, I don't know but it's worth to try it :D
Any idea about this wait function? With timer object? How to do it?
It will be executed only on the initialization -
@Christoph-Hart If you tell me what the flag is and how to set it I will send you $10 tip in PayPal...
-