Exactly what the various audio output group algorithms do

The manual gives a very brief (a couple sentences) description of the algorithm by which one of the group-to-logical output cycling works. After searching this forum, I found the following very useful description of one of the algorithms:

------------------
For the 'Cyclic within octave, octaves and ranks cycled' algorithm the speaker number within the group to which a pipe will be routed is calculated as follows:

note_in_oct = (MIDI note number) mod 12
oct_num = (MIDI note number) / 12
num_speakers = number of speakers in the group
rank_seq_num = a number generated for the rank by sorting the ranks by RankID and then assigning an incremented number to each in turn (0 for the first rank, 1 for the second rank, etc.).

speaker_num = ( note_in_oct + oct_num + rank_seq_num) mod num_speakers
---------------------

But I could not find a similarly exact description of the other cycling methods. Is that documented anywhere? If not, would you consider posting the other methods? Thanks!

Tim

[mdyde]

Hello Tim,

I've made a document for you to show exactly what the two 'tone matching' algorithms do:

http://downloadhauptwerk.com/misc/Hauptwerk4ToneMatchingAlgorithms.pdf

Those two were originally primarily designed to minimise the occurrences of dissonances on any given channel in equal temperament when used with 3-5 outputs in a group.

For the cyclic algorithms the audio output number within the group to which a pipe will be routed is calculated as follows:

midi_note_num = <MIDI note number>
note_in_oct = (midi_note_num) mod 12
oct_num = (midi_note_num) / 12
num_outputs = <number of audio outputs in the group>
rank_seq_num = (a number generated for the rank by sorting the ranks by RankID and then assigning an incremented number to each in turn (0 for the first rank, 1 for the second rank, etc.)>

---
'Cyclic within octave, octaves and ranks cycled' algorithm:

output_num = ( (note_in_oct) + (oct_num) + (rank_seq_num) ) mod (num_outputs)

---

'Cyclic within octave, octaves constant (C/C# split)' algorithm:

output_num = (note_in_oct) mod (num_outputs)

---

'Cyclic across whole rank compass' algorithm:

output_num = (midi_note_num) mod (num_outputs)

---

[mdyde]

[P.S. I've moved the topic here, edited its title slightly, and made it 'sticky' so that people can find it in the future as easily as possible, since I imagine other people might find this information useful too.]

Thank you! That is very useful.

Tim

To complete the speech, it may be useful to remember that if Hauptwerk does not have an allocation algorithm that suits you then within certain limits you can create one yourself (and outside Hauptwerk).

If it may be useful to extend the concept of "Tone Matching Mode 1 & 2" using less than 12 speakers you may consider a hypothetical "Tone Matching Mode 3".

All of Hauptwerk allocation algorithms assume that each note is statically allocated in A channel. This is a correct assumption but in some cases the intermodulation distortions that occur when using intervals other than octave/unison are quite annoying, especially if you use saturation plugins (which exalt the distortions).

If you are using 6 speakers (or less than 12) you can dynamically manage 12 chromatic notes allocations to avoid overlapping intervals different from unison/octave on the same speaker. This means that a same note may appear, at different times and at different contexts, in a different speaker in order to avoid intermodulation distortions. This works well until there are up to 6 different chromatic notes at once. Obviously the ways of implementation can vary, but the underlying concept is always the same.

Tone Matching Mode 3 does not exist in Hauptwerk. To simulate it, you have to use 12 virtual chromatic channels with Hauptwerk and manage these 12 channels within a VST/AU plugin in a DAW. In practice, you can create a mixing rule from 12 notes (=chromatic scale) to less than 12 available speakers.

It's not a simple thing but Ardour DAW can help you do this with a Lua DSP script.
http://manual.ardour.org/lua-scripting/

I wrote a script that does this and works well at zero latency.
Later I will publish an easily manageable version with a friendly user configuration interface.

[mdyde]

Hello Elia,

Although routing pipes dynamically to different speakers depending on the pipes that are are already sounding could potentially give some benefit in terms of reducing the load on the speakers (helping to minimise speaker distortions), Hauptwerk intentionally doesn't include that functionality natively since it wouldn't be realistic, in that any given virtual pipe would then be heard to move seemingly arbitrarily around the listening room each time it was played, whereas each real organ pipe always sounds from a fixed point in space. I think you would find the effect noticeably unnatural.

Likewise with using saturation effects on Hauptwerk's output -- saturation/distortion effects and pipe organs don't traditionally go together.

However, you could of course potentially implement those things yourself outside of Hauptwerk if you really wanted to, as you describe.

Hello Martin,
I totally agree with the general observations for wet and stereo/surround sampling and when the listener is near the source.

In the particular case of a church, the situation is very different.

Unfortunately dry sampling is not always as clean as you would expect in the studio and you often have to do creative work to revitalize the sound. Even a good equalizer can help a lot.

There are various sources of distortion: the speaker, the amplifier and even the digital mixing. The latter (intermodulation distortion) is created at the beginning of the audio chain and can not be deleted. Obviously this is a very variable distortion as intensity and depends on the context.

With monophonic dry sounds, octave/unison interval greatly alleviates this effect at the expense of playing the same note on the same speaker.

If you place speakers very close to each other then 15 meters away from the source it is very difficult to notice that the notes move. A note moves only when it is completely extinct and its place has been occupied by another note.

In short, this is always a compromise. You must always judge with your ear to see if it can be useful. In the particular case, sound can be more easily structured, elaborated and controlled, even though CPU load may become very heavy even for a Mac Pro. (In addition, the 32-channel VSTi limit requires the use of Jack Audio or other routing systems to scale over a larger number of channels for more structured and complex work.)

Best regards,
Elia