fluid-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[fluid-dev] Overflow settings (was: problems with fluidsynth 1.1.6 on a


From: David Henningsson
Subject: [fluid-dev] Overflow settings (was: problems with fluidsynth 1.1.6 on a raspberry pi)
Date: Mon, 17 Dec 2012 08:32:35 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

On 12/17/2012 12:45 AM, Aere Greenway wrote:
David:

Establishing a score on a note to compare with other notes' scores, to
determine which note to remove is an interesting idea.

I was a little inaccurate in my previous email; the score is per voice, i e, if a note translates to more than voice in the soundfont, all voices are scored independently.

Anyway it's the method used since before my time with the project.

But there might be an easier way to determine whether a note can be
killed or not.  I am merely speculating here, and don't know what
information is visible to the code that decides to remove a note.

Many instruments have a sound that fades-away with time, regardless
whether or not the sustain-pedal is pressed.  The volume it fades-to is
probably what is maintained sounding by the sustain-pedal.

Although percussion instruments (in a rhythm-track) are important for
keeping the other instruments together, many percussion instruments
(such as a wood-block) are the type whose sound quickly fades to a
barely audible (or inaudible) level.  Also, the sustain pedal doesn't
seem to affect them.

When a sample has finished playing it is automatically freed up so that it can be used for other voices. A wood-block sound would typically have a very short sample.

Likewise, a guitar sound has a strong attack sound, but quickly fades to
a lower level.

Playing a guitar voice with the sustain-pedal held down changes the
sound, making it generally richer and more full, but it doesn't have as
noticeable an effect as playing a piano voice with the sustain-pedal
held down.

On the other hand, very many instruments (such as on oboe, trumpet, or
French horn, to name a few), have a high volume-level for the sustained
note (which is lower than the attack-phase of the note).  In
performing/recording a track for such instruments, I generally don't use
the sustain pedal, but will use it if I need to keep a note playing
while I re-position my hand to play the next phrase.

If the software is aware of the volume level of notes still sounding, it
would seem logical (to me) that if a note is no longer sounding at an
audible (or barely audible) level, the note could be removed without
making a noticeable change to the sound.

So it makes sense that the volume level of a note is a very important
(perhaps most-important) part of the score used to determine if a note
could be removed.  Certainly if a note is no longer audible (even though
the sustain pedal is depressed) it could be removed with impunity.

Sure; but things are more complex than that. We also have stuff like reverse cymbal, where the note is currently almost inaudible, but soon will have a very strong sound.

Or imagine that somebody has very soft sound, maybe a synth pad or so, that seems like a good candidate for removal, but later the user want to use the channel's main volume to achieve a techno-like effect on that sound.

So; I'm not saying there isn't room for improvement, the current algorithm is far from optimal. But there is also another constraint - if we were to do some kind of RMS calculations of every sample to find its maximum volume (or even future maximum volume?) at different points in time, that is time/CPU consuming. I'm not exactly sure when to do that to make it accurate without sacrificing latency at the same time. I e, determining how loud a voice currently is, or will be, is far from trivial.

I normally use Qsynth, and am thinking there is no way (at least in the
GUI) to change the parameters.

In looking at the man-page for Qsynth, I saw the following option info:

        -o, --option [name=value]
               Define a setting name=value

Ok, that is good to know!

// David



reply via email to

[Prev in Thread] Current Thread [Next in Thread]