Re: Users and the development process (was: Re: See ya!)
Jan Depner <[email protected]>
| Newsgroups | gmane.comp.audio.jamin.devel |
|---|---|
| Message-ID | <1163639248.28387.13.camel@eviltwin> |
Comments below ;-)
On Wed, 2006-11-15 at 20:54 +0100, Florian Berger wrote:
> Hi Steve, Daniel and all,
>
> there we go, action on the list. :)
>
> @Daniel: I was polemic, by intention. I might be in this email as
> well. Please take my words with a grain of salt.
>
> @Steve: Thanks for coming and rescuing me. ;-)
>
> So, there are some things to reply to.
>
> D = Daniel James
>
> D > don't judge a professional by the complexity
> D > of the tools they use, you go by the results.
>
> You do need certain tools for certain results. To stay with analogies,
> I want crosshairs on my rifle. I can't hit right with my bare eyes.
>
> D > Squeezing every last dB out of those RMS meters leads
> D > to nasty, over-compressed results.
>
> No one is talking about squeezing. I want to go for a certain RMS-Peak
> ratio to actually avoid overcompression, a thing recommended by
> professionals[1] and hard to do without an appropriate meter.
>
> D > I think you've misunderstood how free software works. [...]
> D > With free software, once the developers are happy,
> D > there's no need to add new features.
>
> O.O Right... To me, free software means more than just "here it is, get
> lost and don't bother me". It means to develop a responsibility. If
> there is a dissatisfied user, then there is something wrong with the
> software. Hold on: Of course this is always an opinion. But no one is
> "right" here. If the developer is happy, he has no obligation to improve
> the software. But there is still something missing - in the user's
> mind. The question is: Where do we go from here?
>
> If the user is a programmer, he can fix it on his own. If he's a
> gardener, oh well, he can go ahead and learn to program. If he can
> afford it, he can pay the developer to add this nifty feature.
>
> But the projects I've dealt with so far do it another way. They want
> to build a tool that is useful not only to them, but to end users. So
> the end user's opinion is a critical measurement of how they succeeded.
> Of course, again, there is no obligation to work this way. But in my
> mind it produces the better tools.
>
> The Free Software world is no longer what it used to be back then. One
> might cheer or cry about consumers installing Linux from an Ubuntu
> cover CD found on a magazine. But developers begin to understand that
> their software might be improved by listening to what makes actual users
> happy that are not involved in the development. Projects like [2]
> prove this approach.
>
> D > Right, and you haven't offered to fund Jamin development
> D > either, as I recall. [...] "I want specific features in Jamin
> D > but I won't do any of the work, and I expect other people to
> D > do that work for me - for free." So I'm not surprised the features
> D > you want have not appeared yet.
>
> Oh. As for "any of the work": Yes, I won't go, learn C and study DSP
> algorithms to fix it myself. You see, there _are_ developers in the
> project who know about all that stuff intimately.
>
> For "expect": I don't expect anyone to do anything. I just wanted to
> react on your "everythin is fine"-mail. I want to provide useful input,
> which, in my mind, is actually to _give_ something.
>
> "for free": From my observations I do not think fundig would affect the
> development process of JAMin much, at least the funding I could give as
> a person who is trying hard to make a living. And would it mean "now, I
> paid you, go do this and that"? I doubt it, I wouldn't want that as a
> developer. Let's just give it a try: I am ready to fund the feature
> "configurable meter colors at configurabel levels", in the sense of [0]-
> [-6]dBFS: red, [-6]dBFS - [-15]dBFS: yellow, below [-15]dBFS: green,
> with 10,00 EUR per working hour. Let's see what happens.
>
I have added configurable warning level for both the input and
output meters (tied together at present) to the Preferences dialog. The
colors have always been configurable. This allows you to set the
"yellow" to "green" level. I can't change the "over" ("red" to
"yellow") level because it is hard-wired to 0 dBFS. Steve will have to
decide whether that needs to be configurable or not. Being able to
reset the warning level is very nice because you can set the output
limiter down to -7dBFS and lose the warning altogether when it's
hardwired to -6. If this is satisfactory you owe me 20,00 EUR (or a
beer, whichever comes first ;-)
I have one major problem with these changes though, it seems that my
password has changed, expired, been hijacked, whatever, at sourceforge
'cause I can't do the commit or log in. Anybody have any ideas???
Anybody??? Beuhler???
> For the -30dBFS:
> D > Probably because if you are compressing audio that quiet, then
> D > adding makeup gain to bring the peaks to 0dBFS, you will be raising
> D > the noise floor a lot too. You'd be better off re-recording.
>
> I do not want to add makeup gain. A 24 Bit recording with -15 dBFS peak,
> -30 dBFS mean level and a noise floor somewhere around -100 dBFS is not
> at all bad in a technical way. If I want to do some leveling with a 1.5
> ratio and a threshold of -45 dBFS, the software should not get in the
> way.
>
> S = Steve Harris
>
> S > > DSP development is definately a bottleneck
> D > I don't see it that way, as a user. Jamin works great, there are
> D > more LADSPA plugins than any one person could use
>
> That is not my point. When I suggested RMS meters, the overall reply
> was "good idea, but Steve is the only one who can do it". Steve is busy,
> and he is right to be so. So development is stuck, in that area. That is
> what I mean.
>
Yup. I think it's a great idea, I just don't know how to implement
it :(
> D > I think if users demand specific features then they should be
> D > prepared to either help out, or fund that work. If not, I have
> D > about as much sympathy for them as I do for those people who moan
> D > about a particular proprietary app crashing, but are using a cracked
> D > copy they got from a mate.
>
> I strongly agree here. Now, Daniel, how can I help out? As I said, I
> can not and will not code. What is left? I can report bugs. JAMin runs
> quite stable and does well what it does at the moment, so nothing to
> report here. So I look around, find myself sitting in a studio, doing
> recording and occasional kind-of-mastering work as an everyday
> business. I have some Linux skills and I'd love to migrate my audio
> work to free software. So - my point is, to provide an however biased
> view and wishlist for JAMin from an every day audio user's perspective
> seems something valuable for me. And it does "help out" in some way, in
> my very own humble opinion. If you can't sympathize with that, then I
> am sorry to bug you.
>
I think the suggestions are a good thing. Unfortunately, our ideas
of what constitutes a mastering tool may differ. I want to be able to
add up to 2ms delay to the low band and up to .5ms to the mid band the
same way that some Rane crossovers and the BBE Sonic Maximizer do but I
seem to be the only one so we probably won't see that feature ;-)
> D > I see free software as a gift to the wider community, and I think
> D > sending gifts back and expecting something 'better' is just rude...
>
> That does not apply to me, as far as I see it. JAMin indeed is a gift,
> and it is a great one. I've met Steve at a LAC in Karlsruhe and used
> that opportunity to just give a personal "Thank you so much". I didn't
> bug him with a wish list. :) Rude? No.
>
> I do not "send back" JAMin either. I do not expect 'something better
> instead', but I want to help (the little I can) to _make_ it something
> better.
>
> Right... lots of words. I hope I cleared the smoke a bit.
>
>
> Best regards,
> Florian
>
> References:
>
> [1]
> http://www.digido.com/modules.php?name=News&file=article&sid=9&mode=&order=0&thold=0
>
> [2] http://www.openusability.org/
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Jamin-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jamin-devel
--
Jan 'Evil Twin' Depner
http://myweb.cableone.net/eviltwin69
"Life should NOT be a journey to the grave with the intention of
arriving safely in an attractive and well preserved body, but rather to
skid in sideways, chardonnay in one hand, chocolate in the other, body
thoroughly used up, totally worn out, and screaming 'WOO HOO, what a ride'"
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV