Hi Eric, Good software design in my philosophy is allowing the flexibility and generality when needed, but, yes, saving the user from themselves! Given that the clicks were not heard on say FluidSynth, I'd say they have something like this in place. And I think something like this would be very good for Timidity.
However I understand your concern for purity and literally 'doing what the user asks'...so 3 thoughts come to mind: 1) You could have a auto-declicking provision coded in by default, and have a command line option to disable. 2) You could have a command-line option to *enable* auto-declicking, where it's off by default 3) You could document the issue. The user searching for solutions now is in the dark, and is likely to give up on Timidty. Right now, it's not mentioned but in passing, and adding 'strip=tail' doesn't work. Google didn't really bring it up except this recent thread, and the manpage mentioning the 'strip=tail' option. So, if it weren't for tinkering, I would write off Timidity too. A lot of people may have already written Timidity off as not being capable of professional, clean-quality work, b/c it has clicking noise where other MIDI soundfont software doesn't. They may have said, as I did, "development isn't active, it's old software, I don't think this will get fixed", and move on, to get their music done without the hassle of figuring it out.....I perceive NOT dealing with it clikcing as a bug, not a feature. My 2¢!!! All best, Aaron. Aaron Krister Johnson http://www.akjmusic.com http://www.untwelve.org On Fri, Aug 28, 2009 at 12:16 AM, Eric Welsh<ewe...@biology.wustl.edu> wrote: > > This may bring up the wider question of what is the "correct" behavior of > timidity in the case where "stupid" envelope parameters are specified. > Should it continue operating as it currently does, and just accept them > as-is, or should it set some minimum release rate that is still very very > short, but would be long enough to prevent clicks? > > Sorry, I'm going to go into a historical rant now to overly explain > the issue.... It is my emperical experience that amplitude changes need > to be ramped over a minimum of 0.5 milleseconds from starting amplitude to > new ending amplitude. Any faster than that and clicks happen. All notes > playing in timidity have a current internal amplification, a target > amplification, and an increment value that tells it how rapidly to > increase/decrease the amplification. Envelopes are implemented by > adjusting these internal values on the fly as the different portions of > the envelope are reached in the sample. Volume pans and Expression levels > are handled in the same routine, it's all done during the mixing stage. > Originally, timidity had clicking problems during rapid Expression level > changes, or during very rapid (instant) far right/left pans during the > middle of a note. I added a check to adjust the minimum time spent > ramping between initial and target amplitudes to 0.5 msec and the popping > went away. Any shorter and the volume pops, any longer and the ramp delay > starts to become audible and sound slightly "sluggish". I deemed this to > be a reasonable compromise between "do what I told you" and "do what I > meant" since the brain will not notice the 0.5 msec delay in the volume > adjustment. > > So, why is this code not kicking in when there is no release rate set? > I'm going to guess that timidity pre-calculates that the end of the sample > play time has been reached, and thus ends the note without any additional > mixing (since there is no sample left to mix since it ended the resampling > upstream of the mixing already). This is just a guess, and I'm too lazy > to go dig into the code to look right now. Whatever the reason, I don't > think that any additional fixes could be easily made at the mixing level > to check for non-existant release rates. I think the changes would have > to be implemented during SF2/PAT loading itself, to check for "bad" > envelopes and adjust them to something "not so bad". > > If I remember correctly, and my memory is a little hazy on this at the > moment, I think that the standard GUS pat loader will use a default > pre-set envelope if no envelope at all is found in the instrument. This > is bypassed when the -P option is used, and the envelope is used as-is > directly from the pat (this part I am *sure* of). This would explain why > the recorder click problem was very bad when I used -P, but was reasonably > mild when I edited my gravis.cfg file to load the pat instead. > > If this is being done for the standard GUS loader (I have no idea how the > realtime softsynth handles it), should it be done for SF2 as well? What > is, philosophically, the best thing to do here? Should timidity trust the > user and do exactly what the user said to do, because the user knows best? > Or should it set a minimum release rate to protect the user from himself? > Protecting the user from himself is a dangerous path to take, since it is > easy to go too far and deny the user from accomplishing his intentions. > If I tell it 0 release, and timidity auto-fudges this to 0.5 msec release, > would this auto-fudging behavior be "bad" because it isn't doing what I > explicitly told it to do? I'm hesitant to auto-correct "bad" envelope > settings. > > Also, from a purely personal viewpoint, I think the popping noises are > "good", since they alert the user that there is something amiss with the > instrument and that its envelopes should be edited to sound better. > Better to have the user blatantly notice the problem and fix it properly > than to mask over the problem and result in a not-as-great sounding, but > not jarringly bad sound. > > -Eric > -- ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Timidity-talk mailing list Timidity-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/timidity-talk
