Debugging with Reaper

[Christoph Hart]

The moodycamel queue is being used for communicating between audio and UI. If the queue is full, it means that you are sending too many messages from the audio thread.

Do you have some setAttribute() or something like that that is being called once per buffer (or even more)?

[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