Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

[Paul Davis]

> Am 09.12.2017 um 23:59 schrieb Ralf Mardorf:
>
>> On Sat, 9 Dec 2017 09:44:02 -0500, Paul Davis wrote:
>>
>>> ​As a plugin host, Carla attempts (and generally does) allow plugins
>>> to use many different toolkits for their own GUIs.
>>>
>> Do you think that Fons is an idiot, not being aware of this?
>
>
​No, I think you're the only person I've ever blocked email from​, so
replying to me in this fashion goes unseen unless someone chooses to reply
to your reply, which is mercifully infrequent.
​
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

[Hermann Meyer]

Am 09.12.2017 um 23:59 schrieb Ralf Mardorf:

On Sat, 9 Dec 2017 09:44:02 -0500, Paul Davis wrote:

​As a plugin host, Carla attempts (and generally does) allow plugins
to use many different toolkits for their own GUIs.

Do you think that Fons is an idiot, not being aware of this? The issue
still remains, the more dedicated dependencies, the more possible
issues. However, let's ignore the GUI issue, for what purpose are
fluidsynth and linuxsampler dependencies of a host? Especially
linuxsampler is a serious issue for a lot of distros, regarding the
customized/invalid license. Actually the official Arch Linux community
repository provides linuxsampler, but you unlikely could mention much
more major distros supporting it by their official repositories.


As already mentioned, this are all optional dependency's. Even the samplers.
Think about yourself, for what should a audio plugin host use samplers??


Keep in mind that some distro's, such as Arch Linux follow the KISS
principle, IOW an app usually is build with the upstream defaults,
without excluding features.


This is fully understandable, but, should this lead a developer to 
disable features by default?
Even then, distro maintainer usually trying to enable as much features 
as possible, even when they been disabled by default.




___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Carla (was... whatever)

[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 :)

On Sun, Dec 10, 2017 at 12:21 AM, Ralf Mardorf 
wrote:

> On Sat, 9 Dec 2017 18:00:32 +0100, Filipe Coelho wrote:
> >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
> Linux-audio-dev@lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Carla (was... whatever)

[Ralf Mardorf]

On Sat, 9 Dec 2017 18:00:32 +0100, Filipe Coelho wrote:
>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
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

[Ralf Mardorf]

On Sat, 9 Dec 2017 09:44:02 -0500, Paul Davis wrote:
>​As a plugin host, Carla attempts (and generally does) allow plugins
>to use many different toolkits for their own GUIs.

Do you think that Fons is an idiot, not being aware of this? The issue
still remains, the more dedicated dependencies, the more possible
issues. However, let's ignore the GUI issue, for what purpose are
fluidsynth and linuxsampler dependencies of a host? Especially
linuxsampler is a serious issue for a lot of distros, regarding the
customized/invalid license. Actually the official Arch Linux community
repository provides linuxsampler, but you unlikely could mention much
more major distros supporting it by their official repositories.

Keep in mind that some distro's, such as Arch Linux follow the KISS
principle, IOW an app usually is build with the upstream defaults,
without excluding features. This at least could become tricky, as soon
as e.g. a dependency to Steinberg is involved. Maybe not regarding the
distro's policy, but at least regarding hunting for the current
Steinberg download link.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

[Jeremy Jongepier]

On 12/09/2017 02:24 PM, Louigi Verona wrote:
> This is a good point, Fons.
> 
> On Windows it is typical to bundle a program with stable libraries and
> dependencies. Is this strategy thinkable on FLOSS systems?

Yes, think of packaging solutions like Snappy (https://snapcraft.io/),
Flatpak (https://flatpak.org/) or AppImage (https://appimage.org/).

Jeremy



signature.asc
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Carla (was... whatever)

[Filipe Coelho]

On 09.12.2017 15:56, Len Ovens wrote:
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.



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.


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 ;)



___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[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

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

[Paul Davis]

DLL Hell is something entirely different. The term comes from a time where
Windows installers actually installed an applications required libraries in
the "system location". So if application Foo is installed, and uses library
Bar version N, but then you install application Baz, and it uses library B
version N+M, suddenly Foo no longer works.

Modern "application bundle" approaches don't do this, because they keep any
required shared (i.e. non-statically linked) libraries private to the
application (bundle). This is what MacOS has done since its inception, and
it has never suffered from DLL Hell.

The one notable downside is when there are vulnerabilities discovered in
code ... the "traditional" Linux approach means that a system update can
fix all applications in one step, whereas the bundle approach breaks this.


On Sat, Dec 9, 2017 at 8:37 AM, Gordonjcp  wrote:

> On Sat, Dec 09, 2017 at 02:24:37PM +0100, Louigi Verona wrote:
> > This is a good point, Fons.
> >
> > On Windows it is typical to bundle a program with stable libraries and
> > dependencies. Is this strategy thinkable on FLOSS systems?
>
> No, and it's a stupid idea on Windows too, which is why Windows uniquely
> suffers from "DLL Hell".
>
> Just write your software so it doesn't break APIs.
>
> --
> Gordonjcp
>
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

[Paul Davis]

On Sat, Dec 9, 2017 at 6:36 AM, Fons Adriaensen  wrote:

>
> Interesting that you mention carla. I wanted to give it a try some
> months ago. Until I noticed the list of dependencies, see e.g.
> .
>
> This 'Audio Plugin Host' depends on at least five GUI toolkits
> (ntk, gtk2, gtk3, qt4, qt5), a number of soft synths (why ?),
> and some very specific or -git versions of lots of libraries.
> Many of these have similar long dependency lists of their own.
>

​As a plugin host, Carla attempts (and generally does) allow plugins to use
many different toolkits for their own GUIs. To do that, it has to have
small amounts of "stub" code that connect it to each possible toolkit.

This list of dependencies mostly just reflects that, rather than anything
to do with Carla's own implementation.​
​
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

[Neil C Smith]

On Sat, 9 Dec 2017, 13:37 Gordonjcp,  wrote:

> On Sat, Dec 09, 2017 at 02:24:37PM +0100, Louigi Verona wrote:
> > This is a good point, Fons.
> >
> > On Windows it is typical to bundle a program with stable libraries and
> > dependencies. Is this strategy thinkable on FLOSS systems?
>
> No, and it's a stupid idea on Windows too, which is why Windows uniquely
> suffers from "DLL Hell".
>

Er, yes it's thinkable, and you do realise what's being talked about is
quite distinctly different from, in fact opposite to, DLL Hell?

Sometimes I miss my old RiscOS days and their self contained application
bundles!

Best wishes,

Neil

> --
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

[Will J Godfrey]

On Sat, 9 Dec 2017 13:37:30 +
Gordonjcp  wrote:

>On Sat, Dec 09, 2017 at 02:24:37PM +0100, Louigi Verona wrote:
>> This is a good point, Fons.
>> 
>> On Windows it is typical to bundle a program with stable libraries and
>> dependencies. Is this strategy thinkable on FLOSS systems?  
>
>No, and it's a stupid idea on Windows too, which is why Windows uniquely
>suffers from "DLL Hell".
>
>Just write your software so it doesn't break APIs.

I rather thought it was library API changes that were breaking the software -
something I've been a victim of.

-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

[Gordonjcp]

On Sat, Dec 09, 2017 at 02:24:37PM +0100, Louigi Verona wrote:
> This is a good point, Fons.
> 
> On Windows it is typical to bundle a program with stable libraries and
> dependencies. Is this strategy thinkable on FLOSS systems?

No, and it's a stupid idea on Windows too, which is why Windows uniquely
suffers from "DLL Hell".

Just write your software so it doesn't break APIs.

-- 
Gordonjcp

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

[nils]

Yes, that is possible and I wholeheartly lobby for that because library
bugs and mismatches are common and could be avoided.

Ardour does it and I do it in my own programs as well, or at least will
if properly released. If you can copy a library into your source tree
(Python in my case) why would depend to the external ecosystem?

Some Linux distributions  (mostly very small and unknown though) do it
already but the "way of forefathers", the shared library, is still stuck
in peoples head.

Bottom line: It turned out the Windows way of shipping all or most
libs with the program is a really good way to compatibility.

On 12/09/2017 02:24 PM, Louigi Verona wrote:
> This is a good point, Fons.
>
> On Windows it is typical to bundle a program with stable libraries and
> dependencies. Is this strategy thinkable on FLOSS systems?
>
>
>
>
>
>
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

[Louigi Verona]

This is a good point, Fons.

On Windows it is typical to bundle a program with stable libraries and
dependencies. Is this strategy thinkable on FLOSS systems?
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

[Fons Adriaensen]

On Mon, Dec 04, 2017 at 11:52:30AM +0100, Louigi Verona wrote:
 
> for instance, when preparing for the sonoj convention, i had carla start
> crashing on me and i could not complete music examples. i eventually had to
> revert to flstudio to make them.

Interesting that you mention carla. I wanted to give it a try some
months ago. Until I noticed the list of dependencies, see e.g.
.

This 'Audio Plugin Host' depends on at least five GUI toolkits
(ntk, gtk2, gtk3, qt4, qt5), a number of soft synths (why ?),
and some very specific or -git versions of lots of libraries.
Many of these have similar long dependency lists of their own.

Expecting this sort of software to be stable, secure and maintainable
(assuming you manage to build it at all) is just dreaming. This is
not an uncommon problem with FLOSS.   

As someone who depends on open source audio SW for my daily work,
I've learned to be very selective, even if that limits what I can
use. 

Ciao,

-- 
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev