Debugging with Reaper

[Christoph Hart]

@d-healey Can you make a example project that demonstrates the issue?

@orange There should be no need for a delay in the initialisation, the proper solution is to set a flag during initialisation that prevents the message queue from getting hammered like this.

[d.healey]

@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.

[d.healey]

@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.

[Dan Korneff]

I should have some time to whip up an example this week

[Natan]

@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?

[Fortune]

fixed multithreading crash

is this commit a fix for this issue?

[Christoph Hart]

Unlikely.

[Fortune]

@Christoph-Hart Ok for cpu multithreading then.

[orange]

@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

[ally]

@Christoph-Hart If you tell me what the flag is and how to set it I will send you $10 tip in PayPal...