Re: [LAD] So what do you think sucks about Linux audio ?

On 8 February 2013 02:02, Fons Adriaensen <fons(a)linuxaudio.org> wrote: There are differences between the win and mac way of doing things, and the "collective of smaller parts" philosophy of Linux Audio. This requires a different mindset. The notion of sessions is much less apparent in the more monolithic commercial world, and imho, far more important in ours. Male and Fons are both right, imho, that we don't need to chase tails, but i will add that a common agreement and enthusiasm for a "LinuxAudio session protocol", AND a dumb user (count me in) session interface would go quite some way to unifying disparate elements, and make linux audio more presentable to users. User expectations are as excessive in win and mac as they are in linuxaudio, so i don't think that's a viable reason for debate. (generally) User input to devs is important, as i've discovered. YMMV for response, but that's just as true for dealing with commercial vendors, where the user is far more likely to encounter the "corporate wall of silence" when asking those companies to fix bugs in their latest grope in the consumer's wallet. Personally, i don't care about VSTs or AUs, and i had just as much trouble with them in the past, as i've had problems with the rapidly developing LV2 format. (And this is 2 allegedly "stable" protocols, versus one growing before our very eyes. VST and AU were just as problematic in the beginning, and took quite a bit longer to mature) We have a good collection of plugs, and rather than push and push for thousands, i'd like to see great plugs of high quality (which we have some of already) even if this means i have 8 favourites, and "only" 258 others. (Irony noted i hope) Users need to put up or shut up, and i say that as a user who's had to learn the "linux way" over some years, when interacting with devs, making plenty of mistakes along the way. I continue to live and learn. Good bug reports, well thought out and detailed feature requests (which may or may not be accepted) to give the devs a clearer idea of what you're actually trying to say, and some sort of contribution in writing docs, making vidoes, and/or relentless testing, etc, go a long way. Quality control is not just the province of devs, but users too, and frankly, if you as a user finds a problem and doesn't report it, then you deserve what you get. Whether the dev is interested in your reports or not is up to the dev, but it's likely that a persistently unreceptive dev will find out soon enough that bleating about a lack of user interest will fall on deaf ears. It works both ways here, with the proviso that devs are coding in their own time, and users are testing and reporting in their own time as well. Likewise, and i think Fons is right here, if a project is dying, and there's little to no user interest, then let it die. I'd rather see the very few devs we have working on live stuff, with regular user input, than dragging a dead horse to a brothel. Example, i was enthusiastic about using Rezound but it hasn't built here for some time. At first i was keen to see it revived by "someone" but learned quickly that my perception of what i thought was an important linuxaudio app, was in fact just my perception, so i moved on. Such is life, and part of the rolling evolution. I don't think we're in as bad shape as is implied in some posts, but the incomplete or evolving session management required to manipulate our modular by design collection of apps, coupled with what seems like a universally accepted concern about hardware drivers do contribute, imho, to a often exaggerated perception that linux audio is perpetually poor. A new robust and persistent client name system for jack would be good too. (in relation to opening the same app more than once in a single session, and having each instance, plus its presets and settings saved and named the same way for each session instance) Maybe an addition to the API? My two Kr.s worth. Fons, there are no virgins in Yorkshire. Alex.