On 08/15/2013 12:42 PM, Harry van Haaren wrote: i had to listen the 2 and 3 podcasts offline while resting off diving on open waters (no pun) so this might be kind of retarded reply anyway :/ i have a feeling--a strong one if i may--that the OP bug is on my http://www.rncbc.org/drupal/node/678 happily, i'm still on vacation/holydays now and still, that doesn't make to justify an incomplete bug report and followup process. ah, always the process, when evidences are due late or never coming... yes, Louigi it's you who i'm looking at ;) right on. LV has been one of those "soft-core" testers ever still, maybe anymore? lap003 tells me otherwise, but hey Louigi, software development is no simple craftsmanship, complex software is serious business and old and new assumptions are always caught in the open i have this kinda metaphor for that old returning bug case: short blanket syndrome. yep, an anti-pattern of its own--simply put: you may fix or close one but will most certainly open one another often hidden and even dead older--the most hideous bugs just lurk in there, believe me, i know ;) cheers -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

"At first you sounded like you were announcing that you were giving up on participating and maybe even using free software" To be honest I was very surprised someone got it that way. "Complaining wihtout offering any solutions is about the most useless thing a human being can do with their time." I respectfully disagree. I see no logical connection between criticism and solution offering. "None of these facts are specific to linux audio or even free software." I argue that they are. On Thu, Aug 15, 2013 at 10:32 PM, J. Liles <malnourite(a)gmail.com> wrote: -- Louigi Verona http://www.louigiverona.ru/

I'd rather be realistic than dystopian ;)

On Thu, Aug 15, 2013 at 8:54 PM, hermann meyer <brummer-(a)web.de> wrote: True and well said. It sometimes seems like people think they are doing the project or developer a favor by merely using it. Well, sure, it's good for the ego to have the most popular whatever, but what is the value of having 1,000,000 users who never donate, who never submit bug reports, and who only go around complaining that the thing they got for free doesn't work as well as the thing that company X charges $700 for. Personally, I've benefitted a greatly from free-software and I have also given a lot back in return. I simply can't understand the mentality of those who take and take and yet can't be bothered to do so much as alert a developer to a problem. Progress doesn't just happen magically. It happens because people make it happen. If anyone is frustrated with the glacial pace of whatever--they just need to get off their ass and do something about it.

"It sometimes seems like people think they are doing the project or developer a favor by merely using it." Perhaps some people, but I do not subscribe to such a view ;) I'll repeat once again - it was just sharing of my experience that surprised myself and I wanted to tell about it - that even a rather dedicated user can go through such a phase. There is really no frustration or complaining, but, if course, I did anticipate that someone might react that way. I do say very positive things about Linux Audio if you read my site, so I just do not agree that you attacking me as someone who just complains is constructive or necessary ;)

If we move past the current arguments of "don't complain about free stuff", there's something pretty interesting to discuss that we all could benefit from; how do we make this better? interaction better? What can users do to provide better bug reports, and how should they be handled? Are there guidelines for most projects as to how users should report bugs? Can we simplify this bugreporting somehow for the user, and at the same time make it more powerful to the dev? What does developers think is lacking in this interaction right now? What does users think's lacking? One point Hermann made is that devs more or less only gets contacted when there's something wrong with their application. I can really see how that is, and that's very unfortunate. For me, one of the greatest draws to Linux Audio is the fact that I can so easily interact with the people who write the applications I use. A tighter community integration would be great for most people. We have forums like Linuxmusicians.com, which might be a bit more laid back than the projects official forums. Maybe we could try and use LM-forums as a gathering point for the community for real? If we make sure every project that wants gets its own sub-forum, getting together and both discussing as well as helping each other gets very easy. Any thoughts on that idea? For me personally as a user, I can subscribe to a lot of Louigi's thoughts. The applications I use more or less always has some fairly basic functionality that's either half or fully broken. Even if there's reports and a will to help debug, there's only so much one (or at best, a handful) developer can do. What's basic and a *must* functionality for me, might not at all be important to the rest. This is a reality, but can we make it better? Please feel free to answer any of my questions here. I'd love to hear what both developers and users have to say about this, as this is something that On Fri, Aug 16, 2013 at 7:36 AM, hermann meyer <brummer-(a)web.de> wrote:

On Fri, Aug 16, 2013 at 1:57 AM, Gabbe Nord <gabbe.nord(a)gmail.com> wrote: The fact of the matter is, if you have a feature that is non-trivial, critical to you, and not critical to others (especially the developer), you have the following options: 1) pick a more appropriate tool. The natural instinct of a user is to INSIST that the feature X they want should be integrated into software Y, when really the feature may have nothing to do with Y at all, it just happens to be the software they're working with at the moment. This force should not be underestimated, as it is a very real effect and one of the major causes of software bloat. Chances are that some other program exists that was DESIGNED to do X and does it well. This is why we have DAWs that burn CDs and text editors that play tetris and browse the web--and the general result is a lot of software that does the same thing poorly rather than a little bit of software that does it well. 2) make a convincing case to the developer (maybe even one not connected to the project you want to change). Programmers work for free in a large part because it can be fun. They will only work for free on fun things. For unfun things, you have to pay them boatloads of money. If you have a feature that you consider important--convincing the developer that it's importand and interesting is going to be a lot more effective than just whinging about how badly you need it. 3) pay for it. 60% of the time, it works every time. 4) Do it your own damn self. I'm dead serious here. This is how users become developers. They identify a need that only they have, or in a domain that only they understand well enough to devise a solution. Either by patching existing software (a hell of a lot easier than you think!) or by starting something from scratch (goodbye nights and weekends! but hello personal improvement and satisfaction). Many great free-software projects started out this way.

On Fri, August 16, 2013 1:04 pm, Gabbe Nord wrote: I would add to that "not able to code", not able to even understand "send us a diff file" (something that can mean different things to different people and has more than one format and requires the ability to install a src file and understand where something should be in a package) -- Len Ovens www.OvenWerks.net

Great response! I think you're touching on what I perceive as one of the bigger potentials in linux audio - the community integration. Perhaps a no brainer given it open source, but still not something I feel has reached its potential just yet. Like I said before, one of the biggest draws for me is the possibility to interact both with the people that make the software, and also the people who use it the same way I do. I completely understand that no dev will sacrifice their free time to develop something they don't find interesting. I wouldn't be making music in a style I don't find interesting. However, there's so much other, different things users can do. Something that's usually a bit lacking in audio software is tutorials and examples of actual usage of the applications. I can't even count the number of times I've read about or seen interesting software, but just couldn't figure the software out. This is something that users can contribute without necessarily needing any advanced knowledge of debugging etc. Now that the sync issue with screen casting is solved as well, we should have a good basis for doing that. I will actually look in to doing something like that this weekend, just to show I'm not just talk ;-) On Fri, Aug 16, 2013 at 1:04 PM, Gabbe Nord <gabbe.nord(a)gmail.com> wrote: Bug reports are an entirely different problem. It's very hard to get a quality bug report. They vary quite a bit. Often they are of the form "X doesn't work properly". That's about as helpful as a handful of sand in the eyes. It doesn't define 'properly', it doesn't explain how the user determined that X doesn't meet that definition, it doesn't say what version of X, where it was aquired, how it was built, on what system it was running etc, and it is just lacking information in general. On the flip side, lots of bug reports (this is especially true of automatically generated ones) include pages and pages of backtraces and dumps, but don't give any other context, such as what the user was trying to accomplish at the time (often an extremely important piece of information!). I have an article about how to prepare bug reports here: http://non.tuxfamily.org/wiki/BugReports But the issue has been covered at length elsewhere. Often the backtraces etc are not even required, what is required is full disclosure on what the user did and why--preferably without judgements or accusations (these often backfire anyway, as a fair percentage of bugs can indeed be attributed to user error, system configuration, or some other thing that is completely outside the control of the developer). Personally, I respond best to interesting ideas. If someone has a use case for my software that I know I'll never personally need, but it's an interesting an appropriate use case, I'm very likely to go ahead and put in the time to implement it. Donations are always rewarding as well, they are a very tangible way of saying 'thank you' and 'I like this'. Lots of people will /say/ they love your work, but few will prove it by contibuting (anything). As is true of most projects, I don't get many donations (that's another topic entirely!), but I have had a few power users donate considerable sums, and discussing changes with them feels a lot more like collaboration than it does answering demands from those who contribute nothing. I'm also very likley to accept patches, and willing to offer lots of help understanding the code and design for those who want to extend the software--even if it's in a direction that I don't agree with and wouldn't merge into the mainline. Testing is also appreciated. The best testing is acutal use and lots of bug reports! It sucks to put out a 'stable' release and *then* get the bug reports. Hope some of this was helpful!

On Fri, Aug 16, 2013 at 09:53:13AM -0700, J. Liles wrote: This is also how we get EQ plugins that * reduce you S/N to 50 dB or less when given LF input, * become unstable for some settings of the controls, or when you move them too fast (good way to blow up your tweeters), * display a graphical frequency response which is not the actual one, in some cases not even close, and dynamic processors that * claim an attack time of less than a millisecond but are insensitive to much slower variations in level, * are completely unusable if you care a bit about signal quality, and autotuners that massacre your signal, and all sorts of processors with controls that are usable over less than five percent of their range and/or produce massive thumps when moved, etc. etc. These are not 'bugs' that can be put right by a few patches. This is would-be developers who do know just enough about programming to modify some example code, but little or nothing about audio nor DSP, and who naively implement some equations from a textbook (in the best case) or some web page (in most cases) without even a hint of understanding what it does. This is why at least 70% of all LADSPA plugins ever developed are completely useless. Sure, not all programming is DSP, and for most 'big' audio-related apps the DSP parts may just be a tiny fraction of the code. But in many cases the same careless attitude is prevalent when developing the non-DSP parts. One-liners are usually little more than peptalk promoted by the prevailing topdogs, and I tend to ignore them. But there is one that is IHMO very wrong, and that's the popular 'release early' (and often). Please don't. Make at least sure your stuff works. Test it. Measure it. On nice aspect of free software development is that you can work without company policies, quality and marketing departments, and supervisors looking over your shoulder. Which in the end means that you, the developer, and only you, have to assume your responsability. 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)

On Sat, Aug 17, 2013 at 07:29:25PM -0700, J. Liles wrote: The topic of the thread was about reporting bugs. What should a user do when he/she encounters things like described above ? * To report a bug would be completely useless in such a case. * ... For normal audio processing (EQ, dynamics, effects,...) that is true. If you count 'instrument' plugins as well things could look different. But why should those be plugins in the first place. ... I surely wasn't. And it takes a long time and a lot of effort to build up both the theoretical knowledge and the skills. And even more to understand the practical consequences of some of the standard theory in an audio processing context. It's also a process that never ends. Just yesterday I discovered some small but systematic errors in the white noise generator used in e.g. Jaaa. [*] Anyone who's learning this sort of thing and who uses his/her knowledge to write free software will have my full support. But I won't do anything to make life easier for those who just copy some DSP code and wrap a 'shiny GUI' around it, with as the only result one more that just looks as much as a toy as most of them do. Ciao, [*] Set up Jaaa to measure its own noise output, with averaging. Zoom in on the vertical axis. The result will never be exactly flat (as it is a finite lenght average), but the remaining errors should be random. If you wait long enough and repeat this a few times, you'll notice that the small dips of 0.3 dB or so at around 1, 2 3 kHz are systematic. This was a surprise, as the noise generator is based on a random number generator which has a very good reputation - whatever autocorrelation it hase will probably be insignificant in most applications. Yet this test will reveal them. Will be fixed in the next release of course. -- 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)

On Sun, 18 Aug 2013 10:55:22 -0500 Neil <djdualcore(a)gmail.com> wrote: I would also like to add my *full* support to those who make their own work freely available. If I say that some material is not quite up to the standard I would work to, I'm also quite well aware that much of my work would not be as good as other peoples. I try to feed back constructive bug reports on the applications I use. If at all possible including a step-by-step account of how to trigger it. If it doesn't get fixed quickly, I don't go into a hissy fit. I recognise that the original dev. likely has other priorities. Finally, were it not for the efforts of some very talented programmers I would not be on this list at all - I wouldn't have the ability to produce the music that I do. Nor would i have an OS that I can get on with. -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.

On Sun, Aug 18, 2013 at 01:03:19PM -0700, J. Liles wrote: The net effect would be zero, as you probably know. Packagers would just refer you upstream. Correct. There is no quality awareness at all. Which means that even if you write something that does work and package it in one of the popular formats (e.g. LV2), it just becomes part of the giant heap of junk. 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)

What plugins are the best according to you Liles, and you Fons? Or anyone else knowledgable for that matter. I personally wouldn't catch the difference unless it's something fairly obvious, but I do agree it's impossible to know which ones are the good ones in the giant pile that is LADSPA/LV2 plugins... If you tell me/us that, I'll compile it to a list and put it somewhere where we can refer people. Preferably the Linuxmusicians or Linux Audio wiki. Cheers! On Sun, Aug 18, 2013 at 10:46 PM, Tim Goetze <tim(a)quitte.de> wrote:

On Sun, Aug 18, 2013 at 2:14 PM, J. Liles <malnourite(a)gmail.com> wrote: And if that's too obscure I've attached it in the form of a Non Mixer plugin favorites file (put it in ~/.non-mixer)

On Sun, Aug 18, 2013 at 2:42 PM, Gabbe Nord <gabbe.nord(a)gmail.com> wrote: As with anything else, you'll only notice when things don't work, not when they do. A good plugin is simply one that does what it says on the tin. I'd say that the C* Versatile Plate Reverb is one of the better algo reverbs out there (although lately I've moved to doing all my reverb with jconvolver, instead of plugins). The GLAME Butterworth Highpass and Lowpass are what they claim to be and work for most EQ tasks. DJ EQ is pretty good when you need a few more bands. Fons' Parametric EQ is good when you need more control, but isn't very user friendly. TAP TubeWarmth is good for killing some of the fidelity of vocals. SC4 Mono is my go-to compressor. The guitarix plugins are OK, but they have some denormal problems and aren't very user friendly. I'm not a believer in mojo. EQ is EQ, distortion is distortion etc. IMHO the best plugins simple ones that do one thing.

On 08/18/2013 12:49 PM, Louigi Verona wrote: I once wrote a fractal graphics generator in 6510 Assembler for C64. I can read a number of different programming languages. I know enough about programming to know I'm not a developer - anything I produced would not be a positive contribution to anything! So I'd rather make art and music and such. Thanks to all the developers - known, unknown, on Linux or any other platforms - who've successfully turned complex theories into something I can use to get a sound or photographic effect I want in order to express what I want to say. -- David gnome(a)hawaii.rr.com authenticity, honesty, community http://dancingtreefrog.com http://clanjones.org/david/ http://dancing-treefrog.deviantart.com/

Dear J. Liles! (I am sorry, I do not know your first name) Since I've posted my podcast, you have reacted in a rather aggressive manner, as if I am saying something controversial. Well, I am not. Being part of a community is being able to freely speak your mind, provided, of course, it is stated in a polite and respectful manner. I believe I have not been rude or disrespectful. If you personally find this discussion useless, no problem. I am not forcing you to continue. "just shut your mouth and be happy that people are building you a house for free out of the kindness of their hearts" I am afraid I do not see free software community that way. You are always trying to have someone be obliged to someone else. In my words you see obligation of the developer to the user, although I have several times said I do not believe such an obligation exists. Now you hint at users being obliged to developers. And just to point out one other small thing: "If the software can export files, but just not 'properly', by your private definition, then it's indeed very likely that everbody else who uses it simply has a different definition of 'properly'." I have faced situations where a file would get rendered with pops and clicks in place of certain effects and with whole sections missing from the middle of the track. Or when a file would just not get rendered at all. I would be very curious to read the definition, by which this is fine. Believe me, my needs are nothing fancy. When I say "basic" - I mean it. And to be fair, this is not only Linux Audio. While on Ubuntu Karmic, I remember stock DVD burner having a bug that makes the software freeze when you press "Burn". To me this is also basic functionality lacking, unless I am missing something fundamental :D Cheers, L.V.

[J. Liles] You have reported these problems to the plugin authors, right? Because if you haven't, you're doing exactly what you criticise Louigi for: public dismissal with no opportunity for the developer to fix the issue. I'd be surprised to hear of a developer of a substantive LADSPA bundle who would ignore such grave issues, the occasionally experimental, amateur or plain basic character of some endeavours notwithstanding. Please name those LADSPA bundles where you find six out of seven plugins to "do nothing, crash the host, or make horrible tweater[sic] destroying noises" while their authors ignore your reports. If you can't, your quote constitutes plain slander, and how much good can that possibly do? Tim

On Sat, 2013-08-17 at 22:00 +0000, Fons Adriaensen wrote: That is what I meant when I mentioned that even free as in beer software that comes with a disclaimer has to provide a little bit of quality. I disagree that this is important for those audio apps you mentioned, but it's important for software that has to do with privacy and security. Sure, a plugin that has tendencies to kill tweeters should be removed from repositories, or better, never should be available by a repository, but as long as such software was released with no ill intend, the disclaimer is a fair way to mention risks and self-responsibility of the users. I completely agree that such software can't be fixed and I'm thinking of software that is less complicated than fourier synthesis. When I programmed the C64 I didn't fix the programs I wrote as a beginner, when I became a good coder, I wrote completely new programs. Being a good coder does mean that you have to keep it rolling. If you would give me a C64 today I wouldn't be able to write good software anymore. IOW users can't become coders, when they aren't willing to program regularly. It should be ok just to be a user. It even should be ok when some people give absolutely nothing back to the free software community, our societies are huge and somebody could take from the software community and give by e.g. doing the shopping for physically disabled people. Real live is more than just free software, artists should know this. Regards, Ralf

On Fri, Aug 16, 2013 at 10:23 AM, Egor Sanin <egor.sanin(a)gmail.com> wrote: An interesting point. As a though experiment: pretend you are a musician; if someone came to you asking you to rewrite your song to better suit their listening needs, how would you respond?

On Fri, Aug 16, 2013 at 10:46 AM, Egor Sanin <egor.sanin(a)gmail.com> wrote: I've never questioned OPs experience or power-user status or anything of that nature. I think we all need to remember that we use GNU/Linux and free-software not only because of the low price or because it works perfectly all the time. We use it for practical and ethical reasons as well. I wouldn't give up on a musician because they missed a note, and I wouldn't give up on Linux Audio because it has a few bugs. The truth is, Linux Audio didn't exist, I wouldn't be using computers to make music. Period. I'm sure there are a lot of people in the same boat. Some for financial reasons, some for practical reasons, some for ethical reasons. We all need it to work. But only a very few of us are willing to put in the time to make it work.

On Fri, 2013-08-16 at 13:46 -0400, Egor Sanin wrote: There's a difference between art and tools released for the public. Art, excepted of the crap on the radio, should not suit to anything. A tool, even if it's for free as in beer, needs some quality. For example, if I build a power supply for somebody for free, this person can't expect that I fulfill all imaginable uses, e.g. for somebody who needs it for a Tattoo machine, I won't provide balanced voltage, but it could be used with the bikes battery and mains. What I fulfil is security, if she/he should hang ab the tattoo machine on the bikes handlebars no short will destroy anything, if the mains are used, nobody getting tattooed will get an electric shock. If I build a power supply just for my self, not for anybody else, I can ignore some security things, because I know what I do with this power supply. I even could use banana jacks instead of a Schuko jack to connect to the mains. Why the double standards? Regards, Ralf

On Fri, 2013-08-16 at 11:14 -0700, J. Liles wrote: The reason for this is coverage, but the target of FLOSS is to provide a quality level. Again, it's not black and white. If music apps shouldn't be perfect it's one thing, but regarding to e.g. security, privacy even this disclaimer won't protect an evil coder against a lawsuit.

On Fri, 16 Aug 2013 12:07:08 -0700 "J. Liles" <malnourite(a)gmail.com> wrote: Hear! Hear! Very well put. -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.

On Fri, Aug 16, 2013 at 12:27 PM, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>wrote;wrote: Ralf, I have only one thing left to say to you: sudo rm -rf /

On Fri, Aug 16, 2013 at 12:46 PM, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>wrote;wrote: It would be impossible for me to be mistaken regarding an argument I never made.

On Fri, 2013-08-16 at 20:10 +0200, Ralf Mardorf wrote: ^^^^^^^^^^^^^^^^ Is the correct term symmetric voltage? For + and - voltage, e.g. to use with op-amps.

Am 16.08.2013 19:23, schrieb Egor Sanin: It's also important to get the point that Luigi talk about "getting tired" and not about "running out of time". If you get "tired", and want to reach a goal, you have to . . . move yourself. Maybe it suggest this opinion to you, because you want to read exactly this in my lines. But that is just your interpretation of what I've wrote, if you take my words back in context, you may come to a other interpretation. Most linux audio developers been musicians to, and love to spend there free time in make music as well. Coming back to your time arg, then I would say, the time would be better used by just fill this bug report. ;-)