ok.

so, i can demonstrate that drawing it in *does* in fact create different values than dialing it in - which is actually reasonable and likely by design. drawing it in is picking a point on a continuous curve, whereas dialing it in is discrete. that indicates that i shouldn't expect to be able to dial in exact eq settings that will null with settings i created by drawing. that's a step forwards in understanding.

it explains why loading the presets creates a different render than dialing them in; the presets are a combination of dials and draws, with little thought put into recreating them exactly. it explains why some tracks null quickly on reconstruction, while others don't - some eqs are drawn and some are dialed. if the eq in the original song was typed in, typing it in the reconstruction should output an exact replica; if the eq in the original song was drawn, i'd have to draw at exactly the same point, which is very low probability. so, i'd be left with little option but to import the previous mixer settings to recreate the original mix.

however, it doesn't explain why the output is so consistently different on the save when i dial it in. this could be explained by truncation error if it's saving values on the curve that needed rounding. the image map is obviously quantized, so you can only get so far with that logic - and it's not very far. but, if i'm typing in numbers then it shouldn't be rounding. i can't use this method to determine this; i know that any sort of save differs from what is in ram. so, i'd have to use debugging tools to get the numbers out of ram to compare. but, in truth it is obvious that they are different.

i'm falling asleep. i'll play with the ram in the morning.

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.

not updating the time machine

track #2 (from the end of july, 2014) uses the cubase eq to greater effect, which has allowed for greater testing. the results are very curious, and cement a broken mixer as the cause. there's also a specific behaviour that is not asserting itself and that i believe may be at the root of the problem.

i have all of these eq settings saved in my rampresets.xml file. so, i'm testing at three levels. the first is manually entering the eq, as they exist in the preset file, without saving. the second is re-opening the file after the save. the third is loading the presets from the xml file.

this actually produces three different outputs that are clearly eq-based in the difference files. further, the results can be consistently recreated so they null with like outputs - the output will continue to null over and over after i load the presets, or before i save the file.

it is only the third option that will null with the original output.

but, here's the thing: i shouldn't have to load these presets. cubase should recognize that they are the presets in the file, and the presets should then auto-load. this is something it has always done. but, it hasn't been doing it in the time it's been weird.

i think that there's a good chance that if i can solve this problem then i'll have solved the whole problem. there's a number of things i can test for.

as it is, i currently see no reason to update this ep, which was also finalized at the end of this may. but, i'll have to do some more testing to be sure of it.

https://jasonparent.bandcamp.com/album/the-time-machine


for now, it seems to suggest that *both* of the options i'm dealing with - rendering from ram or rendering from disk - are wrong!