Debugging with Reaper

[Dan Korneff]

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

[Dan Korneff]

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

[Christoph Hart]

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.

[orange]

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

[Dan Korneff]

@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

[orange]

@dustbro yeah me too. That's a very sad thing....

[d.healey]

The moodycamel strikes again, we got a solution for this yet?

[Dan Korneff]

[Fortune]

This issue is a real pain in the ass........

[orange]

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]

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