Re: [Linuxsampler-devel] default_path SFZ

[Christian S. <sch...@li...>]

On Samstag, 23. Mai 2020 17:17:34 CEST rosea.grammostola wrote:
> On 5/19/20 11:56 PM, Christian Schoenebeck wrote:
> > Sure! SFZ is a very simple text based format. Hurdles are not high to
> > start
> > some new player based on it. The actual challenge is to bring a new player
> > to a certain point and then still keeping development activity high.
> 
> Sure.
> 
> >> The exception on the GPL license for Linuxsampler doesn't help here
> >> probably. I'm sure you've debated this many times, which is not my
> >> intention. But from a practical point of view, I could see how a pure
> >> GPL license could help Linuxsampler here. People are probably more
> >> willing to work on the project instead of starting a new project (sfizz).
> > 
> > libgig, libakai, libsf2, liblscp, QSampler, Gigedit, Fantasia are all pure
> > GPL or even LGPL. People could contribute directly to those, they could
> > have used them for other projects, forked them and lead them into other
> > directions according to their own ideas. But: no activity difference to
> > LS at all.
> It's not that pure GPL is a guarantee for contributions, but people do
> mention the license of Linuxsampler now and then when discussing SFZ
> developments as a reason to look further. It's definitely a issue for some.
> 
> The developer of Sfizz did mention the license of Linuxsampler too, but
> he also wanted to start from scratch because he didn't feel ready yet to
> contribute to a larger project like Linuxsampler. Maybe in future, who
> knows. But that would be more likely if Linuxsampler would be full GPL I
> think.

I have not seen anybody starting a project, and then heading to another 
similar one.

I've been thinking about license relaxing myself as well, but more because of 
user aspects, i.e. convenient precompiled availability of LS in users' 
distribution of their choice, and there maybe preconfigured/customized for 
certain use case aspects. Like I said, from contribution point of view though, 
I don't think it would make any significant difference.

> > Likewise if you look at other Linux audio projects beyond a certain
> > maturity level: almost no activity anymore nowadays. Most of the time
> > it's like this: somebody starts a new project, there's activity for some
> > time, and then after a certain point it stops. Many great LAD projects
> > suffered this death (e.g. Rezound).
> 
> Latest commit 6 days ago ;)
> 
> https://github.com/ddurham2/rezound

Wow, a sign of life after years! :)

> At least the LAU mailinglist is far more quiet then years ago, (not sure
> what I should conclude from this yet). On the other hand, projects like
> Ardour, Muse, Non-session-manager, Zynaddsubfx, Radium, Qtractor etc.
> are still pretty active in development these days.

Who knows, fact is that communication ways and habits also shifted with the 
years. Many people no longer want to use mailing lists. It's like when I 
started coding, communication was typically on dedicated newsgroup networks, 
which we also thought of just being a relict of old times. Same situation with 
MLs today.

Just wait couple more years and you'll see a real game changer with AI 
thriving as dominant servant in engineering, and a significant change how 
exactly (and how little) humans will still be part of that engineering 
process. [ dramatic music playing ]

CU
Christian