GrandOrgue GoODF Pitch Tuning Issues Explained

Hey everyone! Let's dive into a peculiar issue encountered while working with pitch tuning in GrandOrgue's GoODF, specifically concerning pipe samples and their tuning. It’s a bit of a technical journey, but stick with me, and we’ll unravel this musical mystery!

Understanding the Problem: Pitch Tuning Per Pipe

So, the core challenge here revolves around pitch tuning for individual pipes within a GrandOrgue organ setup. Imagine you’re working with a virtual organ, like the Dortmund organ, where certain pipes reuse the same audio samples. This is a common optimization technique in virtual organ design. However, this approach can lead to some interesting challenges when it comes to fine-tuning the pitch of individual notes.

In the specific case mentioned, the Dortmund organ's 'Nah' rank for the great trumpet uses pipe samples for the G above middle C for the F# above middle C as well as for the G above. Essentially, the F# pipe is borrowing its sound from the G pipe’s sample. Now, if we need to adjust the pitch of that F# pipe – say, by -100 cents – to get it sounding just right, we run into a snag. The natural inclination is to use the PipeXXXPitchTuning parameter in the Organ Definition File (ODF) to make this adjustment. This parameter should allow us to specify a pitch tuning value for a particular pipe number. However, the issue arises when we try to implement this in GoODF, the GrandOrgue Organ Definition File editor.

The problem is that GoODF seems to be associating the pitch tuning with the sample itself, rather than the specific pipe number. This means that if we set PipeXXXPitchTuning = -100 for the F# pipe, which shares a sample with the G pipe, that tuning adjustment inadvertently gets applied to the G pipe as well! This is definitely not what we want, as it throws the G pipe's pitch out of whack. It's like trying to adjust the tuning of one string on a guitar and accidentally affecting another string that happens to be vibrating sympathetically. The desired outcome is precise control over each pipe's pitch, independently of the samples they might share. This level of granularity is crucial for accurately recreating the nuances and intricacies of a real pipe organ.

This behavior can be quite frustrating because it prevents us from making the necessary fine-grained adjustments to the organ's sound. Imagine the scenario: you've meticulously sampled each pipe of a real organ, capturing its unique tonal characteristics. You then load these samples into GrandOrgue and start building your virtual instrument. But when you encounter these pitch tuning discrepancies, it feels like you're losing control over the final sound. The goal is to replicate the original instrument as faithfully as possible, and these technical hurdles can stand in the way of achieving that sonic perfection. So, the core issue is the need for a way to independently adjust the pitch of individual pipes, even when they share the same samples, without affecting other pipes that use the same sample.

The Manual Workaround and GoODF's Interpretation

Okay, so we've identified the problem. What can we do about it? Well, there's a workaround, but it's not exactly ideal. The user discovered that they could manually edit the .organ file – the text file that contains all the organ's definitions – and directly insert the correct PitchTuning value for the F# pipe. This works! The organ sounds proper when played in GrandOrgue. It's like performing surgery on the organ's DNA, directly manipulating the code to achieve the desired result.

However, here's where things get even more interesting. When this manually edited ODF is loaded back into GoODF, the editor doesn't seem to recognize the PitchTuning = -100 setting for the F# pipe. Instead, it displays the pitch tuning for that pipe as zero. It's as if GoODF is blind to the manual change we made, or perhaps it's interpreting the data in a different way. This discrepancy suggests that there's a disconnect between how GoODF handles and displays pitch tuning information and how GrandOrgue actually interprets it from the .organ file. It's like having two different dictionaries, one that defines words in a certain way and another that has a slightly different interpretation. This inconsistency can lead to confusion and makes it difficult to rely on GoODF as a true representation of the organ's actual settings.

This observation further reinforces the idea that GoODF is associating the PitchTuning with the sample rather than the pipe number. When GoODF loads the ODF, it sees that the sample used by both the F# and G pipes doesn't have a specific pitch tuning assigned to it (at least, not in the way it expects). Therefore, it defaults to displaying a pitch tuning of zero. This behavior highlights a potential limitation in GoODF's current implementation, where it might not be fully equipped to handle scenarios where fine-grained pitch adjustments are required for individual pipes that share samples. The manual workaround, while effective, is not a sustainable solution in the long run. It's time-consuming, error-prone, and defeats the purpose of having a visual editor like GoODF in the first place. The goal is to have a seamless workflow where adjustments made in GoODF are accurately reflected in the final organ sound, and vice versa. This inconsistency breaks that workflow and adds an extra layer of complexity to the organ building process. Guys, we need a solution that allows for accurate and intuitive pitch tuning control within GoODF itself.

The Core Issue: Sample vs. Pipe Association

Let's really nail down the core issue: It's the association of pitch tuning with the sample rather than the pipe number. This is the root cause of the problem we're seeing. In a perfect world, we should be able to say,