Acoustica for LINUX ??

Official support for: acondigital.com
enrico2010
KVRer
Topic Starter
4 posts since 25 Jan, 2010

Post Thu Jan 06, 2022 9:47 am

Happy New Year dear Acoustica Team -
since I found out about Acoustica in the year 2007/2008 I was impressed about this slim and powerful piece of Software.
Coming to this time as a voice over Artist and Audio Engineer from SoundForge the only thing
I was missing was the 'scroll into the selection with mouse wheel - function'
I posted this as a useful wish to the development team of Acoustica to this time and bang !! - two weeks later it was implemented.
Since this days I edited tons of Audio material with no crashed and wonderful set of great working plug-ins - I never looked back.
I just saw other audio editors getting huge and clumsy - slow in comparison - I never did regret.
During all this time I was always willing to relocate my whole work environment to Linux (that's because of my background as a Software Engineer -> only a few lucky ones may make a living from Recording only), but never could do that in cause of the lack of very basic Audio Tools and no VST PlugIns.
In the last years this changed and I started to work with Ardour and as well Tracktion Wavform DAW as creativity machine.
There're some very good VST3 Plug-in Producers (e.g. uhe) now, which are doing great stuff as well for Linux.
There are other diffrent DAWs as well available e.g. BitwigStudio .... which shows that there are many
people out there, who ware buying and donating for professional Software on Linux.
To make a long story short -> would you take in consideration to support Linux with Arcoustica (as the only professional Audio Editor on Linux then) ??

Best Hendrik

User avatar
stian
KVRian
1299 posts since 1 Jan, 2005 from Norway

Post Wed Jan 12, 2022 7:49 am

Thanks for the kind words about Acoustica! The major problem with Linux on the desktop is that we would have to support so many different distributions. Since Acoustica uses JUCE and is written in standard C++, it would be possible to build for Linux after a fairly short development time, I suppose. My worries is making it compatible with all distributions and supporting the platform in the long run.

Best,
Stian

imrae
KVRAF
2055 posts since 2 Jul, 2010

Post Wed Jan 12, 2022 7:57 am

I wonder if flatpak would be a useful solution to that problem?

(I am entirely sympathetic to the support concerns! Some packages handle this by only having one or two officially-supported distributions, and leaving adaptation to other distros as an exercise for end users / community.)

User avatar
audiojunkie
KVRAF
3310 posts since 19 Apr, 2002 from Utah

Post Wed Jan 12, 2022 11:56 am

stian wrote: Wed Jan 12, 2022 7:49 am Thanks for the kind words about Acoustica! The major problem with Linux on the desktop is that we would have to support so many different distributions. Since Acoustica uses JUCE and is written in standard C++, it would be possible to build for Linux after a fairly short development time, I suppose. My worries is making it compatible with all distributions and supporting the platform in the long run.

Best,
Stian
I'm going to quote from a very long and interesting thread that you may find useful. These are things that I've gathered regarding this topic:

https://forum.cockos.com/showthread.php?t=259967

----BEGIN QUOTE-----
So, as far as dealing with Proprietary/commercial/closed-source binaries across distros on Linux, current thought argues for/against the following strategies:

A. Build a separate binary for every OS, chip architecture, or distro release. This is the Original problem and currently the only current guaranteed way to make sure everything will work. It is also so counter productive that NO ONE will do it.

B. Develop something like the OBS (Open Build System) https://build.opensuse.org/ But cover every OS, chip architecture, or distro release. The OBS seems to be really cool and has a lot of potential, but doesn't support everything that is needed, and has its own set of problems.

C. Listen to Linus when he says: Don't "Break Userspace!" In other words Library developers need to maintain 100% backwards compatibility No Matter What, and distro developers need to stick to this core set of compatible libraries.

D. Containerization such as Flatpak, SNAP, etc.

E. While waiting for better solutions to come along, use the recipe for hosts and plug-ins to play nicely together:

1. Keep dependencies minimal (for both host and plugins) and don't expose unnecessary symbols in either (-fvisibility=hidden etc, and don't assume that just 'stripping' a binary does anything of the kind)
2. Dynamically link to system libs in preference to requiring custom library versions or using LD_LIBRARY_PATH hacks
3. Build to the earliest version of system libs you want to be compatible with (most APIs will maintain compatibility in future versions, the reverse is seldom true)
4. Statically link, only if you absolutely have to, and if its compatible with licenses etc.
5. Hosts should load plug-ins with dlopen(RTLD_LOCAL | RTLD_LAZY) as they already do, and that should be enough to keep plug-ins namespaces segregated from one another. There are still some edge cases, like host application vs plugin symbol collisions, but most of these turn out to be rare if the other suggestions are adhered to.

"Then you have something which works at least as well as it does on other platforms. (Intentionally or otherwise, this seems to be what happens with for example Reaper on Linux, the host has minimal dependencies and seems to dynamically link to only a few system infrastructure libs, and by far the vast majority of Linux plug-ins appear to work without problems)."

In addition to this, the Linux binary needs to be compiled for a conservative distro using the older libraries, with the expectation that it should mostly work on a newer distro, like Arch, with bleeding edge binaries.

I would add to this that in all fairness, commercial developers need to provide a way for users to test the software on their own distros by providing a way to demo the software on their personal distro. Refund requests are probably the reason why developers are afraid to label the their software anything other than "experimental" or provide more than limited Linux support. But that doesn't encourage the customer to buy software, even if it limits their liability. There needs to be a way for the consumer to feel more safe that their purchase will work on their distro. Labeling the build as supporting only Ubuntu cuts into their sales.
-----END QUOTE-----

So, my question would be, couldn't you do option D. or option E.? If you don't have any external plugins that are needed, option Flatpak would be a good choice. But either way, since you use JUCE, you could use as few libraries as possible, compile on an older, conservative distro (like Ubuntu), and then have a try before you buy option where the user is expected to test to see if it works for their distro. Arch based distros are bleeding edge and shouldn't have any problems with the libraries that Ubuntu would use.
C/R, dongles & other intrusive copy protection equals less-control & more-hassle for consumers. Company gone-can’t authorize. Limit to # of auths. Instability-ie PACE. Forced internet auths. THE HONEST ARE HASSLED, NOT THE PIRATES.

Return to “Acon Digital”