Okay this is getting really out there. There is a third possibility in all this. Can our minds actually change reality? Talking about the observer effect of quantum physics.
" In physics , the observer effect is the theory that simply observing a situation or phenomenon necessarily changes that phenomenon. … An especially unusual version of the observer effect occurs in quantum mechanics , as best demonstrated by the double-slit experiment."
Exactly. I doubt anyone here disagrees with this.
Plus, we have discussed this many times - just like every other audio forum on the planet. 
In the end, reality is a collaboration between the observer and that which he or she observes.
We all have different systems and physiology, therefore what we experience is unique to each and every one of us.
Many thanks for the explanation and insights into (some of) the potential causes of SQ differences.
Last evening I compared 3.0.0 and 3.0.4. The differences I thought I heard, if any, were minuscule. I’m back to 3.0.4 mainly because it was what was loaded when I decided to quit comparing. Whatever differences I thought might exist are dwarfed in my environment by changes in position of the listening chair (into /out of various room nodes), small adjustments in speaker toe-in angles, and things of that nature.
The room is in a state of minor flux as I recently moved the speakers to the long wall of the room and have been tweaking and listening to the effects of changes as I contemplate the addition of more diffusion and absorption. The point being is that I have been in the cycle of making changes and listening for effects for the past month, so this was just another variable to toss into the mix.
On to the next peak 
I tried V1 again briefly, but in my system, V2 is the keeper.
A wonderfully fun thread.
We have accidentally done this experiment - there were a handful of releases for Torreys, one of them was accidentally the same as another and indeed various people expressed strong preferences for one or the other. I also think that sonically most people preferred the original (but broken version of Torreys): some chose to live with the bugs and others found that the bugs annoyed them more than the loss in sound quality.
Still I don’t see it as an issue. I, like you, at times don’t hear a difference when many others do. In those cases I typically use the cheaper version (if there’s not some other overriding concern.) On the other hand at times my tinnitus reacts differently to different choices and even if most others don’t hear a difference I’ll take the less annoying version
FWIW we don’t need to do the experiment with FPGAs that come from the exact same source code and act identically bit for bit. The differences are often extremely clear (much more clear than the differences in the current versions of Snowmass.) And it’s a good thing: changing the just version number of the FPGA code very clearly makes a sound quality difference.
From release to release I attempt to make a bigger difference than any we are talking about in this thread.
Pic code changed as well, not just the version number
If you are referring to anything in my post I’m slightly confused by this statement. In Snowmass I think we understand that it’s the PIC code changes (or for some the Bridge code changes) that are being talked about.
If you are referring to Torreys, there were indeed accidentally two identical releases, PIC code and all. When I built my post which attempted to clarify the version numbers vs the different Torreys releases I just skipped the duplicate. We also didn’t stir the waters with revealing that we’d made such a mistake (in fact Paul may not realize it happened at all.) There was already enough confusion about various Torreys releases and since it’s completely normal to hear differences every time you listen to the same thing twice in a row it was completely expected.
Ted, could you talk a little about the compile process? It’s very interesting to hear that each compile finds different/unique ways to generate the same answer. I guess my question is, why doesn’t the compile find the same way to configure the FPGA each time if the set of parameters you’re giving it doesn’t change? If it’s looking to find the “best” way each time a compile is done, and it’s done in a mathematical way, why doesn’t the the compile process find the same way every time? I can’t wrap my head around that. Or is this done on purpose so you have the opportunity to hear what each FPGA configuration sounds like?
The FPGA place and route code is indeed deterministic: given the same source and the same pseudo random number generator seed (and the same processor description, etc.) it will produce the same placement and routing.
But whenever you have a search space that is huge it’s extremely easy to find a locally best answer that is far from the truly best answer (we often call this hill climbing, if you are lucky you can see that there’s a taller hill just beyond the valley). In fact you often wouldn’t know even if you had found the truly best answer without looking at every possible answer (or at least exploring every separate mountain peak in the search space, but you hardly ever know all of the separate peaks either.)
As I mentioned above many times companies will invest in a FPGA routing farm and run many trial searches in parallel either to save calendar time finding a solution or simply to find any solution at all. The Xilinx tools can orchestrate driving many compiles each with their own seeds on a large set of machines.
We discovered with our second beta release that fixing a simple bug took the life out of the music. Everyone liked version 0.35 better than any of the various bug fixed versions we did for the first release. To keep from ending up in that situation again we decided to simply compile 20 versions of each release and sort them by ear. As it turned out Arnie Nudell was pretty efficient at doing that and had a good ear for hearing the versions that were most lifelike.
It’s not quite as random as it sounds, in general all compiles of the next release sound better than any compiles of the last release, but most of us have discovered that when we’ve heard a new differences we’ve never heard before we will hear it forever. So we are always listening for smaller and smaller differences but perceiving them each as significant as the last.
this seems to be very true and is the reason why I usually only bother about immediate differences which are easily reproducible…have too little patience for the rest.
For those who are curious about those versions of Torreys:
The term “observer” has misled many in the discussion of quantum indeterminacy. It’s more helpful to think of it as being indeterminate until the situation requires it to have a single value.
When we make “observations” with our tools it puts the system into a state which cannot continue to be indeterminate. Such forcing occurs all the time without a conscious observer being part of it.
Sorry Ted, I thought you were saying the only difference between Snowmass 1&2 was the version no
No problem, I suspected that was the case, but apparently I like telling stories so much I seem to take any opportunity 
Don’t stop, we like your stories!
So, if I’m understanding this correctly, you’re saying that the more logic blocks the FPGA has, the amount of possible unique compiles goes up exponentially? Does this imply that getting a good sounding compile gets exponentially more difficult as the block count gets higher, ie a more powerful FPGA? Essentially, more duds and less objectively good sounding ones. If this is true, then wouldn’t you want to choose an FPGA that isn’t over qualified to do the job at hand? Or are the compiles not drastically different when it comes to audible differences?
Not to contradict myself, but now that I think about it more, I think the opposite would be true. Having more blocks to program implies that there are now more possibilities for better sounding compiles. There are now more unique ways for any given compile to sound unique and therefore potentially better than others.