Auburnsounds plugins now working in ardour

The auburnsounds plugins just got updated and now work in Ardour and Mixbus.

The issue report was sent last month, so it took over a month for this new update which came out 2 days ago. All their three plugins no longer cause Ardour and Mixbus to crash.

in case anyone has tried these plugins in Linux —

– if you spot a problem with a plugin that crashes ardour/mixbus feel free to report them to the developers of those plugins as that is the only way plugins would get fixed. There’s a tendency among users to presume the issue is first with Ardour/Mixbus, but the thing is plugins in Ardour/Mixbus run within the same space as the main daw, so there is no plugin-crash protection.(the argument is it helps to reduce latency)
https://ardour.org/plugins-in-process.html

Ardour/Mixbus staff do not take care of fixing third-party plugins, that’s the job of end-users to send the report. There are small plugin teams who cross-build their plugins and do not have resources to test their plugins for Ardour on Linux, so we need to be a little more pro-active about it and inform them of issues.

cheers

2 Likes

Thanks, I never heard of these plugins. Couture looks really excellent!

Please cease to spread misinformation, in particular information that was corrected in the past: Ardour5 crashes suil error. tl;dr: We do care and sometimes also work with plugin-devs.

In-process processing has nothing to do with the case at hand. The article was written to explain why Ardour does not offer crash-protection (aka sandboxing).

Not quite, DSP load (time to process vs time available to process) is reduced by not switching process context. Reliability is improved and one can run more plugins. Latency remains unaffected.

I just read that article for the first time. The simple answer given:

It doesn’t scale up to work with large sessions with low latency settings.

And this in the technical notes

It may work for 4 track Bitwig session with 12 plugins or thereabouts but it’s not suitable for any large scale work, and certainly not at the very low latency settings that Ardour can be run with.

Reaper can have humongous sessions without noticeable latency, so is the latency that would be introduced by using sandboxing in Ardour down to some fundamental design element of Ardour’s audio engine rather than being a general issue with sandboxing?

No, it has nothing to do with Ardour’s design.

Read the article. The math is there. The math isn’t about Ardour, it covers how all audio processing on any general purpose computer/operating system takes place. You can’t wish away context switches, at least not if the goal is process-level separation to prevent plugins from being a part of the DAW.

Historically, Reaper didn’t even run plugins in realtime anyway - it pre-rendered everything, creating more control latency (i.e. time from tweaking a parameter to the result being audible). This was changed in Reaper some years ago, at least in as much it is no longer necessary to do this, but I still don’t know if it is the default.

the auburnsounds plugins are closed-source, unlike the v1 plugins – what I meant of course in simple terms is the logical step of contacting plugin developers directly – even if their demos are failing. These commercial plugins got fixed, but only because I’m their end-customer… has nothing to do with ardour. I know you do “care” for opensource/free software plugins, but I am also writing to help encourage users to mind taking also a pro-active stance on contacting plugin developers directly on their own.

thanks!

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