On Tue, Jan 2, 2018 at 1:25 AM, Jim Henry <jim.he...@sbcglobal.net> wrote:
> Hi Aaron, > > > > If you haven’t already, you should look at the Miditzer and the jOrgan > projects. Both are organ simulators the use FluidSynth to produce sound. > The Miditzer is strictly a Wurlitzer theatre organ simulator while jOrgan > is a general purpose simulator for both classical and theatre organs. > Thanks for the pointer! I'm using jorgan with fluidsynth. > > > As the original programmer of the Miditzer I can tell you that the way I > handled the channels was to assign each rank to a channel. I did this not > because of the distortion problem but because the sound fonts are assigned > on a channel basis. This works out well for a theatre organ because they > have relatively few ranks. I think you may be using preset combinations. > Both the Miditzer and jOrgan emulate organ relays so that all the stop > control of a real organ is available. > > > > To deal with the distortion caused by drawing many ranks you need to > consider two things. One is to limit the amplitude of the sound samples so > that playing multiple notes with multiple stops does not lead to values > that exceed the maximum value for a channel. The other is to limit the > number of channels that are being mixed into a single speaker as > overdriving the speaker will also create distortion. If you can arrange to > mix only a few MIDI channels into one of a large number of speakers, then > your final mixing is air mixing, which doesn’t distort. Everything before > you get into the air is subject to electrical distortion that can be > challenging to manage. > I'm not talking about clipping. I can turn down the volume and mostly manage that. I'm talking about sound quality and electronic distortion: Harmonic distortion. Frequency response distortion. Phase distortion. The sound is sometimes shrill or tinny. Statically putting one rank per channel also isn't nearly as good as what I'm suggesting because the likelihood of choosing several stops that are assigned to the same channel is rather high. Something dynamic would be much better. > > Best, > > Jim Henry > > > ------------------------------ > > *From:* fluid-dev [mailto:fluid-dev-bounces+jim.henry= > sbcglobal....@nongnu.org] *On Behalf Of *Aaron Laws > *Sent:* Monday, January 1, 2018 11:30 AM > *To:* fluid-dev@nongnu.org > *Subject:* [fluid-dev] Channel handling > > > > I'm an organist and have a midi organ that uses fluidsynth to produce its > sound. Audio fidelity is an important aspect to this project since several > presets (hence very many instruments) can be sounding simultaneously. > Distortion becomes noticeable very quickly. > > > > I've been thinking of ways to deal with this, and one that comes to mind > would be to split up the audio into several channels. By the way, I'm > assuming all-mono sample sets for now. There are a number of ways to do > this: I could opt for each preset to its own channel, or perhaps each > octave on its own channel, etc., but I think what would be best is having > each note class on its own channel. > > > > If a user has 12 channels, this is simple, but I for one don't plan on > having 12 channels of audio. If, for instance, I only have four channels, > if I'm only playing four note-classes at a time, each channel should be > occupied. If I add a fifth noteclass, one channel must do double-duty. > Channels should be assigned pitch classes on the fly as the channels become > available. Perhaps, imagine that C and E are on the same channel, then the > other channels are sounding D, G, Bb, then the latter three are removed. It > would be nice for fluidsynth to notice that only two sounds are sounding, > and they're both on the same channel, so let's dynamically move one over to > an unused channel. > > > > Anyway, I hope you can see where I'm going with this, and perhaps > something like this functionality already exists? > > > > I am a software developer and have contributed to free software before, > and am interested in doing so again, but I wanted to check with this > community first for several reasons: > > > > 1.) Is this already implemented somewhere somehow? > > 2.) What kind of interest is there in this functionality? If none, is it > conceivable that a patch with this functionality would be accepted? > > 3.) How should I get started? If this would never be accepted, I would > still appreciate some guidance about where to begin looking at the code > base so that I can patch my own fluidsynth. > > > > Thank you for your time; Sincerely, > > > In Christ, > Aaron Laws > > _______________________________________________ > fluid-dev mailing list > fluid-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/fluid-dev > >
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
