[LAD] Carla (was... whatever)

[Len Ovens]

I agree that Carla has a long list of deps. However, it is worth building
on one's own system and excluding some features. This is very easy to do,
if Carla doesn't find a depend, it just leaves features requiring those
depends out. This does mean the user does have to:
- build their own
- know what they need
- know why they are using Carla in the first place
- understand that Carla _tries_ to make up for the mistakes
of plugin developers or distro packagers. It is a tool
to make the best of a broken situation.

In general, a better solution is to use the OS the plugin is made for or
use plugins made for your OS of choice.

--
Len Ovens
www.ovenwerks.net

[Filipe Coelho]

Post by Len Ovens
I agree that Carla has a long list of deps. However, it is worth
building on one's own system and excluding some features. This is very
easy to do, if Carla doesn't find a depend, it just leaves features
requiring those depends out.

I have to confirm this, since I am the author of Carla I know what I am
talking about ;)

Carla's dependencies are all optional, only needs a compiler to get the
basic stuff working.
OSC support is done by liblo, so liblo is needed if you want OSC.
Same for a alsa and pulseaudio (using a bundled RtAudio).

The toolkits, as Paul said before, is to be able to load different kinds
of toolkits that LV2 plugins use.
Usually hosts give that task to suil, so you don't see the dependency
list directly.
But when installing jalv or qtractor for archlinux, because they depend
on suil, expect it to pull gtk2, gtk3, qt4 and qt5.

Carla's frontend uses PyQt (either version 4 or 5), so you need that if
you want the full GUI.
But carla works just fine without it, you just have to load single
plugins or previously saved project files...

The dependency on zynaddsubfx is a leftover from when I started
experimenting zynaddsubfx as a plugin.
I started it as an internal carla plugin to see how far I could take it,
and how well it could work as a plugin.
It needed quite a few changes, which are now all upstream. Eventually I
made the new code that makes zyn work as plugin, officially, without
using Carla.
The plan is to make all the extra internal plugins (including zyn) a git
submodule, and disable them by default on new builds.
This is already the case on the FreeBSD ports.

Post by Len Ovens
 - build their own
 - know what they need
 - know why they are using Carla in the first place
 - understand that Carla _tries_ to make up for the mistakes
    of plugin developers or distro packagers. It is a tool
    to make the best of a broken situation.

This is correct.

Carla is and will remain an advanced tool.
I have no intentions to dumb it down, I hate that practice myself.
All the options provided are very technical, and errors it reports when
something misbehaves are very technical too.

Carla was born out of a personal need for a modular host that loaded all
kinds of plugins.
That need (for me at least) still stands.
It might be that you don't really have a need for it, so just don't use
it ;)

[Ralf Mardorf]

Post by Filipe Coelho
But when installing jalv or qtractor for archlinux, because they
depend on suil, expect it to pull gtk2, gtk3, qt4 and qt5.

suil comes with a dedicated version itself and as far as I notice
doesn't require ntk-git or even qt4 and qt5 at the same time, even not
by it's one and only hard dependency lv2, let alone that even qt4 is an
optional dependency. Following the dependency chain ... I might be
mistaken .. even GTK3 seems not to be a hard dependency. Did I miss
something by suil's dependency chain?

[Simon van der Veldt]

If you want to embed toolkit A in toolkit B you'll need both.
Another reason for plugins to please not use a massive toolkit :)

Post by Ralf Mardorf

Post by Filipe Coelho
But when installing jalv or qtractor for archlinux, because they
depend on suil, expect it to pull gtk2, gtk3, qt4 and qt5.

suil comes with a dedicated version itself and as far as I notice
doesn't require ntk-git or even qt4 and qt5 at the same time, even not
by it's one and only hard dependency lv2, let alone that even qt4 is an
optional dependency. Following the dependency chain ... I might be
mistaken .. even GTK3 seems not to be a hard dependency. Did I miss
something by suil's dependency chain?
_______________________________________________
Linux-audio-dev mailing list
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[Filipe Coelho]

Post by Ralf Mardorf

Post by Filipe Coelho
But when installing jalv or qtractor for archlinux, because they
depend on suil, expect it to pull gtk2, gtk3, qt4 and qt5.

suil comes with a dedicated version itself and as far as I notice
doesn't require ntk-git or even qt4 and qt5 at the same time, even not
by it's one and only hard dependency lv2, let alone that even qt4 is an
optional dependency. Following the dependency chain ... I might be
mistaken .. even GTK3 seems not to be a hard dependency. Did I miss
something by suil's dependency chain?

You're missing the fact that all of these are optional dependencies.
Nothing in carla is a real build-time dependency.

But obviously, if you want to load gtk2 uis on carla, you need gtk2.
Same goes for qt4, qt5 and gtk3. There is no way around this, you need
the toolkit during build-time in order to support it.

ntk-git (and also fftw3, mxml and zlib) are dependencies of zynaddsubfx.
you can take those out if you don't care about zyn inside carla.

[Ralf Mardorf]

Post by Filipe Coelho

Post by Ralf Mardorf

Post by Filipe Coelho
But when installing jalv or qtractor for archlinux, because they
depend on suil, expect it to pull gtk2, gtk3, qt4 and qt5.

suil comes with a dedicated version itself and as far as I notice
doesn't require ntk-git or even qt4 and qt5 at the same time, even
not by it's one and only hard dependency lv2, let alone that even
qt4 is an optional dependency. Following the dependency chain ... I
might be mistaken .. even GTK3 seems not to be a hard dependency.
Did I miss something by suil's dependency chain?

You're missing the fact that all of these are optional dependencies.
Nothing in carla is a real build-time dependency.
But obviously, if you want to load gtk2 uis on carla, you need gtk2.
Same goes for qt4, qt5 and gtk3. There is no way around this, you need
the toolkit during build-time in order to support it.
ntk-git (and also fftw3, mxml and zlib) are dependencies of
zynaddsubfx. you can take those out if you don't care about zyn inside
carla.

Please don't get me wrong, sometimes a plugin's GUI could be an
advantage, but it also could be annoying. IMO plugins more often could
be more comfortable, with an UI provided by the host.

[Filipe Coelho]

Post by Ralf Mardorf

Post by Filipe Coelho

Post by Ralf Mardorf

Post by Filipe Coelho
But when installing jalv or qtractor for archlinux, because they
depend on suil, expect it to pull gtk2, gtk3, qt4 and qt5.

suil comes with a dedicated version itself and as far as I notice
doesn't require ntk-git or even qt4 and qt5 at the same time, even
not by it's one and only hard dependency lv2, let alone that even
qt4 is an optional dependency. Following the dependency chain ... I
might be mistaken .. even GTK3 seems not to be a hard dependency.
Did I miss something by suil's dependency chain?

You're missing the fact that all of these are optional dependencies.
Nothing in carla is a real build-time dependency.
But obviously, if you want to load gtk2 uis on carla, you need gtk2.
Same goes for qt4, qt5 and gtk3. There is no way around this, you need
the toolkit during build-time in order to support it.
ntk-git (and also fftw3, mxml and zlib) are dependencies of
zynaddsubfx. you can take those out if you don't care about zyn inside
carla.

Please don't get me wrong, sometimes a plugin's GUI could be an
advantage, but it also could be annoying. IMO plugins more often could
be more comfortable, with an UI provided by the host.

I agree there, but most users don't.

In case you did not notice from me and Rui, we Portuguese people like to
support as much stuff as possible :)

There are not any lv2 gtk3 plugin UIs yet, but Carla already supports those.
It supported Qt5 UIs before any other host, because Carla's ui-bridge
makes it easy to support a new UI type - though it needs the UI to work
without instance-access.

Anyway, you were complaining about the many toolkit dependencies, now
you know why.
As long as there are plugins using these toolkits, users will want to
use them, so I end up supporting them in the end.

[Ralf Mardorf]

Post by Filipe Coelho
In case you did not notice from me and Rui, we Portuguese people like
to support as much stuff as possible :)

Not really. For example, record a few audio tracks with Qtractor using
a low frame size, while you mute several tracks to avoid xruns. Then
for mixing purpose increase the frame size and enable all tracks. Oops,
the already not that good latency compensation, gets a little bit more
out of sync, in relation to the MIDI tracks ;).

[Ralf Mardorf]

Post by Ralf Mardorf

Post by Filipe Coelho
In case you did not notice from me and Rui, we Portuguese people like
to support as much stuff as possible :)

Not really. For example, record a few audio tracks with Qtractor using
a low frame size, while you mute several tracks to avoid xruns. Then
for mixing purpose increase the frame size and enable all tracks. Oops,
the already not that good latency compensation, gets a little bit more
out of sync, in relation to the MIDI tracks ;).

Do you claim that Portuguese people prefer quantity rather than quality
over quality rather than quantity?

[Filipe Coelho]

Post by Ralf Mardorf

Post by Ralf Mardorf

Post by Filipe Coelho
In case you did not notice from me and Rui, we Portuguese people like
to support as much stuff as possible :)

Not really. For example, record a few audio tracks with Qtractor using
a low frame size, while you mute several tracks to avoid xruns. Then
for mixing purpose increase the frame size and enable all tracks. Oops,
the already not that good latency compensation, gets a little bit more
out of sync, in relation to the MIDI tracks ;).

Do you claim that Portuguese people prefer quantity rather than quality
over quality rather than quantity?

You're getting really offtopic here, ignoring all the rest I said and
only going for a minor joke in the post...

Anyway, latency compensation is likely the most complicated thing you
can do as a plugin host / DAW.
afaik Ardour only now started a proper implementation of it.
A commercial major DAW I use from time to time only recently implemented it.

And quantity over quantity does not translate well into software.
For a host that supports LADSPA and OSC for example, implementing DSSI
would be very easy because it reuses LADSPA and OSC directly.
Often you only need to implement a format or specific extra feature
once, and it stays there for a long time.
This is how the linux kernel can support so many devices.

[Fons Adriaensen]

Post by Filipe Coelho
You're missing the fact that all of these are optional dependencies.
Nothing in carla is a real build-time dependency.

So that means that the following (from The AUR PKGBUILD file) is
mostly wrong:

depends=('file' 'fftw' 'fluidsynth' 'glu' 'liblo' 'linuxsampler' 'mxml' 'ntk-git' 'projectm' 'python' 'python-pyqt5' 'qt5-svg' 'zlib')
makedepends=('gtk2' 'gtk3' 'python-pyliblo' 'python-rdflib' 'qt4' 'zynaddsubfx')
optdepends=(
'gtk2: LV2 GTK2 UI support'
'gtk3: LV2 GTK3 UI support'
'python-pyliblo: OSC support'
'python-rdflib: LADSPA-RDF support'
'qt4: LV2 QT4 UI support'
'zynaddsubfx: ZynAddSubFX banks'
)

Even if this is 'WoefulDerelict' (the packager) mixing things up,
I still don't get why fluidsynth, linuxsampler and zynaddsubfx are
there - unless upstream somehow indicated they should be.
You mentioned you worked on having zyn 'inside carla', but why
should any synth ever be a built-in part of a plugin host ?
Same about projectm (which seems to be some music visualisation
gadget, nothing at all to do with even semi-pro audio).

If you could provide a correct version of the above that would
be most useful.

Ciao,

[Filipe Coelho]

Post by Fons Adriaensen

Post by Filipe Coelho
You're missing the fact that all of these are optional dependencies.
Nothing in carla is a real build-time dependency.

So that means that the following (from The AUR PKGBUILD file) is
depends=('file' 'fftw' 'fluidsynth' 'glu' 'liblo' 'linuxsampler' 'mxml' 'ntk-git' 'projectm' 'python' 'python-pyqt5' 'qt5-svg' 'zlib')
makedepends=('gtk2' 'gtk3' 'python-pyliblo' 'python-rdflib' 'qt4' 'zynaddsubfx')
optdepends=(
'gtk2: LV2 GTK2 UI support'
'gtk3: LV2 GTK3 UI support'
'python-pyliblo: OSC support'
'python-rdflib: LADSPA-RDF support'
'qt4: LV2 QT4 UI support'
'zynaddsubfx: ZynAddSubFX banks'
)
Even if this is 'WoefulDerelict' (the packager) mixing things up,
I still don't get why fluidsynth, linuxsampler and zynaddsubfx are
there - unless upstream somehow indicated they should be.

From what I understand, you cannot specify multiple packages as
optional dependency to get a feature working.
I mean, for zynaddsubfx carla uses mxml, fftw, zlib, ntk (or fltk) and
zynaddsubfx itself.

liblo, fluidsynth, glu, linuxsampler and projectm should be optional
dependencies there. (not to mention zyn stuff)
but to be honest, people don't usually care for installing a few extra
libraries.

Post by Fons Adriaensen
You mentioned you worked on having zyn 'inside carla', but why
should any synth ever be a built-in part of a plugin host ?

I mention on a different reply, that it was initially a test to see if
and how zyn could work as a plugin.
The reason why we have zynaddsubfx as a plugin (officially supported
upstream) was because of this initial investigation.
And of course the help of Mark to make sure we were doing things properly.

The plugin is still available there (on linux builds) for backwards
compatible reasons.
Soon I will remove it from the default build and make projects that use
that plugin convert automatically to the LV2 version.
But this has not happened yet.

On MacOS and Windows builds I will still keep those plugins, so that the
users that have not installed any other plugins can still make some noise.

Post by Fons Adriaensen
Same about projectm (which seems to be some music visualisation
gadget, nothing at all to do with even semi-pro audio).

projectm "dependency" comes from a plugin that is included with carla
(for now).
that being https://github.com/DISTRHO/ProM/

As I said before, eventually these extra plugins will be moved into a
git submodule.
They will not be built by default, and existing projects (when the
internal plugin is not found) will be converted automatically to their
LV2 version.

Post by Fons Adriaensen
If you could provide a correct version of the above that would
be most useful.

I left a comment on the carla-git package on AUR regarding
optional-dependency changes.