On Tue, Jan 2, 2018 at 7:59 AM, Marcus Weseloh <mweselo...@gmail.com> wrote:
> Hi Aaron, > > 2018-01-01 20:30 GMT+01:00 Aaron Laws <dartm...@gmail.com>: > >> 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. >> > > But wouldn't you need to mix those channels together again at some point > anyway, moving the problem only a little bit further downstream? Or would > you then use a multi-channel output and have each channel output to a > dedicated speaker? > Thanks for asking. My goal is to do as little mixing as possible :-) If * I have four physical channels available (four sets of loud speakers: one subwoofer, one midrange, one tweeter, and a super tweeter per channel, say) * Fluidsynth is dynamically dividing output by noteclass to different channels * I'm only playing two notes The only mixing that should happen is in-air. On the other hand, if * I have four physical channels * Fluidsynth is dynamically dividing output by preset to different channels * I'm only playing two presets (organ stops in my case) Any notes played on the individual presets must be mixed in software, but the two presets should only be mixing in air. Let me know if any more clarification would be helpful. I'm assuming that avoiding dissonance between note classes is better than avoiding dissonance between timbres, but I'm open to suggestions.
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
