Extended ranks

I'm building an organ definition file to represent the organ at my church. I'll be recording the pipes in a little while (after Easter tuning) but for now I'm using the St Anne samples as placeholders.

Our organ is somewhat overly unified. There is a single 'Trompette' which goes from 16' through 4', 85 pipes in total. On the Great, the Principal 4' is just the one octave extension of the regular principal, etc.

I'd like to simplify my Rank table by having a single rank for each color, then have the stoprank table say where the stop begins and ends, rather than creating a separate rank for the 12 pipes of the extensions. Is there any reason to do it differently?

Second part of this question - Is there a way for the Rank object to specify more than one set of files, so I can build the long rank from 2 ranks in the placeholder set? Or, must I make an extra rank for the extension and use the stoprank to unify them - and if so, how?

[mdyde]

Hello lizny,

To model a real unified rank you would have just a single Custom Organ Design Module organ definition (CODM ODF) Rank object for it, with:

Rank.MIDINoteNumberOfFirstPipe
Rank.NumberOfPipes

... specifying the full (extended) range of notes that it encompasses (with a corresponding set of samples), then use StopRank objects to map portions of it to the stops.

As an example, have a look at the "Great: Trumpet 8 (Clarion 4)" rank in the "ExampleCustomOrgan3-StAnnes-Simplified" example CODM ODF:

Code: Select all

   <rank>
      <RankID>14</RankID>
      <Name>13 Great: Trumpet 8 (Clarion 4)</Name>
      <NumberOfPipes>73</NumberOfPipes>
      <MIDINoteNumberOfFirstPipe>36</MIDINoteNumberOfFirstPipe>
      ...
   </rank>
   ...
   <stoprank>
      <Name>016 Stop: Gt: Trumpet 8</Name>
      <StopCode>2109</StopCode>
      <RankID>14</RankID>
      <MIDINoteNumIncrementFromDivisionToRank>0</MIDINoteNumIncrementFromDivisionToRank>
      <MIDINoteNumOfFirstMappedDivisionKey>36</MIDINoteNumOfFirstMappedDivisionKey>
      <NumberOfMappedDivisionKeys>61</NumberOfMappedDivisionKeys>
      ...
   </stoprank>
   <stoprank>
      <Name>017 Stop: Gt: Clarion 4</Name>
      <StopCode>2110</StopCode>
      <RankID>14</RankID>
      <MIDINoteNumIncrementFromDivisionToRank>12</MIDINoteNumIncrementFromDivisionToRank>
      <MIDINoteNumOfFirstMappedDivisionKey>36</MIDINoteNumOfFirstMappedDivisionKey>
      <NumberOfMappedDivisionKeys>61</NumberOfMappedDivisionKeys>
      ...
   </stoprank>


As in the above excerpts, both the Gt Trumpet 8 and Gt Clarion 4 stops are unified from that single 73-pipe Rank.

Thank you - that was pretty much my plan for the "real" organ - record all the principals as one rank, for instance, and use the stoprank to select the correct starting point for the pitch needed.

Where I'm puzzled is an interim step - and maybe this isn't going to work and I should just not bother, but it would help me construct and validate the custom organ definition while i'm waiting to make and process the recordings.

St Anne has an 8 foot principal and a 4 foot principal. Is there a way for me to create a 73 pipe rank object using samples from the two different sample folders?

-Liz

[mdyde]

Thanks, Liz.

Where I'm puzzled is an interim step - and maybe this isn't going to work and I should just not bother, but it would help me construct and validate the custom organ definition while i'm waiting to make and process the recordings.

St Anne has an 8 foot principal and a 4 foot principal. Is there a way for me to create a 73 pipe rank object using samples from the two different sample folders?

In the CODM, any given Rank object requires all of its sample files to be within a single folder, and numbered consecutively (i.e. with a contiguous MIDI note number range).

Although you could technically achieve the same end result (from the user's perspective) fully within a CODM ODF (i.e. without moving/copying any sample files) by having two Rank objects, and *three* StopRank objects (two of which would be for the same stop, since you'd need to split its compass between the two Rank objects), that would make it more complicated than would be needed for your 'real' final organ samples, so it probably wouldn't be useful as an intermediate means of validating your design anyway.

You could potentially instead copy and renumber all of the relevant diapason/principal samples into a single folder within a custom installation package ID folder of your own (within the 'user' 800000-899999 range), then use them in the same way that you would for the Trumpet/Clarion (but referencing the different installation package ID and sample folder, of course).

Alternatively, for now you could just make your unified diapason/principal temporarily use the trumpet/clarion samples again. That would be the simplest option. E.g. for testing you could temporarily set Rank.HarmonicShaping_PipeMIDINoteNum036/096_3rdAndUpperHarmLvlAdjDb to a non-zero value for that Rank object, so that it sounded different to your other unified trumpet/clarion rank, so that you could tell them apart when testing.

That's what I needed to know, thank you. I was looking to avoid copying files and building the custom rank folders, but eventually I'll need to do that anyway with the real samples so it is probably the least amount of throwaway work.

[mdyde]

Thanks, Liz.

You're very welcome. Best wishes for your new sample set.

It is going well - I can even play my pseudo-organ. One last thing I'm stuck on. I have a 16' Bourdon rank in the great, which is really an 8' that actually exists but borrows the bottom octave from a pedal rank. I assume the stoprank object is where I explain this situation to Hauptwerk, but I'm not sure how - does one of the examples do something like this?

I could just record that octave twice for a simpler configuration - but the rank in the great is enclosed, and the borrowed bottom octave isn't, so configuring the borrowing will best match reality.

[mdyde]

Hello Liz,

I don't recall any of the example CODM ODFs borrowing just part of a rank, but you could easily do it by adding a second StopRank entry for that particular stop, which references the rank from which it needs to borrow the bottom octave (with NumberOfMappedDivisionKeys=12, and MIDINoteNumIncrementFromDivisionToRank and MIDINoteNumOfFirstMappedDivisionKey set appropriately).

Liz,

Welcome to the world of customizing Hauptwerk sample sets. Please feel free to visit my web site at

http://www.nightbloomingjazzmen.com/NBJ_Organ_Software.html

I have posted the CODM files for all the organs I have released to the public and they use many of the same techniques you are trying yourself - including extending one rank using samples from a second rank. Perhaps you can use these as additional learning guides.

Les

So, the stop object can reference 2 stopranks? do we have an example of that?

[mdyde]

So, the stop object can reference 2 stopranks?

Correct. The StopRank table provides a many-to-many relationship between stops and ranks. I.e. you can have any number of StopRank entries for the same stop.

do we have an example of that?

I don't recall any of the standard example CODM ODFs having more than one. Les mentioned that some of his ODFs do.

Liz,

Welcome to the world of customizing Hauptwerk sample sets. Please feel free to visit my web site at

http://www.nightbloomingjazzmen.com/NBJ_Organ_Software.html

I have posted the CODM files for all the organs I have released to the public and they use many of the same techniques you are trying yourself - including extending one rank using samples from a second rank. Perhaps you can use these as additional learning guides.

Les

thank you! Would you point me at an example? I'm looking at a couple but not certain what I'm looking for and there's lots

I suggest you start with the English organ. It is also mostly based on St Anne’s.

Les

I suggest you start with the English organ. It is also mostly based on St Anne’s.

Les

Ahh, I see - multiple stoprank objects with the same stopcode. I had thought there could be only one, and it would reference multiple ranks inside. Simple now thank you!

I am glad this helped. Martin's documentation is completely correct - but sometimes it helps to see and example...