Treble/ Bass Balance #1596
Replies: 16 comments 18 replies
-
|
+1 to the suggestions of @Bumblebee001 I wanted to post a similar post, so just want to confirm the big big interest in those improvements. |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunally. I don't have any idea how to implement Treble/Bass tuning of each pipe this without huge CPU consumption. It can be done on the audio group level only, because there is only few audio groups. |
Beta Was this translation helpful? Give feedback.
-
|
Surely if the samples are correctly tuned then all the organ's pipes will automatically be in tune. Or am I missing something? I do know that some of the older samples were a bit out of tune but was under the impression that had been recently fixed. If you want to alter the treble/bass balance then surely this is easy to do in the main audio (pre) amplifier. The only filter that still ought to be implementes is that which should be in the swell pedal/s. I do not think that copying HW is a good idea - I know a lot of organists think it is the last word in quality but many, more knowledgable, people would disagree. csw900 |
Beta Was this translation helpful? Give feedback.
-
Tuning pipes by several cents or even semitones requires resampling. This action consumes some CPU power, but not very much, so it is implemented in GrandOrgue now. But adjusting level of Bass/Treble requires two ff-transformings, that is more CPU intensive. When GrandOrgue plays several pipes with some polyphony level, the audio signal of each pipe is added together. If we implement the whole organ Bass/Treble correction, GO will do
But if we implement Bass/Treble correction for each pipe, GO will do
The second options requires much more ff-transformings (for each pipes separatelly instead of once for the summary signal). |
Beta Was this translation helpful? Give feedback.
-
|
There are other ways to do this. |
Beta Was this translation helpful? Give feedback.
-
|
Cannot the FF transforms be fully avoided using the convolution theorem? I suspect that we can store the inverse Fourier transform of the bass/treble adjustment, and simply convolve it with the pipe sample. |
Beta Was this translation helpful? Give feedback.
-
|
Personally, I don't think such feature should be in GrandOrgue. As @midimusic said, IMHO such things should be managed after (amplifier, ...). We should focus on other features |
Beta Was this translation helpful? Give feedback.
-
|
Clearly then you don’t understand the meaning of voicing.
…On Sat, 08 Jul 2023 at 23:08, Denis Roussel (ACSONE) < ***@***.***> wrote:
Personally, I don't think such feature should be in GrandOrgue. As
@midimusic <https://github.com/midimusic> said, IMHO such things should
be managed after (amplifier, ...)
—
Reply to this email directly, view it on GitHub
<#1596 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABVM7NXPJBMFEQWRBETIDS3XPHD4TANCNFSM6AAAAAA2CTNCJ4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
The advantage of having such a feature in GrandOrgue would be to have a set of audio tunings proper to each organ and stored by GrandOrgue, so no need to readjust the external amplifier when we change the loaded organ. |
Beta Was this translation helpful? Give feedback.
-
|
Just for testing, I've done an implementation of a per pipe controllable eq with (relatively) adjustable cutoff frequencies for mid/high and bass/mid and individual band applied gains that's available in the OrganDialog. No higher level (rank, windchest or organ) than the pipe was implemented as this test is purely academic at the moment. Nor is any saving of the eq settings implemented as I don't want to have .cmb settings files created that won't be compatible with mainstream GO. That said, those interested in testing it, as it currently is, can find builds at https://github.com/larspalo/grandorgue/actions/runs/5564161290. The toll on available polyphony is huge, preliminary tests show a reduction to almost one third of the current GO master. Thus, I'd be inclined to agree with both @rousseldenis and @oleg68 that it's not a good idea to implement any per pipe filtering in GO unless someone can do a better implementation than I've done... Any filtering is (at least for now) better done in the sample production stage than in GO. I think that might be productive to continue the investigation of creating more sophisticated swell box models with filtering though, but the pipe voicing aspect with eq should better not be done fully real time as it seems to limit the available polyphony too much. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, but we would need to re-design the sound engine. |
Beta Was this translation helpful? Give feedback.
-
|
Basically only route the pipes with changed gain levels for bass, mid or high through the eq and otherwise just never go through it. I can quickly test a crude version of it and compare. |
Beta Was this translation helpful? Give feedback.
-
|
@oleg68 You're right. Simply adding a selection only to apply eq when needed brings back the polyphony. The init process is not reducing polyphony and that's where the logic check if eq is needed or not is done. But there's much work remaning if, and I really mean if, we want to include this or anything similar in GO. |
Beta Was this translation helpful? Give feedback.
-
|
A new build with eq added only when needed is available at https://github.com/larspalo/grandorgue/actions/runs/5566517684. |
Beta Was this translation helpful? Give feedback.
-
|
I second the swell box modeling. Great discussion and work here. Look forward to seeing where it goes. |
Beta Was this translation helpful? Give feedback.
-
|
The idea is to able to voice individual pipes or a particular rank NOT the
whole organ. The latter can obviously be achieved by changing setting
elsewhere. The changes done during voicing would then be saved in the cmb
file so every time the organ is loaded those saved adjustments would be
read by GO as the odf would be. Just as one would have specific
instructions for so many things in the odf there will be an additional bit
of data showing how much bass or treble a note is to be sounded as.
Would this involve so much use of computer power?
…On Sat, 15 Jul 2023 at 23:42, larspalo ***@***.***> wrote:
Just for testing, I've done an implementation of a per pipe controllable
eq with (relatively) adjustable cutoff frequencies for mid/high and
bass/mid and individual band applied gains that's available in the
OrganDialog. No higher level (rank, windchest or organ) than the pipe was
implemented as this test is purely academic at the moment. Nor is any
saving of the eq settings implemented as I don't want to have .cmb settings
files created that won't be compatible with mainstream GO. That said, those
interested in testing it, as it currently is, can find builds at
https://github.com/larspalo/grandorgue/actions/runs/5564161290.
The toll on available polyphony is huge, preliminary tests show a
reduction to almost one third of the current GO master. Thus, I'd be
inclined to agree with both @rousseldenis
<https://github.com/rousseldenis> and @oleg68 <https://github.com/oleg68>
that it's not a good idea to implement any per pipe filtering in GO unless
someone can do a better implementation than I've done... Any filtering is
(at least for now) better done in the sample production stage than in GO.
I think that might be productive to continue the investigation of creating
more sophisticated swell box models with filtering though, but the pipe
voicing aspect with eq should better not be done fully real time as it
seems to limit the available polyphony too much.
—
Reply to this email directly, view it on GitHub
<#1596 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABVM7NWM57VOIZLKDW7URP3XQMFDHANCNFSM6AAAAAA2CTNCJ4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Have you even tested the GO build I linked to above so that you know what I've done? And yes, when it's done in real time on a per pipe level and not pre-computed into a copy of the whole wave data for the provider - then it's very computation intensive. If it would be done on a copy - then the memory requirement would increase... |
Beta Was this translation helpful? Give feedback.
-
|
I've been thinking about this, and have looked at what Lars Palo implemented, which is the correct approach, but can perhaps be simplified. I think that most voicing can be accomplished just by changing individual pipe volume, which is already possible in GrandOrgue. That's what's most often done in the field, unless a pipe has a speaking defect. But for sampled pipes, these defects should already have been taken care of. Typically I've found that in GrandOrgue I want to change the volume of pipes gradually over a range simply because I'm playing the entire organ at a different volume level than was originally intended. I would propose that for a single pipe, only one of three possibilities needs to be applied:
A common static storage location is needed for the filter on a per pipe basis. Only one is needed, since all three compensators are based on 1. the low pass filter, and only one of the three need be applied parameters required are a cutoff frequency, a selector for the desired function, and a high frequency attenuation parameter for 2 I've attached a block diagram showing all three compensators implemented together, but not showing the mechanism to pick one, and showing the responses to a chirped sine wave input when the cutoff frequency is set at 100 Hz. The calculations at the upper left, are of course done only once when the parameters are entered. |
Beta Was this translation helpful? Give feedback.
-
|
Some of my replies do not seam to appear in this discussion. @ Lars: you have included too many parameters in your test build. What I was expecting was a simple: Bass------------------^----------------------------Treble Bass at one end and Treble at the other and a slider in between. As one increases the Treble, the Bass decreases at the same time and vice versa. This function existed in audio equipment hardware since my youth. I'm sure the whole matter can be greatly simplified and yet remaining effective in achieving some control over brightness. Whilst sample-sets ideally have these corrected on the original samples, organists may still want to vary these accordingly to satisfy their own tastes. Some people's hearing is far more acute than others and they can hear sounds far better than sample-set producers. |
Beta Was this translation helpful? Give feedback.
-
|
@Bumblebee001 Somethings I'll never be able to understand are things like this... You've just been offered a Ferrari for free, but you refuse, complain, and want a Goggomobil instead! Anyway, jokes aside, at https://github.com/larspalo/grandorgue/actions/runs/5604507504 there are builds of a first, very simplified version of individual pipe eq, or brightness control that I've created. Same type of limitations mentioned above still applies as this is at best only a draft or test of a concept. |
Beta Was this translation helpful? Give feedback.
-
|
Hahahaha..... If I was offered a Ferrari for free...... I would definitely accept it...... but to sell it NOT to keep it. How would I be able to afford the fuel consumption or its maintenance costs when on a meagre pension?It would have been unaffordable even if I still worked let alone. Yes..... joking aside.... I was merely trying to get this feature included in the climate of antagonism / lack of acceptance by the developers on one side and the need for so much computing power if it were implimented. I was expecting a reply more along the lines of "Is that all you want? Oh that's easy? Good idea. Yes we'll do it. No problemos." I reiterate, I will accept the Ferrari if you've got one. I'll send you my address in a private email! ;-) |
Beta Was this translation helpful? Give feedback.
-
|
P.S. Whatever is implimented at the end of the day has got to be simple to understand and to use and practical..... i.e. it must be very user-friendly for the general and less technical organist. To drive my car I didn't need to understand how the engine is made and how it actually works. |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately that what's "simple to understand and to use" tend to also be limited, non-flexible and less capable than that what might require just a little more brain usage... The moment one actually understand how things work, one can start tuning things to greater performance, which I think "the general and less technical organist" should strive to understand and put some effort into reaching a higher level. By the way, the combined amount of work all the developers of GO has put into it, especially when one add the work done by sample set producers to provide free sample sets, some of which has a quality that's well beyond many commercial options, the total value at your hands is likely exceeding that of a Ferrari many times over. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with you there larspalo,
Developing an application, it’s dependencies, resources, is more of a challenge than people think. Been there, done it, worn the shirt. GrandOrgue is a unique system and a competitor against H|auptwerk, the challenge is trying to provide the right mix of features and support with a team of developers with different specialities and backgrounds. You’re all amazing and skilled people. If it takes time to fix an issue or compile a release, so be it, the product at the end of the day is free, it would be a different argument if it was a product sold and license costs, etc.
lew
… On 20 Jul 2023, at 08:11, larspalo ***@***.***> wrote:
Unfortunately that what's "simple to understand and to use" tend to also be limited, non-flexible and less capable than that what might require just a little more brain usage... The moment one actually understand how things work, one can start tuning things to greater performance, which I think "the general and less technical organist" should strive to understand and put some effort into reaching a higher level.
By the way, the combined amount of work all the developers of GO has put into it, especially when one add the work done by sample set producers to provide free sample sets, some of which has a quality that's well beyond many commercial options, the total value at your hands is likely exceeding that of a Ferrari many times over.
—
Reply to this email directly, view it on GitHub <#1596 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATQDNKLU4WCJO6VBCOUGRP3XRDK2FANCNFSM6AAAAAA2CTNCJ4>.
You are receiving this because you are subscribed to this thread.
|
Beta Was this translation helpful? Give feedback.
-
|
In the real world of pipe organs organists don’t get to tune or voice the
instrument they play! It’s in the virtual world that attempts at tuning and
voicing is done because it is easier, accessible, presents no physical
danger and requires no equipment besides it is easily reversible if not
done correctly.
…On Thu, 20 Jul 2023 at 09:11, larspalo ***@***.***> wrote:
Unfortunately that what's "simple to understand and to use" tend to also
be limited, non-flexible and less capable than that what might require just
a little more brain usage... The moment one actually understand how things
work, one can start tuning things to greater performance, which I think
"the general and less technical organist" should strive to understand and
put some effort into reaching a higher level.
By the way, the combined amount of work all the developers of GO has put
into it, especially when one add the work done by sample set producers to
provide free sample sets, some of which has a quality that's well beyond
many commercial options, the total value at your hands is likely exceeding
that of a Ferrari many times over.
—
Reply to this email directly, view it on GitHub
<#1596 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABVM7NSCQYGEAOA4GBSMDELXRDK2DANCNFSM6AAAAAA2CTNCJ4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Actually, I do many such things in real life (at least partly, since for the more serious things I usually hire an organbuilder). The fact that I'm privileged enough also allows me to share some of that with the rest of the world. My hopes are, as always, that more people will learn to appreciate the pipe organ as an instrument and help preserve them in real life too. |
Beta Was this translation helpful? Give feedback.
-
|
Indeed. I share the same sentiments. It is what has motivated me to produce free sample-sets to share with the world. I appreciate the hard work involved and priveleged to be part of this community and be able to partake in this "mission" in a direct and concrete manner. Mark Bugeja |
Beta Was this translation helpful? Give feedback.
-
|
@larspalo are you going to make a PR with the bass/treble balance feature? |
Beta Was this translation helpful? Give feedback.
-
|
@oleg68 If there is a great interest in it, I can re-work it into a PR. However, I have a feeling that the (backend) EQ really should be more versatile so that we can use it in different ways than only the simple pipe voicing bass-treble slider in the future (like expanding the enclosure model). Also, one of the things I'm not decided about, that most likely needs to be improved from the simple eq version that I demonstrated above, is how the inheritance/overrides should be made between pipe->rank/stop->windchest->Organ level(s). Do you have any thoughts about that? In the end it's an individual pipe that needs to be adjusted and the adjustment really should be calculated in as few steps as possible to not be too heavy on the available polyphony. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Lars, I am working on another sample-set and I am having issues voicing pipes after doing noise reduction etc. I am having to use other software to achieve some degree of adjustments needed but unfortunately working with different software is resulting in some things, created with another, to be lost eg after using Audacity the markers disappear and I have to re-load the samples again in the previous software to re-create them anew. Would it be possible for your GOODF to allow such adjustments and for these changes to be incorporated into the odf instead? It would make some sense for a sample-set creator to be able to voice pipes through the software that is helping create the sample-sets themselves. GrandOrgue features should allow the user to make further changes if necessary or according to preference or to accomodate for the particular system set-up (eg sound card, speakers etc) being used to play the sample-sets. |
Beta Was this translation helpful? Give feedback.
-
I think I'll essentially only add things to GOODF that can end up in the odf usable in GO. However, I could possibly expand LoopAuditioneer to do more adjustments to the samples (audio files) themselves to avoid moving the samples to and from Audacity so much. Basically I want to keep all sample modifications in LoopAuditioneer and the odf related things in GOODF. It's very likely though that if the waveform is changed very much by any effects, any previously added loops might need slight adjustments to sound perfect. I've just recently added the possibility to view/inspect the FFT power spectrum of a file to set the embedded pitch from it to ensure even better quality control. Since this forum is geared more for GrandOrgue features, we could perhaps continue this discussion over mail or elsewhere so that I can learn more of what kind of features you feel the need of having. |
Beta Was this translation helpful? Give feedback.
-
+1 for that idea. The level of technical complexity in this discussion is beyond me (it's over 40 years since I last had to understand FFTs etc), but if sample editing could all be handled in LoopAuditioneer that would make it an even more powerful tool. I've experienced the same issue as @Bumblebee001 with Audacity losing embedded data when I've been trying to clean up 'dirty' samples in a new sampleset (eg the occasional pipe that presumably still had a graveyard of flies in it before sampling, and others that had a very slow attack). If LoopAuditioneer could be the place to go for sample adjustments, rather than a workflow involving several tools, that would be a great improvement. And if you could make another of your excellent videos to instruct us how to use it properly that would be even better! |
Beta Was this translation helpful? Give feedback.
-
Hi,
I have on a previous occasion requested that GO will have the added function of adjusting tone to sample-sets. Basically one needs to add Treble - Bass balance functionality which is currently missing.
Secondly, all voicing adjustments needs an added function - the ability to hear in real time - the adjustments as they are made. One cannot tune or voice unless the changes can be heard or measured with a Tuner (eg an iPhone app).
Thirdly, Sliders might be a better and neater way to make changes considered necessary. OK... it might be thought of as merely aesthetics at the end of the day - but not so in practice! If one compares GO to Hauptwerk, sliders can be added in similar way to HW to allow individual (note by note), group (octave by octave) or even whole rank adjustments to be done simultaneously.
HW has been receiving bad press in the way it has been developed beyond v4.2 and sold and many are very upset. GO, still free and hopefully will remain so, has been touted as a better alternative. Let's make it the best, not just better. To achieve this, sound quality may need particular attention. This would be one step towards that goal. There may be other considerations eg filters etc.... but I am not one who knows much about this so I cannot say anything else on the subject.
There are other aesthetical issues I would like to see changed in GO but I think I will leave those for another occasion. What I asked for above and in the recent past is a priority and yet to be given its due attenion and implimented.
Beta Was this translation helpful? Give feedback.
All reactions