Menu
▾
▴
#82 ODF - do not limit enclosures to a simple amplitude modulation
Hello,
I've made some odfs for sample sets made for HW. With the odf file format I can translate a lot of functionnalities of those sample sets, but I would like to be able to give a more precise realisation in enclosures. In most HW sample sets, the enclosures are defined by varying amplitude differently on several frequencies, and also filter extreme frequencies. I think it could be added to GO, and it's surely something I would like to see!
Kind regards,
E.D.
Discussion
Me too! I've been itching for something like this for years now, ever since 2016 when I first dipped my toes into the VPO world.
Better simulation of Enclosures with GO is already possible without modifications to GO.
Filtering is required to simulate the frequency-dependent damping of an enclosure. However, unlike HW, GO has no built-in filters. Whether that is easy to add I do not know. At least I can't. But I did find a relatively simple solution for this. To do this, a one-off filtering of the samples of a swell must first be applied in order to create a set of samples that represents the sound with closed swell.
In the Odf we then make an enclosure with the samples of the opened swell and an enclosure with the samples of the closed swell. By mixing these with one enclosure closing while the other opens, we can simulate all intermediate positions. Incidentally, this is easily done with one control element by linking both swells to one swell pedal via the midi, but in such a way that the “closedsamplesSwell” is inverted so with the minimum at 127 and 0 or a slightly higher number for the upper limit.
A Demo (for the Billerbeck Semidry Demo) can be found in the Filebase of MPS-orgelseite (https://mps-orgelseite.de/home/filebase/ ).
(Important: For English instructions, choose the English version of the website)
Last edit: Bas Kleinbloesem 2020-07-07
Note: this is a duplicate of #18.
There is, I think, a major issue both with the method that Bas suggests and the implementation in GO. Any (simulated) pipe sound consists of three parts: attack, actual tone (looped) and release. The filtering HAS to be applied to the full pipe sound, containing all these parts. If filtering is applied to the parts individually, there is a risk that the transitions between the parts will not sound natural. One can try to hide this by applying cross-fading between the parts, but that doesn't feel like a correct way to do it.
Any implementation outside of GO can however only apply filterering to the individual parts (maybe attack and note are combined, but normally not the release(s)).
Implementation inside GO is challenging (as far as I have seen it) because of the same issue.
Yet, it's on my wishlist too. Let's see.
The risk Sjoerd mentions exists in theory indeed. I have applied the method that I proposed and it turned out that in practice it does not have to be an issue. It is important to use a suitable (phase linear) filter and thus filter both the tone sample and all releases. Fortunately this can be done in batch. The Demo I am referring to: https://mps-orgelseite.de/home/filebase/ (Odf GO-Swellbox-simulation Demo for the Billerbeck Semi-Dry Demo Sampleset) is accompanied by a clear instruction that allows you to run and test it yourself. As you will see, apart from the cross fading thats already built into GO, no further cross fading will be required.
Last edit: Bas Kleinbloesem 2020-07-08
I have just uploaded an audio-demo to the Concerthall of Contrebombarde https://www.contrebombarde.com/concerthall/music/40404.
I have listened to the demo on Contrebombarde and the swells sound great.
I also downloaded the swellbox demo ODF and followed the excellent intructions to run it at home, and there were no problems with transitions between loops.
However, in my testing I did notice one issue:
Each sample has multiple loop points, and my understanding is that GO selects loops randomly to make the sounds more varied and realistic. This means that the "swell open" sample is not always in sync with its corresponding "swell closed" sample, due to GO playing different the loops in a different order. I can hear a distinct "phasing" effect with the swell half closed, which degrades the sound quality, for me at least.
Colin Pykett has a discussion of this effect, along with a demonstration of the distortion I'm talking about, here (you may need to scroll down to "Signal Mixing"): http://www.colinpykett.org.uk/EndOfPipeOrgan.htm#Mixing
Thank you for your feedback Matthew,
Would you like to check if the “randomize pipe tuning” function (in audio and midi settings) is enabled? If so, would you like to test if you can still hear a phasing effect with the “randomize pipe tuning” function turned off?
Good call Bas. I disabled the option to randomize pipe speaking and the phasing effects are gone. Therefore I think it is safe to attribute the distortion to that random detuning feature, rather than the looping as I thought previously. Thanks!
Hi Matthew,
Good to hear that this has been resolved. Thank you for your attention.
When the function “Randomize Pipe Speaking” is switched on, it appears that a different detuning is applied to the different samples for the same pipe.
I noticed that earlier when I made an GO-Odf for a surround sampleset and have since turned this feature off by default. Sorry I was not alert to warn about this.
I have now made a feature request to get the option to disable the “Randomize Pipe Speaking” via the Odf and block it for sample sets where desired.
I know that this thread is a bit old, but I haven't checked in with the Feature Requests tab in a while. I would love to see this feature come to be as well since I think it would add a great deal of realism to the sound produced by GrandOrgue.
My concern with the double enclosure route, which hasn't been mentioned yet (as far as I can see) is that this is likely only reasonable for smaller instruments or systems with lots of RAM. Please correct me if I've missed something, but since you have to pass all the pipe recordings through a filter to create the enclosed samples, I'm assuming you would have to load twice as many WAV files per stop to implement this feature in this way. For an organ with many enclosed stops, this effectively would double the RAM requirements for the instrument. Am I missing something?
With complete respect for the amount of work and difficulty I'm sure it would take to implement a real time audio filter that could do this directly into GrandOrgue (I know this would be a huge undertaking), for me this is the better option for implementation. If it were possible to build this sort of filter directly into GrandOrgue, the same sorts of filters might be able to be put to use as a resolution to feature request #83 as well.
Regardless, many thanks to all that contribute to this software in any way. It brings me joy daily and I'm very grateful to have it!