Implementing brightness balance eq voicing

[larspalo]

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

[Bumblebee001]

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.

[Bumblebee001]

Not to mention also the not-uncommon situation where a user/ organist might bring together samples from different sets to make a composite instrument....

Conclusion: please do not underestimate the value of what is being requested and I hope that GO will move forward expeditiously on this matter.

[oleg68]

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

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.

[larspalo]

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.

[larspalo]

Another version where the filtering is implemented as 1st order which has a milder curve can be tested at https://github.com/larspalo/grandorgue/actions/runs/8695970872 for comparison with the version above. The less steep reduction curve might actually be advantageous as the goal with this feature is to alter the tonal characteristics, not just eliminate some frequencies. This was actually suggested in #1596 (comment). The amount of calculations and state storage is also slightly less with this version.

Frequency plot of the same white noise sample as above with this version has a minimum lowpass with slider at -1:

Maximum lowpass with slider at -100:

Minimum highpass with slider at 1:

Maximum highpass with slider at 100:

Except the choice of actual frequency range that can be affected, one could perhaps consider another cutoff frequency conversion from the slider value (like more logarithmic than linear). There are so many options available and details to think about... As I personally don't think that there are no "absolute best" version to be found I'd ideally like some GO user feedback on this feature before we make any "final" decisions on the implementation details. If this truly is such a "sought after" feature as some (@Bumblebee001) has led me to believe, I'd expect that a lot of user/community involvement would be good.

[larspalo]

It would be great getting some feedback from all GO users on:

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?

[Jean-Gabriel1982]

Hello everyone,

First of all a huge thank you to @larspalo for implementing the Brightness balance, Trebble and Bass function in GO. I am convinced that this function is, I would say, crucial in the development of GO. It will add extraordinary added value to the program.

In fact, being able to very finely adapt the organ that we have under our fingers, to the place where it will sound, in addition to adjusting the volume, amplitude and gain, will allow the user to have an instrument that "sounds".

Like @oleg68 I think that the function should not be part of the .organ file, but set by the user specifically for the place where the organ sounds.

So rather in the .cmb parameters. of course I am completely willing to fully test this function and provide feedback.

[Psi58]

(1) Do you think this feature is worth adding to GO?

• YES! I will certainly make use of it once it is incorporated into a release. I don't have the skill (or perhaps, to be honest, the patience) to fiddle with Audacity and LoopAuditioneer etc to tweak tonal qualities for my environment, whereas this is very easy to use.
• I also suspect it will be very useful for anyone assembling personal composite samplesets, trying to blend pipes from different sources.

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

• The 1st order filtering is more subtle, I prefer it. I suspect that it would be good enough for most users in most cases; if more extensive modification is needed there are other tools...

(3) Is the affected frequency range suitable in your opinion?

• In my limited experience, yes. It's always the 2' (and above) ranks that I want to tweak in my home environment, and this seems fine for them.

(4) Is the response from the slider/value feeling appropriate to you?

• A couple of comments about the UI

1. I found it quite hard to reset the slider to precisely zero when I wanted to listen to the 'original' sound again. Maybe there could be a 'Reset' button or similar to the right of it.

2. As @Bumblebee001 suggested in another discussion it would be an improvement if the need to press "Apply" was bypassed. I get that the computational load would be huge if changes are continuously made in real time whilst the user is dragging the slider, but perhaps they could be applied when the slider is released?

Many thanks @larspalo for developing this - a significant step in GO development.

[larspalo]

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.

[Jean-Gabriel1982]

Dear Lars, sorry for silly questions .. how to install your builds to test on windows ?
🫣

[larspalo]

As this is very much for testing only I'd recommend downloading the windows .zip version, like for instance https://github.com/larspalo/grandorgue/actions/runs/8707267180/artifacts/1418534516 and just run it in place without any installation. If you want to test the other versions just look for the windows .zip file.

[Jean-Gabriel1982]

Thank you !

[oleg68]

@larspalo Thank you for implementation of bass/treble balance. I've made some tests with all three variants you provided: 3.14.1-0.1, 3.14.1-0.2 and 3.14.1-0.3.

There a few notes.

1. 3.14.1-0.2: setting even -100 or 100 affects the sound very little. 3.14.1-0.1 and 3.14.1-0.3 change sound essentially.
2. I've confused with the label Brigtness, because I have a maximal brightness with the zero value. Any other values give less brigtness because this functionality works as a filter.
3. I expected that a positive value would increase treble and decrease bass, and a negative value would increase bass and decrease trebble. But GO does not increase anything, so the volume always becomes less. As a minimum it might be compensated with an increasing the volume. But increasing bass/treble as well as decreasing the other would be preferable.
4. When I set a value for a rank, now it affects different notes differently. For example, setting brigtness to 100 influenced the great octave but does not affect the third octave at all. I expected that the pass values for the filter would depend on the pitch of the note so all notes would be affected in similary.

[larspalo]

@oleg68 Thanks for testning.

1. Correct, that's party why I increased the range for the 1st order filter in the later build.

2. and 3. A lowpass and highpass filter always cut away frequencies but the point is that the tonal balance will change because of it. In you move the slider towards the treble side the bass frequencies will be supressed/reduced which makes the sound thinner and "brighter". Moving the slider towards the bass side will make the sound duller or "less bright". Loss of amplitude can be compensated with gain/amplitude level. This feature is about tonal balance.

For 4. Correct, the calculated cutoff pitch is the same no matter the level, which is why it's best to mainly work at pipe level. But sometimes it might be enough to correct/adjust the balance with rank level. If it's not enough, adjust at pipe level.

[davidgritter]

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.

[davidgritter]

I did play a bit more with what I was proposing, with separate lag-lead(low pass) and lead-lag(high pass) sections, but any attempt to mix between their outputs or between their outputs and the input signal rapidly devolves to transfer function very similar to what you are proposing above, so the best case solution along the lines I was proposing is a simple first order filter with adjustable numerator time constant and separately adjustable denominator time constant. This would allow attenuation or boost over only a limited range of frequencies up to boosting or attenuating 20db per decade over the entire audible frequency range.

[oleg68]

@larspalo

My very first eq attempt (published around #1596 (reply in thread)) was more like a 3 band equalizer where gain could be applied individually within each band, but that was deemed to be too complicated by some of the requesters of this feature.

I agree that a 3-band eq would be too complex. The single brigtness value is sufficient.

My suggestions are

• to make that the cut-off frequencies would depend on the pipe pitch
• to adjust bass level automatically when cutting treble and vice versa

Now when I've thought a little more on the implementation details I think that it might be useful to move the ownership of the eq filtering to the sound provider itself and not have it in the sampler like in the builds above in this thread (it would reduce the amount of calls to initialize the filters).

Sound provider is not mutable during the play, so it could not keep m_state. Sampler is mutable so it is a better place for it. But eq coeffs may be kept in the sound provider indeed.

Also, the sound provider could easily have multiple eq filters so that we could do different types of filtering and customize them much more

Do you find it necessary?

I'll look into the possibility of adding low-shelf and high-shelf filters too, the high shelf filter would be top candidate for an expanded swell box model.

Yes, it would be very interessing.

With some work I think it would be possible to utilize the slider and textbox value for multiple eq functions that could be selected from a dropdown choice of some kind.

For now I would not bring additional complexity to the UI and I would just make the single slider more similar to an ordinar timbre control of an audio amplifier: when you increase treble or bass, the sound volume is not decreasing.

[larspalo]

My suggestions are

to make that the cut-off frequencies would depend on the pipe pitch
to adjust bass level automatically when cutting treble and vice versa

There is a very good reason why the cutoff should be possible to set completely without any regards to the existing pitch. That's because one might want to intrude more or less into the existing harmonics of a sample and not rely on any specified pitch that might be valid or not. If you're very much concerned about the supposedly poor effectiveness of applying filtering on a higher level than the pipe, I would even consider dropping the possibility to set it on any other level (Organ, WindchestGroup, Rank) than the Pipe where it's very effective. Would you prefer that approach? Or do you want that the setting on any higher level than Pipe only would apply for the lowest pipe and then be auto scaled upwards by semitones (MIDI notes and perhaps also adjusted for harmonic number)?

Adjusting gain to exactly match the loss of gain from filtering is not trivial. The compensation of loss would depend on knowing exactly how much would be lost from the filtering - which would require an average measurement of the sustain section before and after filtering to not have fluctuating gains from buffer to buffer. I think that it's much better and easier to just let the user take responsibility to judge exactly how much more gain needs to be applied after the filter has been applied. GO already allow the user to do this according to his/her own taste.

Sound provider is not mutable during the play, so it could not keep m_state. Sampler is mutable so it is a better place for it. But eq coeffs may be kept in the sound provider indeed.

So you're saying that the sound provider cannot have a member that is the filter itself (or maybe in the future a vector of filters) that handle the buffer processing and also is storing of the history state? It could only have the coefficients (and setup calculations for them)? I've not tested it myself yet so I cannot say for sure how it would behave. The most obvious concern I'd have about that is if it would be necessary to re-set the state when it has finally decayed. My main thought with moving the ownership was to avoid having multiple initializations of the filter that the sampler inevitably needs anytime when it's passed on whereas the sound provider (pipe) pointer could have it ready whenever the sampler is passed. As the sampler has a pointer to the sound provider I just figured it would be just as easy to send the buffer to the filter there from the sound engine.

Do you find it necessary?

Necessary with more filters? No, not really. But it could be nice. What I'm thinking about is:

• This "Brightness balance" that's maybe better named as "Tone balance"
• "Stereo balance" that just changes "panning" amplitude of the played sample channels
• A "Low/High shelf Eq" that maybe would be more like what you're thinking of but needs four parameters (Low center frequency, Low Gain +/-, High center freqency and High Gain +/-) which would allow even more control of the tonal shaping and gain adjustments in the filter itself
• For every enclosure having a High shelf filter that allow to specify Center frequency and max dB attenuation (of the high shelf) when fully closed. The extra effect of the filter would of course be modulated by the swell pedal position for respective enclosure. This last filter should also be available to specify in the odf. If they should or shouldn't be user configurable is another design choice to make. But if we add it in the GUI this feature could be applied to older sample sets easily without modifying the .organ file

But maybe you're right. For now it might be enough to just add this kind of simple tonal balancing.

[davidgritter]

I've attached my propoal as a pdf with some frequency response graphs for a couple examples. This proposal would be implemented using settable lead frequency (boost) and lag frequency (decrease). I've inlcuded a SCILAB script showing how to calculate the coefficients for an implementation equation. A decription of how to calculate the bilinear transform for the necessary coefficients is at

https://www.qorvo.com/resources/d/from-continuous-time-domain-to-microcontroller-code

brightness control.pdf

[larspalo]

@davidgritter I'll have a look at it later in more detail. From just a quick glance it seems to have a drawback compared to the lpf/hpf version in that low frequencies cannot be cut, which would make it impossible to "trim away" unwanted low frequency noises (like for instance key action left in the sample).

[oleg68]

@larspalo

So you're saying that the sound provider cannot have a member that is the filter itself (or maybe in the future a vector of filters) that handle the buffer processing and also is storing of the history state?

I would create an inner class GOSoundEq::EqState and I would move the history state (now it is only m_state) there from GOSoundEq. Then GOSoundProvider would own a GOSoundEq instance (or a vector of them), and GOSoundSampler would own a GOSoundEq::EqState instance.

My main thought with moving the ownership was to avoid having multiple initializations of the filter that the sampler inevitably needs anytime when it's passed on whereas the sound provider (pipe) pointer could have it ready whenever the sampler is passed

Most of the initialisation of GOSoundEq might be done only once when the organ is loaded or when the brightness changes are applied. The only part of initialisation that must remain at the sampler level is zeroing of m_state as like as the inicialisation of GOSoundEq::EqState.

[oleg68]

• This "Brightness balance" that's maybe better named as "Tone balance"

I like the name Tone balance more than Brigtness.

[larspalo]

@oleg68 I agree with everything you've written here and in the post above. But perhaps also the buffer processing method should be moved to the new inner class that handles the state as it's only that method that needs the history state, or should the buffer processing still be in the outer container class?

[oleg68]

The inner class is close to the container class, so it does not matter where ProcessBuffer is. Both variants are acceptable.

[Jean-Gabriel1982]

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)

[Psi58]

Valid reasons have been explained for implementing filter controls in the cmb and also in the ODF. Could we, ultimately, have both?

As user-level control seems to be the main driver for this in the short term, do this first (phase 1).
Then, when that implementation is stable, create a utility to import the filter functionality and settings from the cmb to a modified ODF (phase 2), allowing sampleset producers etc to "bake in" the filtered samples?

[larspalo]

allowing sampleset producers etc to "bake in" the filtered samples

The filtering we can implement for real-time usage will never equal the capability of what can be done in an external audio editor. I don't want to encourage poor workmanship in sample preparation by allowing pipe voicing into the odf! Sample set producers should instead do the right thing outside of GO, users of GO should have possibility to adapt samples to their likings inside of GO.

[pgcrowe]

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.

[larspalo]

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.

This you're absolutely 100% on target with. For now, what I think we'll stay focused on, at least to begin with, is the fast real-time implementation that allow a "decent enough" sound adjustments for the user who wish to deviate from the recorded samples as presented in the sample set. However, even on the basics, there are lots of things to consider and think about. More test builds will come so that options can be tested and evaluated.

[pgcrowe]

Sounds good!

[larspalo]

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

[Bumblebee001]

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: ***@***.***>

[oleg68]

@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 likes sliders, I would add a separate Voicing panel with lots of sliders for all notes and real-time applying.

[larspalo]

If @Bumblebee001 likes sliders, I would add a separate Voicing panel with lots of sliders for all notes and real-time applying.

That could be interesting to see! However, I don't find that essential, as there is already another way to do the voicing adjustments that works just fine.

I'll go ahead and work on another version without slider and with a more general filter class as a foundation for the tone balance feature class. I think that a GOSoundFilter class that could be utilized for different features could be beneficial for the future.

[pgcrowe]

Excellent, I'm very much in favor of a GOSoundFilter class. It follows the same logic of the GOSoundFader, and how it is used both for crossfades and release shaping.

SFZ has support for controlling filters with fade envelopes. It may be worth preparing an integration of similar control between GOSoundFilter and GOSoundFader. In the future, that could control the filter transitions between the various stages of swell shade opening, provide tremulant control for specific frequency ranges and individual overtones, etc.

[Bumblebee001]

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: ***@***.***>

[larspalo]

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.

[oleg68]

@larspalo I've tested you new version.

• From the functionality point of view it is quite good for adjusting one pipe and the whole rank pipe-by-pipe. The result of setting the rank level tone balance is not what I expected, but for the first version it is acceptable.
• From the GUI point of view it is better than the old one. If @Bumblebee001 wants a separate panel with lots of sliders we can add it later: the functionality will already exist.
• From the code point of view splitting across several classes and files is OK. I hope we will reuse some of them for adding other features.

There are several notes on the code, but I'd make them on the PR.

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.

No, I don't. I found your variant of calling SetSampleRate from PreparePlayback as good enough.

[larspalo]

@oleg68 What about the effective tone balance value? Currently it's implemented as a simple summation of all the elements values. I've recently begun to wonder if it wouldn't be better to have an overriding approach instead. That is, if value is 0 on a child level but parent is set to something else, use parent value, but if a child has a value set - use that instead of the parent value. What approach would you think is the best to use?

The issue I think with the effective sum is that if say rank is set to -75 then a pipe value of 100 would only yield an effective value of 25, which maybe isn't what one would expect. As, you said, it's most effective to work on the pipe level, but if someone sets a value on a parent they might be surprised by the effects on the children...

[oleg68]

I would support the additive approach if the tonal balance behavior took the pipe pitch into account. But for the current behavior the overriding approach looks better.

[larspalo]

@oleg68 @rousseldenis I've altered the get effective value to let children just override a set value of parent, which I feel gives a more appropriate response. Latest builds are available at https://github.com/larspalo/grandorgue/actions/runs/8880894813 for testing. Do we deem this is as PR ready and maybe possible for scheduling (adding as milestone) into a future new feature release?

[oleg68]

@larspalo Yes, I'd be happy to see this PR. We may add it to 3.15.0

[mutti-wilson]

Is the plan to roll this out first and integrate this into the swellbox model? Really looking forward to this.

[larspalo]

@mutti-wilson It's prepared for, but not yet implemented. Too much other things to do right now!

[mutti-wilson]

I understand. It's exciting that the feature is not too far down the road.

[hnb2907]

I'm really looking forward this too! :)

[hnb2907]

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