bit of a breakthrough with this...

it crossed my mind that one way to see what it's doing with the eq values is to recreate a preset i have saved in my rampresets.xml file and save over it, then check the values. sure enough, it's saving differently. this is affirmative proof that the mixer is malfunctioning over some kind of error.

i don't want to actually debug the thing, and i guess now i don't have to - it's enough to see that the gui is highly inexact in terms of what's actually being stored, and conclude that the values that are being saved differ mildly from the values in ram.

what i need to see now is how much of this is the result of some kind of error in arithmetic and how much is the consequence of a meandering mouse. for example: let's say i set the eq in the initial file by drawing it in to the space. if i try and recreate it by typing it in, i may get an inexact value. the eqs only accept one decimal point for volume and Q and whole numbers for frequency. this might just be the way it's designed...

however, if i can demonstrate two situations where i dial in whole numbers and the result is different, i'm left to conclude that the math is failing somewhere. and, i think that's the inescapable conclusion based on what i've seen - i just have to find a way to prove it to myself.

if i can demonstrate this, that reduces the problem to three likely sources: ram, processor or programming error. i can really only test the ram.

if i cannot demonstrate this, i suppose i'll have to accept it.

but, i'll point out again that it absolutely did used to snap into place fairly quickly, and the totality of the evidence suggests a point of error at some point. if i can rule out the ram, i'll have to install cubase on this laptop for testing. i'll have little option but to conclude a malfunctioning processor.