Amp/cabinet simulators ? (Guitarix ?)

[x42]

And, the stance they give is absolutely stupid, and, they know it. At least, there is not a single plugin out there witch is really self-contained.

citation needed

In reality it's quite the opposite. There are only about 10-15 plugins on GNU/Linux which do depend 3rd party libraries and there are zero on other OS, that's simply because you cannot rely on ABI compatible libraries to be available.

The only libraries which you must use are the windowing system (client/server protocol needs to match): libX11 on GNU/Linux, Cocoa on OSX/macOS ws2_32/winmm on Windows). Also libc is generally safe.

Try running `nm` or `objdump` or `otool` on various plugins. Many of them even use -static-libgcc, -static-libsdc++ or similar options to be completely standalone, particularly on Windows where you may otherwise get a "MSVC runtime 4711 dll missing". Linux g++ /5 is a similar nest of rats as is libc++ vs libstdc++ on OSX/macOS.

The next issue is symbol visibility, particularly when loading multiple plugins into the same memory space: Only the entry-point should be exposed.
Writing proper plugins is hard, news at 11.

[tramp]

citation needed

In reality it's quite the opposite. There are only about 10-15 plugins on GNU/Linux which do depend 3rd party libraries and there are zero on other OS, that's simply because you cannot rely on ABI compatible libraries to be available.

Just name one which not depend on a third party library, including your owns?

Indeed, you know, LV2 is come up with the promise to give plugin developers the freedom to develop there plugs with the GUI lib they are used to use. Your stance of "plugs have to be self contained" comes a way later.

It's a pity you are compromised by "Harrison"

Note, I'm in no way interested in writing multi platform plugs, I'm a linux only dev, so, leave me alone with your windows stuff. Try to port your recruitments of windows or MAC, is, what makes me suspect you are a

[x42]

,

Ardour, as with it Mixbus using GTKmm, as widget library to make some money. Therefore they distribute binary's in the manner like windows providers does.

or OSX or iOS etc or actually many other Linux vendors.

The motivation is to have specific hand-picked version of libraries. The vast majority of Ardour bugs was a result of distros mixing various libraries without understanding the relationships, in particular for realtime applications. You will find that projects which do have a similar long list of dependencies (Firefox, Blender etc) do the same. It's the only sane approach for a complex application that needs to be reliable.

Now, today, commercial DAW developers expect from plugin developers that they has to develop there own widget library. This is, in my view totally stupid. In my view, the other way round would make sense, if needed.

Which gtk widgets do you actually use in guitarix? They're all custom widgets are they not?

The actually stupid part is that from a FLOSS perspective there is no reasons for plugins at all. The source is available and could be directly built into the workstation. The commercial idea behind plugins is actually that you can mix various proprietary projects without sharing source.

The whole concept to load a couple of random binary blobs (even if you have the source) into the memory space of another application and expect them to do realtime processing and safely interact with a GUI and with each other is kinda crazy. It's a proprietary model, with FLOSS it would not be needed.
And yes it's rather demanding on the developer's side: If you want to create plugins you do need to play by the rules. You can't mix ABIs, nor make any assumptions on 3rd party libs. Developing some widgets and event-system is trivial compared to the details otherwise involved.

They expect from plugin developers to "not use what we use because we use it" .

It's actually plugin-devs who out of respect for other plugin devs don't do that. The host is a single entity with known properties to target, but plugins don't and cannot know about each other, so they must be self-contained.

As for toolkits suitable for audio plugins: The only one that does get most of the detailed issues right is JUCE (and some derivatives like DPF) -- It's also the only one that does have actual useful widgets for plugin-UIs.

Ardour, for example use for the binary's they provide, old, outdated library's which are normally part of your system,

They may be old, but they're hand-picked. And no, most of them won't normally be part of a default installed system.

I know, this isn't what you all wont to hear here, but, we are on the way to lose the control over our so beloved open source model of audio engineering.

Why do you think that, can you elaborate?
Large parts of this is actually because of the GPL and it's all free software. I fail to see the correlation that you imply.

Unless you didn't mean the development process but integration. But a plugin is never in control and never has been. Isn't that the whole point of a plugin (vs standalone app)?

I'm, as a plugin and host developer, do my best to provide compatible "binary's" for the majority of users, but, to be honest, that isn't possible for arch linux.

It definitely is possible, just look at all the JUCE plugins. Also various standalone ones, helm, zyn-fusion.. Just don't make any assumptions about the system and it'll also run on *BSD, Windows, OSX and every Linux system out there.

If you do depend on 3rd party libs and dynamically link against them or make assumptions about API/ABI, then yes, you can only target a specific system.

[x42]

citation needed

In reality it's quite the opposite. There are only about 10-15 plugins on GNU/Linux which do depend 3rd party libraries and there are zero on other OS, that's simply because you cannot rely on ABI compatible libraries to be available.

Just name one which not depend on a third party library, including your owns?

All of the x42-plugins only depend on libc, libX11 and libGL. They're required (you cannot statically link against X11/openGL) but those are therefore guaranteed to be ABI compatible (thanks to Kronos group specs for GL and X11 consortium) since about 2002 and 1987 respectively.

Grab a binary e.g. GNU/Linux 64bit from http://x42-plugins.com/x42/x42-whirl and see for yourself: https://pastebin.com/Aneg7vU7
except for glibc (versioned), the only other dynamic symbols are some gl* and a handful of X* calls which are guaranteed to b API & ABI independent.

if you run `ldd` you'll see some indirect libraries which are pulled in depending on the local system (e.g. libX11.so usually just depends on other libs which implements the spec and may in turn depend on more libs)

All DPF plugins are similar, e.g. zam-plugins also only depend on mandatory libs, as do the ones from falktx on KXStudio (all statically linked).
The only LV2s which I know to depend on 3rd party libs are ams-lv2, amsynth, calf, eq10q, guitarix, ingen, newtonator, and vocproc. There are probably a few others.

Indeed, you know, LV2 is come up with the promise to give plugin developers the freedom to develop there plugs with the GUI lib they are used to use. Your stance of "plugs have to be self contained" comes a way later.

You can use whatever libs you want, provided they're usable in context of plugins. The requirement to be self-contained is obvious and intrinsic for any plugins that need to be able co-exist. It's not LV2 specific and has always been a requirement for plugins.

Say you write a plugin that needs ffmpeg and uses the newer libswresample2 interface and there's another plugin that uses the older libswresample1 API. Now what? distros may even package both versions, and you can compile and link, but if you load both at the same time, you usually get in trouble. QT4/QT5 gtk2/3 same thing: They can be installed at the same time, but cannot co-exist in a single application. You may also remember https://github.com/FFTW/fftw3/issues/16 which caused crashes when multiple plugins that don't know about each other used it as shared library (static builds were not affected).

Long story short, distro provided libraries do not solve any of the issues. The only way to ensure reliable operation is to statically link and make plugins self-contained (or process-separate plugins, but then you get context switches which are very expensive, even on modern machines).

It's a pity you are compromised by "Harrison"

I'm not, I also don't see how this would be relevant in a technical discussion.

Note, I'm in no way interested in writing multi platform plugs, I'm a linux only dev, so, leave me alone with your windows stuff. Try to port your recruitments of windows or MAC, is, what makes me suspect you are a

Fair enough. I still hope guitarix will in the long run move away from gtkmm and settle for a standard API (libX11 or wayland). It's a really cool project and it would be a pity to see it fall short just because of technicalities.

I do care about free software for artists, not Operating Systems artists use.. And it really makes no difference, clean gnu code builds pretty much everywhere these days. There's nothing Linux specific to audio plugins. Also, who am I to push a user to a specific OS if s/he wants to use free-software. I also don't want anyone to push me away from GNU/Linux either.

Anyway, this gets off topic and personal. Stuff like that is not relevant here and better discussed over a beer. Cheers!

[x42]

Mixbus only exists for regular and gcc5 systems. gcc7 might be following along gcc5, I don't know. But there was a drastic change in binaries between previous regular systems and the systems using the new libc and gcc5.

Yep. It's rather a gcc4 or earlier vs. gcc5 or later. gcc5 broke the binary compatibility with default options. Actually only c++ is affected, libstc++.

It's only relevant when mixing different software. Ardour/Mixbus gcc4 version runs just fine on a modern gcc7 system, but it cannot load plugins which (A) are written in C++, and (B) were compiled with a later version of g++ (using C++11) and (C) depend on external libraries (libstdc++ itself is dual ABI gcc4/5, it's only 3rd party libs that are the problem, most commonly libsigc++ and glibmm)

[funkmuscle]

yep Mixbus 32c works greats. my work around is to use do all the recordings in Ardour then import to Mixbus.
I don't really need the Gx Uis even though they look cooler than the generic UIs from Ardour/Mixbus but all good!

I'm just still stuck with why only the 2 bass amp sim from Gx UIs work when they're all build the same?
Again not a problem but just strange.

[glowrak guy]

Anyway, this gets off topic and personal. Stuff like that is not relevant here and better discussed over a beer. Cheers!

On my side of the tracks, that would mean hosting a 'kegger'

I think a Guitarix mini-distro would be popular/useful, perhaps
with two versions, to accomodate the issues being discussed.
And maybe integrate with MOD products on some level.
Tons of man-hours needed?

(with hal and chrome active, I can jam with netflix etc
from ubuntu studio, maybe a live cd with those capabilities
and network-jam tech would weaken some corona blues?)
Cheers

[Basslint]

I'll use this thread to recommend the amazing amp and pedal sims by Oleg Kapitonov, all FLOSS -> https://kpp-tubeamp.com/

[tramp]

I'll use this thread to recommend the amazing amp and pedal sims by Oleg Kapitonov, all FLOSS -> https://kpp-tubeamp.com/

+1
As this thread is necrose bumped, and nearly all informations here been outdated, it's good that at least some useful information is added.