On Thu, 27 Aug 2009, Aaron Johnson wrote: > I realized that adding a release envelope on the order of 180-200 or > sometimes more did the trick (it was at first confusing, b/c quicker > envelopes get *higher* numbers (like 255 being fastest), not lower...I > wonder if they are denominators of a fraction in some kind of > non-linear time equation??)
> I added the 'strip=tail' option b/c it mentions clicking in the > manpage, but it doesn't seem to be the critical piece...the critical > piece is the 'rate=:::180' option. The strip=tail is an ancient option meant for some ancient GUS pats that could sometimes contain garbage at the end of the sample. There are probably not any instruments still in use today that would benefit from this. I have not seen any instruments like this in a long long time. > Thanks for looking into this...everything works really well now! > >> >> >> > If I render this file with fluidsynth the clicking noise does not > >> >> >> > occur. Also, if I tweak the attack or decay rates in the Timidity > >> >> >> > configuration file, I can mitigate the clicking noise somewhat but > >> >> >> > cannot eliminate it entirely. > >> >> >> > > >> >> >> > Could this be a problem with the soundfont or is Timidity just not > >> >> >> > able to process SF2 fonts completely? I'd be curious to know if WildMidi exhibits this issue too. If there is one thing I am sure of, it is that Chris Ison knows his GUS instrument envelopes! 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
