Architect: NI Razor in Reaktor Player causing crash + Tracktion F'em slow response

[centipus]

A few issues with various plugins I've encountered in using Architect:

In Architect standalone or VST, opening NI Razor 1.5 in Reaktor Player 6.4.3 crashes Architect immediately. I can open Reaktor successfully, but loading Razor reliably causes a quick crash. I do not own the full version of Reaktor or any other Reaktor instruments so I have not tested with anything other than Razor. I get the same result loading Reaktor Player as an AU or a VST

Tracktion F'em causes a massive slowdown in Architect standalone and VST. When loading the plugin on a mixer channel, Architect takes a few seconds. Once loaded, switching to the Architect Mixer panel from any other panel produces a beachball and happens painfully slow. Usually a lag of 8 to 10 seconds before the mixer panel shows. F'em definately opens more slowly than most other plugins I own in my other hosts, but nothing like in Architect.

In Architect standalone and VST Renoise Redux can cause the same channel phase offset behavior as ZebraHZ I described recently in another topic (viewtopic.php?t=585672) when adding some of it's internal effects to a patch. Without adding any effects Redux behaves as expected.

I'm using a 2018 Mac Mini running Big Sur 11.6.8

Despite these issues I've had some total magic moments working with Architect since I recently installed the demo. Thanks for making such a cool app @colin@loomer

[colin@loomer]

Noted all these, and I'll have a look into them.

I may have to come back to you for more info if I struggle to reproduce the issues, if thats OK?

[centipus]

Absolutely! Let me know what you need

[Kott]

F.'em is known having tens of thousands of parameters. Some hosts work very slow in such case.

[colin@loomer]

Yes, I think that is the cause. I deliberately don't enumerate the parameters of a plug-in until the parameter properties are opened, but it seems that somewhere else in the codebase the amount of parameters is causing slowdowns. I should be able to work around it by removing this unneeded parameter scan.

[colin@loomer]

Making some progress on this. I can confirm that it is, as was suggested above, due to the amount of parameters in a hosted plug-in. I created a sample plug-in with a silly amount of parameters - 32,000 - and it does indeed grind the mixer UI to a beaching-ball spinning halt for a while. But I now know which parts of the codebase are being stressed by this, and so can come up with some solution.

[colin@loomer]

@centipus

I have this fixed now. I've basically added custom parameters selection to plug-ins, which means that the parameters will not be all loaded up front. Could I send you a beta build to check if this works for you?

[centipus]

Absolutely. PM when you’re ready