Implementing brightness balance eq voicing #1882
Replies: 18 comments 32 replies
-
Hi. Everyone has his/her own systems (sound card, amplifiers, speakers) and environments all of which will effect the quality of sound not to mention the sense of hearing in different people...... Voicing parameters should be available to all and should be easy and quick to apply to suit the myriad of circumstances and personal preferences irrespective of what sample-set producers offer. |
Beta Was this translation helpful? Give feedback.
-
I agree with this approach. I wouldn't add this feature to ODF. I could think about some optimization: to summarise all playing samples with the same brigthness value before passing to the eq. But this can be made later, not now. |
Beta Was this translation helpful? Give feedback.
-
At https://github.com/larspalo/grandorgue/actions/runs/8687731843 there are builds of the latest version I've done if someone wants to test it. This voicing correction is best done on the pipe level, but if a whole rank or other parent needs overall adjustment it's possible to set too. Those daring to test this should pay close attention to how the changes of the brightness slider/value affects the tone for a great variety of pipes at different frequencies to determine if the current parameter ranges are "good enough" at affecting a wide range of cases. Below comes frequency plots to see how the filtering does affect the audio signal. First the original white noise file used to test the filter: Next comes a minimum lowpass (or high cut) which equals to a brightness slider value of -1: Followed by a maximum lowpass at a brightness slider value of -100: Then on the other side a minimum highpass (or low cut) of a brightness value of 1: Followed by a maximum highpass where the brightness slider is 100: For those interested in the details about the implementation: I've used the RBJ Audio-EQ-Cookbook biquad coefficient calculations (can be found at https://www.w3.org/TR/audio-eq-cookbook/ among other places) with a transposed direct form 2 that should be more efficient than the direct form 1 mentioned in the cookbook. At least there are less history variables to keep track of using form 2... Depending on the slider position (0 means that no filtering will be applied) either a lowpass (high cut) or a highpass (low cut) filter will be applied with a corresponding cutoff frequency. This only removes certain frequencies which will make the other stand out more but in some cases it's also necessary to adjust the gain/amplitude level to compensate for the loss - but this is of course readily available in GO. Set values will be saved with the settings file (.cmb) and I highly recommend that while testing this and until a final version perhaps is included in GO: don't save an organ - use the export settings option instead to not mess up any presets! This naturally means that the exported settings also must be imported to take effect. |
Beta Was this translation helpful? Give feedback.
-
It would be great getting some feedback from all GO users on:
|
Beta Was this translation helpful? Give feedback.
-
(1) Do you think this feature is worth adding to GO?
(2) Which version of filter rolloff/slope would you prefer, https://github.com/larspalo/grandorgue/actions/runs/8687731843 or https://github.com/larspalo/grandorgue/actions/runs/8695970872?
(3) Is the affected frequency range suitable in your opinion?
(4) Is the response from the slider/value feeling appropriate to you?
Many thanks @larspalo for developing this - a significant step in GO development. |
Beta Was this translation helpful? Give feedback.
-
A new build of the 1st order filtering with increased frequency range and a logarithmic slider position to cutoff frequency conversion can be found at https://github.com/larspalo/grandorgue/actions/runs/8707267180 for testing and comparison. |
Beta Was this translation helpful? Give feedback.
-
@larspalo Thank you for implementation of bass/treble balance. I've made some tests with all three variants you provided: There a few notes.
|
Beta Was this translation helpful? Give feedback.
-
I am concerned about a second order filter, particularly a low pass, as that behaves as a formant, giving a more or less reedy sound to a flue pipe. Typically first order formats were applied to sawtooth or square waves in the analog days to create flue pipes, while second order low pass formants, often well underdamped were applied to make reed sounds. I have less concern with the first order approach, but am still a bit concerned about having a cutoff frequency in the audible range. Perhaps if brightness control is how we are characterizing this we could apply a first order high pass and low pass l filter simultaneously whose frequency breakpoints are are adjustable and track each other We could then feed the original signals through these filters and then have a mixer to add the original signal and the two filtered signals together to control the degree of brightness. This would perhaps allow brightness control without inserting any sort of significanat format except near the filter breakpoints. I will play some games with this approach and publish some results. |
Beta Was this translation helpful? Give feedback.
-
I would create an inner class GOSoundEq::EqState and I would move the history state (now it is only
Most of the initialisation of |
Beta Was this translation helpful? Give feedback.
-
I like the name |
Beta Was this translation helpful? Give feedback.
-
Hello, I put a message from a professional, actually using Hauptwerk but very interested in changing for GrandOrgue : For harmonization in my opinion it is necessary: -have a note-to-note level adjustment (already the case on GO), -To this we must add a Brightness type setting (in HW) which plays on the level of I don't know that they are harmonics among the first without doubt. I think that we must consider a pyramidal logic: that the adjustment impacts the first harmonics at their strongest and the further we move away from the fundamental, the less it plays. So for example when you push the setting by 1 db it increases the frequency of the 1st harmonic by 1 db, the second by 0.5 db, the third by 0.25 etc... Basically it's an equalizer with several points programmed decreasing by 2, these different points being defined on the harmonics of the note being processed. -A note-to-note equalization system always. For this last point we could even do better than HW by choosing exactly the equalization frequency range for each note (in HW currently we have a high frequency parameter, without really knowing in what frequency it plays, probably around 10khz at first sight, and a mid frequency parameter less useful in my opinion). The ideal would be for each note to have an equalizer on which we can draw the curve as we want. Afterwards you have to find a practical solution for use, like this: when you are in equalization mode, you press the note and the equalization curve of the note is displayed, you change the note and it is another curve which is displayed which can be modified again etc. If it is too difficult we can consider a more rudimentary system like HW with a series of equalization points on which we move a potentiometer (like 1khz, 2khz, 4khz, 8khz, 12khz, 16khz, 20khz) |
Beta Was this translation helpful? Give feedback.
-
@oleg68 @rousseldenis What do you think about the slider idea at all? Personally I think it wastes quite a lot of space without introducing anything of significant value for the user. Without it we could just add a spinbutton to the right of the textctrl like the other settings and have one row free for other uses. |
Beta Was this translation helpful? Give feedback.
-
On a computer screen, sliders are more natural than knobs. In hardware both
are acceptable.
…On Wed, 24 Apr 2024 at 19:01, Pat Graham Crowe ***@***.***> wrote:
Lars: If a sample set producer is content to rely on lower quality real
time filters in a way that compromises sound quality, their workmanship
likely isn't that good to begin with. The realtime filters would be the
least of the problem! LOL...
I'm something of a "radical" moderate when it comes to these things, in my
belief that a central compromise is usually the best option. There must be
a balance between encouraging good workmanship, without debilitating the
flexibility of this wonderful platform. Likewise, we should ideally
benchmark industry standards, to implement features in a way that is
expected by developers of other platforms such as Hauptwerk, SFZ, Kontakt,
HALion, HISE, and others. All of those platforms have support for filter
parameters in their respective definition file formats. The same holds true
for gain envelopes, particularly in regard to release tail shaping. But
we've already discussed that ad nauseam. ;)
In Hauptwerk, there are many examples where sample set producers have
implemented non-permanent "voicing" tweaks in a definition file, so that
the user could "reset" or those changes if desired, and play the original
(perhaps slightly out of regulation) samples. For subtle filter changes,
simple IIR filters perform reasonably well, with distortion that isn't
noticeable to the average listener. For substantial filtering, it would be
nice to implement a FIR filtering system that processes the filters at load
time, and save them to the cache file to save future load time.
—
Reply to this email directly, view it on GitHub
<#1882 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABVM7NSE73MEPP6XDU2RMCLY67QODAVCNFSM6AAAAABGGLM5T2VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TEMJWGIYDC>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
I agree with you. Now the Organ Settings dialog does not contain any slider and I would not add it now. If @Bumblebee001 likes sliders, I would add a separate |
Beta Was this translation helpful? Give feedback.
-
I’m not asking you to reinvent the wheel to my satisfaction. Please look at
what hauptwerk has. It’s neat, it’s practical, it’s user friendly.
…On Wed, 24 Apr 2024 at 21:15, Oleg Samarin ***@***.***> wrote:
@larspalo <https://github.com/larspalo>
What do you think about the slider idea at all? Personally I think it
wastes quite a lot of space without introducing anything of significant
value for the user. Without it we could just add a spinbutton to the right
of the textctrl like the other settings and have one row free for other
uses.
I agree with you. Now the Organ Settings dialog does not contain any
slider and I would not add it now.
If @Bumblebee001 <https://github.com/Bumblebee001> likes sliders, I would
add a separate Voicing panel with lots of sliders for all notes and
real-time applying.
—
Reply to this email directly, view it on GitHub
<#1882 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABVM7NSP4MJ5TYZBE56RFLTY7AAENAVCNFSM6AAAAABGGLM5T2VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TEMJXGQ2DK>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
There are new test builds that implement some of the things discussed above at https://github.com/larspalo/grandorgue/actions/runs/8849296678 if someone wants to test them. Still, remember that they are test builds made for evaluating this feature and things are likely to change! So it's better to not save anything to presets but instead exporting settings (and importing them) during testing. @oleg68 The filter needs to have access to the samplerate to calculate the coefficients. In the earlier design I could get that as a parameter from the sound engine but with the new divided responsibility of filter and filter state I couldn't find an easy way to get that. I tried making the filter inherit from the soundstatehandler but for some reason the GetSoundEngine() would never give me a valid pointer. So, I took the long way around and passed it from the sounding pipe when the sound engine would be ready. I'd really appreciate to have other options suggested to me that would be cleaner, if you have some ideas about that. Feature is also renamed as "Tone balance", normal spinbuttons used instead of slider in the organ settings dialog and the config key is changed to reflect the change of feature name. With this separate filtering class approach, that's not limited to only the tone balance feature, it will be a very small step to implement a working high shelf addon to the swell box model in the future as it's more or less prepared for already. I could also fairly easily implement a more configurable eq that can boost and/or suppress the bass and treble individually and at freely chosen frequencies if that would be desired in the future. |
Beta Was this translation helpful? Give feedback.
-
Is the plan to roll this out first and integrate this into the swellbox model? Really looking forward to this. |
Beta Was this translation helpful? Give feedback.
-
I've just been trying out the tone balance in version v3.15.0-1, and I've found it to be very useful to improve the sound of a few "pipes" that now blend much better. Thankyou for implementing this feature :) |
Beta Was this translation helpful? Give feedback.
-
@oleg68 @rousseldenis I've recently played around a bit more with the possibility to add a simple eq voicing control to GO (only locally so far). In the organ settings dialog I've added a textctrl and a slider for adjusting brightness (Bass/Treble balance) that work down to pipe level with simple additive slider positions from parents to decide eq level (within a set total limit).
If the total effective slider value (BrightnessValue) indicate that an adjustment should be made filtering will be applied, else the sampler won't send audio data through the eq. This means that for a reasonable amount of voicing adjustments the polyphony won't be seriously restricted. Also the choice to make the effective slider position used for brightness adjustment with simple summations means that there will only be one pass through the filter and not multiple.
I've only added this as a cmb setting, which might upset some. But my reasoning is that it's users of GO that mainly should have the option to adjust the sample voicing to their liking. Sample set producers already have direct control over the samples themselves and can at will apply much better eq types in an audio editor with finer control than what is reasonable in a real-time application like GO.
What are your opinions about this?
Beta Was this translation helpful? Give feedback.
All reactions