Re: release?
Florian Berger <[email protected]>
| Newsgroups | gmane.comp.audio.jamin.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi, "Alexandre Prokoudine" <[email protected]>: > > What is the common idea of JAMin's future? I would like to contribute to that question from a user's perspective. At present, I use Ardour for some tracking and Rezound for some editing, but when it comes to polishing up things I still use Samplitude on Window$, since there are still some important things I miss in JAMin. Here are some directions I'd love JAMin to take: Direction 1: Be verbose. JAMin should be capable to put out much more verbose numbers, at the user's option. One example: the meters. They are very nice, but often they can not provide precise information for certain decisions. So, every meter should be capable to print in realtime: - the current peak level in dBFS (using reasonable time slices) - the current RMS level in dBFS - the highest peak level since last reset in dBFS Check out the horizontal peakmeter in the middle of http://www.samplitude.de/de/grafix/v7_visualizer_big.jpg to see what I mean. This is one of the critical things I miss in JAMin. Other useful verbose output could include: - the mean level reduction of a compressor in the last 5/10/60/... seconds to check what impact the current settings actually have - the mean and max level reduction of the limiter - a percentage of how much of the signal had actually to be limited in a certain amount of time (so one could see if the limiter is limiting 100% or just, say 8% of the last 180 seconds) Direction 2: Be configurable. JAMin should work as a set of tools that the user can adjust, combine, use and abuse to his liking. That means it should not enforce a certain style of working. Example one: Routing The user should be free in the routing of the JAMin components. If the user prefers to limit his mix first, then put it under slight compression, and after that polishing up with some EQ, JAMin should not get in the way. Being a professional tool, it should rely on the fact that the user knows what she's doing. (Beg your pardon if I missed some hidden option to set up the routing... :) ) Example two: Meters This is just what I proposed in some earlier postings. JAMin meters should be configurable to the bone. If the user wants an _RMS_ meter with a green range up to -24 dB, a yellow range up to -13 dB and a purple range up to 0 dB, he should get it. If he wants a _peak_ meter all red with a small blue dip from -1 dB to 0 dB, it should be a matter of some clicks. These are some thoughts an wishes for JAMin from a user's perspective. I have been told to go ahead and implement some of this, but I am an audio engineer, not a C programmer. So I hope to contribute some valuable ideas which help to push JAMin to the next level. I gladly check out, test and give feedback on any new feature implemented in JAMin. Best regards to all, Florian Berger, Leipzig, Germany -- fb audio Tonstudio Leipzig http://www.fb-audio.de/ Aufnahme - Mix - Mastering - Demos - CDs ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642