Paul Davis at LAC 2017

[asbak]

The bits on Audacity are, since the word 'ugly' has fallen already, a bit ugly themselves IMHO, but we know that such judgements lead nowhere, so let's say that if Audacity is so successful, probably a lesson can be learned from that.

There's not much of a lesson to learn.

Audacity became successful because it filled a gap in the market for a lot of people where there weren't many feature rich open source alternatives available to commercial software. Infinitely more people need to perform audiofile editing than produce music with sequencers, softsynths and similar specialised tools. For these folks (the vast majority of whom are not music producers) Audacity was a lifesaver because now they could edit audio files in Windows on the cheap. Windows uptake is what really drove it.

It's cross platform and runs on OSX too and of course it also runs on Linux, but the Linux market for it is relatively small compared to the hordes of Windows users who make use of it.

It works but port audio is pretty lame. The plugin code is really buggy so it crashes all the time depending on which plugs are selected etc. There's a lot of things wrong with it but nevertheless many, many people find good use for it.

It's a great example of how something can succeed despite it being riddled with bugs and unfortunate design decisions.

[forestandgarden]

2 forgotten plusses for Audacity: you learn it once, you've learned it, no mutations, and: the manual is fairly complete. Since Audacity doesn't pretend to be what it is not, this makes for a satisfying user experience.
Interesting to learn what impact windoze can have and has on FLOSS. Or vice versa. Still, nobody has left linux audio because of Audacity, my 2ct.

[khz]

• Linux Audio: An overview
  https://louigiverona.com/?page=projects ... linuxaudio
• On Hobbyist Software
  https://www.youtube.com/watch?v=LwNXn7OKVzY

[ssj71]

By and large, I feel the speech touches a bit on everything and doesn't give much of a conclusion, save 'we might focus on browser interfaces next'.

fair enough, though I don't think he feels concluded completely himself, more he was trying to point out things that perhaps many devs hadn't considered.

@ssj71 So if you really want to challenge me to give 'counter arguments', I'd challenge you to give a point-by-point listing of what the speech actually says. I'm not saying no points exist, but it is a lot of work to properly extract concise statements that make sense in written rather than spoken form, cite with exactitude, etc..

see bottom

I have not even had the time to read all the thread since I opened it - and I'm not sure if there's a need or sense in properly kicking off a discussion now, maybe most people have said what they had to say by now and the thread has lost focus already.

yes the thread kind of drifted, they all do around here. I don't mind. We can always bring back up the original topic.

The bits on Audacity are, since the word 'ugly' has fallen already, a bit ugly themselves IMHO, but we know that such judgements lead nowhere, so let's say that if Audacity is so successful, probably a lesson can be learned from that.

I pretty well agree with asback on his analysis.

A similar impression is left on me by the hushed remarks on not praising jack anymore, not many explanations given, but maybe it is expected that Paul's opinions on jack be known.

Since Paul has heard all sorts of opinions and criticism, it is a bit hard to judge how much of it he is still taking into account, since for every possible user demand or opinion, he can produce an instance of just the opposite demand made or opinion uttered.

Yes. Paul has "turned" against his own baby there. He simply has learned more and his experience points him to believe that the complexity and overhead of jack aren't really justified by the capability. He doesn't speak especially highly of plugins either, but he seems to think they are the better way for technical and perhaps also useability reasons. I'm not going to argue with that.

Intending to compensate for the gloomy note produced by the word 'failures' in the title, Paul points out where he sees the strengths of linux - the vast amount of free quality libraries, which - point taken! - don't free a coder from developing quality solutions himself, couldn't agree more, then it comes: A large amount of users ready to break Ardour in every possible way. Of course we know what he means, the readiness of linux users to engage in the process of debugging, even if it takes devs lots of energy to pinpoint problems from often vague user statements, and that could be me.

There is, nonetheless, a fundamental misconception here: Users are not trying to break things. They are trying to use, and they'd like it much better if nothing broke.

Yes of course, but users do break things because they are trying something the devs had not thought of or not tested, so I don't know that point makes much difference.

To resume from above, some of the conclusions I get out of this talk are:
1. The definition of "good" software is becomes very user specific, but universally means it satisfies the users expectations
2. The difficulty, time, and skills required for "good" software are the limiting factor but open source vs closed source development makes no difference to these challenges (and often we think or say it does)
3. (As you mentioned) Libraries are the biggest advantage open source audio developers have over closed source
4. Polish is important for programs to become "good" but most developers don't want to do that (unless they're paid)
5. Linux and open source is good for exploration, prototyping type of music creation
6. We aren't sure how successful open source audio is, simply because we don't have good metrics
7. There are still significant issues in open source.
8. User/Consumer perception of the value of a product are much more significant than any technical superiority
9. We should recognize that open source audio is a tiny niche, and make sure our motivations fit within that knowledge

There are other little things, but those are big ones I gathered.

[glowrak guy]

You should run for office.

[folderol]

Personally I don't find jack especially complex, neither wearing my developer, nor musician hats. It certainly has far less complexity than any plugin structure I've come across. I find Jack to be quick, easy and 'Adventure' free.

The impression I got from Paul's talk was that knowing more about programming in general than when he wrote jack it was a case of "If you're going there, don't start from here.'

[chaocrator]

just my 5 cents.

1) linux audio ecosystem complexity is strongly overestimated.
just PR and social engineering, nothing else.

2) complexity of windoze & mac audio ecosystems is strongly underestimated.
again, just PR and social engineering, nothing else.

3) all software in the world is buggy shitty crap, with some exceptions.
this is universal and platform-independent.

4) i would compare current linux audio software with commercial audio software of 2000's. actually, this IS good, because the development of commercial audio ecosystems started a decade or more earlier than audio FOSS.

[glowrak guy]

I agree linux is easier than is presented in win/mac fanboi mythologies.
Heat up that command line, and the snowflakes melt in seconds,
without a thought to the powers at hand

Actually I've found plugins quite stable, they mostly just work,
and daws are usually OK for basic multi-track recording.
I don't often need the cooler rocket science features,
and thats likely where devs get involved in entymology projects.
Cheers

[chaocrator]

as for me, linux is just the best, because it's the only system nowadays, that allows one to build a rig in a modular, i mean really modular fashion.

i agree that «ein DAW, ein reich, ein führer» approach is in general easier to handle for a typical user, but it's not that universal and that good for every task, as it's commonly considered nowadays (well done, DAW vendors).

sad, but those modular workflow possibilities are not considered as something really valuable in the community, because «everyone runs a DAW and wants it to host all imaginable plugins». mainstream is such a mainstream.

[CrocoDuck]

just my 5 cents.

1) linux audio ecosystem complexity is strongly overestimated.
just PR and social engineering, nothing else.

2) complexity of windoze & mac audio ecosystems is strongly underestimated.
again, just PR and social engineering, nothing else.

Yes, by looking at things deeper I realized this is perhaps the case if one restricts the analysis to the audio stack. Linux, Mac OS and Windows all have multiple APIs and even demons, so the way the work (design principles of the various components a part) are actually pretty similar at the end.

I would say though that there is a difference that perhaps make Linux somewhat harder: the fact that more often than on other OSes we need to configure not-audio related parts of the system in order to maximize audio performances (see all the realTimeConfigQuickScan checks), and usually by editing conf files (which once you get used to is much more efficient, easy and convenient that GUIs to me, in most cases, but it has a learning curve).

[khz]

Code: Select all

init 1
freedom >> GNU/Linux^audio >> evolve
~DNS-source@modular # /OS/LAW
:like: 
!: evolve@freedom.important
USE=":peace: && freedom" > /all/over/teh/world
together

[glowrak guy]

as for me, linux is just the best, because it's the only system nowadays, that allows one to build a rig in a modular, i mean really modular fashion.

Bitwig, Mixbus and Reaper, among others, all offer some unique and valuable content
and capabilites, which when one is aware of, their outputs can be chained as if they were plugins,
among linux standalone instruments/effects, and the full modular team recorded as desired.

In my case, I would prize Reapers vst hosting, Bitwigs effects chain, and the Mixbus
mix/master signal processing for distribution, while others will fill their pouch
with their own chosen jewels, that these days, one can't help but trip over, while strolling the net.
Cheers

[mendo]

I would prize Reapers vst hosting, Bitwigs effects chain, and the Mixbus
mix/master signal processing for distribution, while others will fill their pouch
with their own chosen jewels, that these days, one can't help but trip over, while strolling the net.
Cheers

Did you solve the Bitwig MIDI issues with Linux?

If yes, how?

[ssj71]

You should run for office.

I have no idea what you mean by that.

1) linux audio ecosystem complexity is strongly overestimated.
just PR and social engineering, nothing else.

2) complexity of windoze & mac audio ecosystems is strongly underestimated.
again, just PR and social engineering, nothing else.

3) all software in the world is buggy shitty crap, with some exceptions.
this is universal and platform-independent.

I really agree, but I think we need to be honest about the challenges specific to our platform (especially that we don't have anyone in PR or social engineering that I'm aware of). I thought Paul did just that.

[mendo]

I would say though that there is a difference that perhaps make Linux somewhat harder: the fact that more often than on other OSes we need to configure not-audio related parts of the system in order to maximize audio performances (see all the realTimeConfigQuickScan checks), and usually by editing conf files (which once you get used to is much more efficient, easy and convenient that GUIs to me, in most cases, but it has a learning curve).

The biggest issue is IMHO the support of new and innovative hardware.
See a current example where I am struggling with one really cool hardware product - Keith McMillen's K-Mix: K-Mix with Linux.

On the controller side, openAV-Ctlra shows a innovative way forward. I think there's much more potential for similar initiatives that make the life easier and that reduce configuration overhead.
If a spends too much time testing compatibility, need to configure & develop my own mapping files or bindings for each many hardware products the (hobbyist) user may turn to the other OS and programs where it 'just works'. Finally, its about music / audio and not computer science.

The software challenges will be solved in the mid-term if the linux audio world succees in gaining traction with larger user groups with less start-up and makes participating in development more easy.

A common hurdle, also mentioned in the talk, was the requirement for efficient programming using C+ or similar complied languages. This is a big blocker for many non-computer scientists to contribute. But there are examples in similar domains which require similar strong processing capabilities and where a healthy ecosystem developed and made FLOSS a success.

Let me provide you with an example: Editing of animated films, editing of photos, processing of imagery from satellites (GRASS GIS) and other geo-information software suffered long the same dilemma.
These days we have Blender, Gimp, GRASS GIS, gvSIG and QGIS which successfully outplay the former market dominating closed-source monolithic monopolies. Functionality and ease of use have reached levels that go on par with regular market offerings.
Blender was adopted by large film studios, while the igniting momentum in the GIS domain came when all the developers from the scattered programs joined forces and founded a governing organisation which then promoted adoption of free software by universities and public authorities.

Concluding, there is need to think more out of the box and question the status quo of approach to issues.
For instance, linux audio seems to somehow reject innovations by the more modern DAWs when it comes to user interface and easiness of use for creative production beyond mere hard-disk recording. This includes items such as integrated audio slicing and bouncing to keys or a drum kit, support of scales and chords, etc.

While the talk was a nice history recap, it was missing such kind of visions or ideas for a fresher way forward.
Thus, it gave me the impression that the speaker and many here on this thread have established themselves in a well defined niche and are too eager to leave it.

Looking forward on your thoughts on this.