Sparta vsts plugins work in ardour?

calimerox · October 9, 2020, 6:57pm

I just found out about these plugins

http://research.spa.aalto.fi/projects/sparta_vsts/plugins.html

would they work in ardour? I know ardour has very advanced possibilities for ambisonics setups via ambdec etc… but this would be a great addition I think.

x42 · October 9, 2020, 7:18pm

Since they’re using JUCE and the source code is available, they can be made to work.

However I expect that first the following issue has to be addressed:

calimerox · October 9, 2020, 7:42pm

fantastic Robin, I keep my fingers crossed…

mrskytown · October 10, 2020, 9:23pm

These plugins look very cool

ccaudle · October 11, 2020, 3:24pm

Would this also cause a problem? I thought Ardour required flexible block sizes now.
“the plug-ins support sampling rates of 44.1 or 48kHz, and block sizes that are a multiple of 64 or 128 samples”

x42 · October 11, 2020, 4:45pm

That sounds like they use some stock convolution engine. This can probably be addressed if needed.

This has always been the case

It’s only used for

sample accurate plugin parameter automation
Looping
Varispeed

Assume a cycle of 1024 samples

(1) Process 567 samples, change parameter, process remaining 457 samples. This is done per plugin (not the whole session) [4].

(2) When reaching the loop point, run for 123 samples, loop-locate, process 901 samples. – This happens session-wide (all processors).

(3) is new in Ardour6. When you play at speed 125%, Ardour runs for 1024 * 125% = 1280 samples and resamples the result to output 1024 samples. This likewise affects all processors of the session.

so in summary: don’t automate the plugin, don’t loop, don’t vari-speed.

–

[4] LV2 plugins can ask to ignore this sample-accurate automation: http://lv2plug.in/ns/ext/buf-size#coarseBlockLength . LV2 plugins could also use time-stamped event-sequences instead of classic parameters. VST3 also offers time-stamped changes.

x42 · October 20, 2020, 4:28pm

The do now, but depending on your OS you may have to compile them from source, still, since the provided binaries depend on recent system libs.

calimerox · October 20, 2020, 7:40pm

I m on linux! thanks , I will test them out!!

calimerox · October 20, 2020, 7:57pm

hmm it still seems to be the gui out of place… but not sure, it might be my specific configuration…

x42 · October 20, 2020, 8:54pm

At least the font renders nicely large

Is that self-compiled version or their binary? Do you perhaps have a HiDPI screen or a multi-screen display with effective large resolution which may trigger the plugin to scale up?

I did local-compile using the JUCE project (not cmake) and that works

well, the plugins load and the GUI shows, I don’t have an ambisonics system to actually test it.

calimerox · October 20, 2020, 8:59pm

haha yes it s a hidpi 4k screen, this might be the cause…

I just copied there linux version from here

and followed the readme , copying the files in the vst folder etc. so no compiling!

this might be still the old version…?

x42 · October 20, 2020, 9:28pm

No. That would not load at all.

Yes. JUCE tries to query the scale using

/usr/bin/dconf read /com/ubuntu/user-interface/scale-factor
/usr/bin/gsettings get org.gnome.desktop.interface scaling-factor

…and falls back to use a scale-factor depending on display’s DPI. There does not seem to be an easy way to override this. Also JUCE assumes that the host “knows” about the scale factor. The relevant code is

github.com

juce-framework/JUCE/blob/b8206e3604ebaca64779bf19f1613c373b9adf4f/modules/juce_gui_basics/native/x11/juce_linux_XWindowSystem.cpp#L916-L980


static double getDisplayScale (const String& name, double dpi)

{

    if (name.isNotEmpty())

    {

        // Ubuntu and derived distributions now save a per-display scale factor as a configuration

        // variable. This can be changed in the Monitor system settings panel.

        ChildProcess dconf;



        if (File ("/usr/bin/dconf").existsAsFile()

            && dconf.start ("/usr/bin/dconf read /com/ubuntu/user-interface/scale-factor", ChildProcess::wantStdOut))

        {

            if (dconf.waitForProcessToFinish (200))

            {

                auto jsonOutput = dconf.readAllProcessOutput().replaceCharacter ('\'', '"');



                if (dconf.getExitCode() == 0 && jsonOutput.isNotEmpty())

                {

                    auto jsonVar = JSON::parse (jsonOutput);



                    if (auto* object = jsonVar.getDynamicObject())

This file has been truncated. show original

github.com

juce-framework/JUCE/blob/b8206e3604ebaca64779bf19f1613c373b9adf4f/modules/juce_gui_basics/native/x11/juce_linux_XWindowSystem.cpp#L2189-L2195


    d.dpi = ((static_cast<double> (crtc->width)  * 25.4 * 0.5) / static_cast<double> (output->mm_width))

          + ((static_cast<double> (crtc->height) * 25.4 * 0.5) / static_cast<double> (output->mm_height));



auto scale = DisplayHelpers::getDisplayScale (output->name, d.dpi);

scale = (scale <= 0.1 ? 1.0 : scale);



d.scale = masterScale * scale;

system · November 17, 2020, 9:28pm

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.