Re: release?

These all sound like good ideas.  Unfortunately, they are all in Steve's
area of expertise and, as I understand it, Steve is as busy as a one
armed paper hanger.

On Wed, 2006-07-12 at 20:09 +0200, Florian Berger wrote:
> 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
-- 
Jan 'Evil Twin' Depner
The Fuzzy Dice
http://myweb.cableone.net/eviltwin69/fuzzy.html


"As we enjoy great advantages from the invention of others, we should be 
glad of an opportunity to serve others by any invention of ours, and 
this we should do freely and generously."

Benjamin Franklin, on declining patents offered by the governor of 
Pennsylvania for his "Pennsylvania Fireplace", c. 1744



-------------------------------------------------------------------------
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