effIdle and u-he Repro about qtractor

[rncbc]

you can tell on reply that Qtractor sends effEditIdle every 66ms (15Hz) -- sending it at 60hz is not an option;

and as far as I can tell effIdle use has been deprecated on VST 2.4, so why one modern plug-in developer requires it still is beyond my understanding :/

cheers

[thebutant]

Aha, I see.
Thanks for your quick and clear answer! 🥇

[thebutant]

Sorry for bringing this up again.
It's just that I'd really love to continue using u-he plugins in Qtractor in the future.

What I asked may have been wrong. Someone commented that it should probably be:
effEditIdle, not effIdle.

Would this make the answer any different?

[rncbc]

as said before, that was the fact: qtractor already sends effEditIdle for ages
the real problem, with recent u-he linux ports lies on something else
from what i read from the kvraudio forum and from my naive standpoint, the u-he UI event loop processing and/or graphical rendering model has been severed and seems to put up with abique through edge of a meltdown... as it seems, not only qtractor is the only one in the victim list
cheers

[thebutant]

Thanks for another good answer.
Yes, you're right. At the moment there are plenty of issues to be solved in the u-he Linux departement. So maybe I shouldn't worry before a (more) stable build is released.

My fear is that they would say "We cannot make something that works for everyone, here's a version that runs smoothly in BitWig on Ubuntu." 'Cause that's a setup I can't see myself having for another 100 years, as. . . you know, I love Qtractor.

[rncbc]

hi, any status update?
on my own I could verify the following:
a. Repro-1-6640 as from Repro-5 public beta (Repro V1.1) runs and shows its GUI as it should;
b. Repro-1-6820 and later, including latest to date Repro-1-6987, all show up as an empty, blank GUI window.
maybe you already know all that all along.
cheers

[thebutant]

That's exactly right.
And the same goes for the new Zebra 2.8 builds they are making.

Fortunately the 6640-build of Repro-1 (and 5) works pretty good. So I just use that one.
In Ardour I actually get the later builds running, but with great lag in UI.
In Carla the newest Repro-build (6987) actually seem to run ok. The latest build of Zebra also runs, but with a little lag.

Of course Ardour and Carla has little to do with this thread, I was just thinking you (I do admit I have pretty high thoughts about you, as I like Qtractor so much) might know something about the way they're made, how they differ from Qtractor.

Thanks for looking into this!

[rncbc]

well, native linux VSTi support predates by a long shot the ones in ardour and carla for crying out loud--facts are that it all this stuff was already there back in 2008, a time when ardour didn't have MIDI support at all and carla wasn't even a sketch yet for some years to come :)

that said, i must confess that u-he is of course focusing on its partners and customers first (like trump's "america first", get it?) and that's one reason why bws works and all the rest (of us) are just left behind as afterthoughts or to say the least, not a kind priority, whatever.

one has also to think about the relationship between one voluntarious guy (abique) and the u-he's top-hat head (urs) : we all fear that once things run barely ok on bws then all the rest are stamped with a "pariah" status; it's quite a understandable commercial behavior but not a communally acceptable one.

anyway, on my watch, i'll get some popcorn ;)

cheers

[rncbc]

o.O

i've just made an interesting finding: Repro-1-6820 shows up its GUI alright on a Qt4 build but alas, it suffers as badly from the same lagging response issues as many reported on some other (floss) linux hosts (all but bws;).

still no doubt, Repro-1-6640 works/shows fine though.

hth.

ps. not even a single line changed on qtractor (old VST) code base.

[thebutant]

Ah, that's interesting!
And thanks for the VSTi history there, I appreciate that. :)

Yes, now it seems everything is about how the vst3 behaves in new betas of BitWig (a little Reaper taken into concern, maybe a little Mixbus, but mostly just Bitwig and no floss or vst2 mentions). As you wrote, I also think it looks like the Linux effort might be done as soon as it runs well in Bitwig. Which, as you also write, is understandable from a commercial company with partners pov, but makes no sense from a GNU/Linux perspective.

I would easily understand if you went RMS on this and stated that those kinds of proprietary plugins are not your concern. But then again, I'd be most happy (in a less heroic and more pragmatic way, of course) if they could work, as they are really quite useful for me. ;)

There is 6640. So there's no hurry anyway.

[rncbc]

new branch "vstx" may have a highly experimental fix to the annoying blank/gray windows from recent u-he plugins (> 6640);
it kind of solves the GUI rendering, but I'm afraid it does nothing to the annoying unresponsiveness lag on setting up Repro-1/5 GUIs;
some other u-he plugins seems fine.
please test && tell
cheers

UPDATE FYI: former "vstx" branch is now merged into master.

[rncbc]

fyi.

Repro-1-7015 seems to show up nice on both released (v0.8.6) and git head (v0.8.6.8+).
although, the GUI lag is still a pain :/
cheers

[thebutant]

You're right!
This is starting to look like a future I can be happy with.
(but then there's global warming and increased surveillance and smarter weapons and. . . ah, fuck!)