i'm procrastinating because i don't want to be further disappointed. but i need to get back to it.
there's an alter-reality update tonight at midnight: it is the date that i've penciled in for the release of my first electronic ep. that is dec 1, 1997. which means i'm pushing into 1998, and the real start of my electronic phase. this ep has about another month as the feature before i plow into the synth-pop.
that means i need to get these instrumental mixes done within the next month. everything has slowed down so dramatically this year; i'm kind of irked, but them are the apples. i just hope the gear co-operates soon and stays co-operative....
https://jasonparent.bandcamp.com/album/inrisampled
Thursday, July 30, 2015
belated, intentionally
hi.
a birthday call shouldn't be a negative experience, so i decided against it this year. i mean, the idea is not to torment you, it's to wish you well. freaking you out would be rather counter-intuitive.
but, i did want to let you know that i didn't forget. i just decided against it.
so, happy birthday.
j
a birthday call shouldn't be a negative experience, so i decided against it this year. i mean, the idea is not to torment you, it's to wish you well. freaking you out would be rather counter-intuitive.
but, i did want to let you know that i didn't forget. i just decided against it.
so, happy birthday.
j
see, this is how you'd assume it should work. it should merge at the master and go through the rest of the chain as one signal.
but, i seem to have disproven this. and, i have further evidence for disproving this - it's helping me explain something i never really understood.
if you place a vanilla bus right in front of the main mix, you'd think it should just be superfluous, because the main mix is combining everything, anyways. it's a virtual path, so you're not creating resistance or any kind of degradation.
but, every time i've done this i've noticed it isn't accurate. sometimes it's subtle. but parking that vanilla bus in there predictably changes the characteristic of the sound. i've never understood this...
...but perhaps the reason this is true is that it actually creates the merge operation that it seems obvious should be there but doesn't seem to actually be.
what that means is that if somebody wants the behaviour in this diagram, they should put a bus in front of the master out and send everything through it. that will merge the signals.
otherwise, this diagram should really be in parallel - at least up to the channel fader (which is right after the eq).
but, i seem to have disproven this. and, i have further evidence for disproving this - it's helping me explain something i never really understood.
if you place a vanilla bus right in front of the main mix, you'd think it should just be superfluous, because the main mix is combining everything, anyways. it's a virtual path, so you're not creating resistance or any kind of degradation.
but, every time i've done this i've noticed it isn't accurate. sometimes it's subtle. but parking that vanilla bus in there predictably changes the characteristic of the sound. i've never understood this...
...but perhaps the reason this is true is that it actually creates the merge operation that it seems obvious should be there but doesn't seem to actually be.
what that means is that if somebody wants the behaviour in this diagram, they should put a bus in front of the master out and send everything through it. that will merge the signals.
otherwise, this diagram should really be in parallel - at least up to the channel fader (which is right after the eq).
i've convinced myself that what was broken in the drivers was the separation of the tracks. the more i explore this, the more likely it is that it's going to start looking random.
i can't verify that cubase processes individual tracks before it mixes them, but it seems like an unavoidable conclusion.
it would then have to be that it broke at the mixing stage - that the tracks were corrupted as they were being combined, on a stream-by-stream basis.
this should be at the driver level, because it's what drivers do: they act between hardware and software instructions.
i'm still a little unclear on exactly how this works, but the inference is that the hardware must be streaming the individual parts separately; that the "mixing" isn't actually done in hardware, but in the listener's ears. like an rgb gun, or a computer monitor for that matter - it shoots out the different colours independently and allows the result to exist in observation. there's no violet inside your computer. there's only instructions on how to create violet on your screen.
if i can verify that this is true, i'll be convinced.
but, i don't think it's going to help a lot in reconstructing it. it means i'd have to run independent processes on each of the tracks, because the corruption is happening on the other side of the master effects.
so, today wasn't a loss. i feel i finally *understand* what's happening. that should help me put it behind me and move on.
talk about a weird error, though. no wonder i couldn't figure it out.
to keep to the colour analogy, i guess it would be sort of like that i had a dirty printer head, and i was getting splotches on the paper as a consequence of it - those splotches being strange frequency boosts.
i can't verify that cubase processes individual tracks before it mixes them, but it seems like an unavoidable conclusion.
it would then have to be that it broke at the mixing stage - that the tracks were corrupted as they were being combined, on a stream-by-stream basis.
this should be at the driver level, because it's what drivers do: they act between hardware and software instructions.
i'm still a little unclear on exactly how this works, but the inference is that the hardware must be streaming the individual parts separately; that the "mixing" isn't actually done in hardware, but in the listener's ears. like an rgb gun, or a computer monitor for that matter - it shoots out the different colours independently and allows the result to exist in observation. there's no violet inside your computer. there's only instructions on how to create violet on your screen.
if i can verify that this is true, i'll be convinced.
but, i don't think it's going to help a lot in reconstructing it. it means i'd have to run independent processes on each of the tracks, because the corruption is happening on the other side of the master effects.
so, today wasn't a loss. i feel i finally *understand* what's happening. that should help me put it behind me and move on.
talk about a weird error, though. no wonder i couldn't figure it out.
to keep to the colour analogy, i guess it would be sort of like that i had a dirty printer head, and i was getting splotches on the paper as a consequence of it - those splotches being strange frequency boosts.
Wednesday, July 29, 2015
i can't make sense of this. i'm starting to understand the tonal differences a little better, but it really makes no less sense to me as to how i ended up where i am.
the guitars null flat. there's some bleed, but it's from the bass part, as it was transferred from tape. tapes bleed. it's not an incomplete null, it's bleed. that's settled.
i can get the drums to very nearly null. i need to cut the eq on them by about 2 db at 50 hz, then boost the master eq by about 2 db at 80 hz. there's an izotope plugin on the master, and it comes in before the eq in the signal path, so that 80 hz boost has to be where it is and that 50 hz cut has to be where it is. i can't say to myself "maybe i split the difference and forgot". they're not interchangeable. in order for it to null, i have to cut the bass into izotope, and increase it out of izotope.
but, of course, anything i do to the master will affect the guitars. then, they no longer null. nor can i say "maybe i cut the guitars before they got to izotope". it doesn't work like that when you've got a plugin in the way.
this suggests two distinct signal paths in the earlier mix. but, i don't mix like that. i've never mixed like that. i'd never do that.
see, the funny thing about this is that it's an entirely rational mixing decision. you might decide the bass is coming in to the mix a little too heavy, take it down and then increase it on the way out. i don't remember doing that here. but i've done this countless times. it's a pretty normal mixing strategy. it doesn't seem like a random error. it seems like there's a fucker at a mixing desk.
i'm still convinced this is crazy. it's the kind of thing i'll never actually believe. i'll disconnect the internet. i'll rant about it all day. but, it's insane.
i'm the kind of person that would think i hallucinated it if god herself came down and slapped me upside the head. i could have a bruise. i'd think i fell somewhere. there's certain things that no amount of evidence can be convincing of. it's a sort of problem with being a cold rationalist. even if it's true, i can't accept it.
yet, i've determined that the old mix somehow sent the guitars and drums through different izotope instantiations, because there was a slight bass boost on one of them and no bass boost on the other - and the probability that this could have cancelled out any other way is so negligible it can't be seriously entertained.
my brain is unable to interpret that as a broken clock, because i can null with what i could call "elementary mixing operations". once a mathematician, always a mathematician. a 2 db boost at 80 hz is a common operation. a 2 db cut at 50 hz is a common operation. a broken clock would create the messy and random complications i was hearing, not uniform cuts at widely used frequencies - that in some sense cancel each other out.
i think, at this point, there's nothing of further value to be gained by trying to null these files. i'm going to shift the focus to determining if the device is currently consistent and flat. if i can prove this, i'll then go back to mixing it from scratch.
let be me clear on the following point: i cannot use mixes that i cannot recreate. whatever the cause, these mixes are useless to me.
the guitars null flat. there's some bleed, but it's from the bass part, as it was transferred from tape. tapes bleed. it's not an incomplete null, it's bleed. that's settled.
i can get the drums to very nearly null. i need to cut the eq on them by about 2 db at 50 hz, then boost the master eq by about 2 db at 80 hz. there's an izotope plugin on the master, and it comes in before the eq in the signal path, so that 80 hz boost has to be where it is and that 50 hz cut has to be where it is. i can't say to myself "maybe i split the difference and forgot". they're not interchangeable. in order for it to null, i have to cut the bass into izotope, and increase it out of izotope.
but, of course, anything i do to the master will affect the guitars. then, they no longer null. nor can i say "maybe i cut the guitars before they got to izotope". it doesn't work like that when you've got a plugin in the way.
this suggests two distinct signal paths in the earlier mix. but, i don't mix like that. i've never mixed like that. i'd never do that.
see, the funny thing about this is that it's an entirely rational mixing decision. you might decide the bass is coming in to the mix a little too heavy, take it down and then increase it on the way out. i don't remember doing that here. but i've done this countless times. it's a pretty normal mixing strategy. it doesn't seem like a random error. it seems like there's a fucker at a mixing desk.
i'm still convinced this is crazy. it's the kind of thing i'll never actually believe. i'll disconnect the internet. i'll rant about it all day. but, it's insane.
i'm the kind of person that would think i hallucinated it if god herself came down and slapped me upside the head. i could have a bruise. i'd think i fell somewhere. there's certain things that no amount of evidence can be convincing of. it's a sort of problem with being a cold rationalist. even if it's true, i can't accept it.
yet, i've determined that the old mix somehow sent the guitars and drums through different izotope instantiations, because there was a slight bass boost on one of them and no bass boost on the other - and the probability that this could have cancelled out any other way is so negligible it can't be seriously entertained.
my brain is unable to interpret that as a broken clock, because i can null with what i could call "elementary mixing operations". once a mathematician, always a mathematician. a 2 db boost at 80 hz is a common operation. a 2 db cut at 50 hz is a common operation. a broken clock would create the messy and random complications i was hearing, not uniform cuts at widely used frequencies - that in some sense cancel each other out.
i think, at this point, there's nothing of further value to be gained by trying to null these files. i'm going to shift the focus to determining if the device is currently consistent and flat. if i can prove this, i'll then go back to mixing it from scratch.
let be me clear on the following point: i cannot use mixes that i cannot recreate. whatever the cause, these mixes are useless to me.
see, what's weird is that, on closer analysis, the guitars are actually nulling. which indicates that the file that's outputted is not actually a clean render. i don't know how to make sense of that. did i render a mix without saving it? i have no recollection of this, and it's very uncharacteristic of me. but it's just about the only thing that makes any sense.
well...i suppose that the corruption in the device may have been bus related. but i think that's kind of stretching it.
dropping this external mixing hypothesis is proving difficult. if i can create a mix that nulls without modifying the master volume or eq, i'm left with a head-scratching paradox. but, that seems to be exactly what i'm in the process of doing.
even this doesn't make sense. the file save date on the project is june 29. the render is dated at basically the same time. there's no space for shenanigans. and these aren't things you can easily fake.
but, if this corruption on the bus is a real thing, what i may be doing is manually reconstructing it. i could have output the file through these corrupt buses, which could be the cause of the warped output.
i suppose that would reduce the initial issue to a cubase problem. it seems remote, but i can't argue with the obvious.
more testing is required.
i can't prove there was actually a driver problem until i wiped the registry. there was some other unknown problem before that.
well...i suppose that the corruption in the device may have been bus related. but i think that's kind of stretching it.
dropping this external mixing hypothesis is proving difficult. if i can create a mix that nulls without modifying the master volume or eq, i'm left with a head-scratching paradox. but, that seems to be exactly what i'm in the process of doing.
even this doesn't make sense. the file save date on the project is june 29. the render is dated at basically the same time. there's no space for shenanigans. and these aren't things you can easily fake.
but, if this corruption on the bus is a real thing, what i may be doing is manually reconstructing it. i could have output the file through these corrupt buses, which could be the cause of the warped output.
i suppose that would reduce the initial issue to a cubase problem. it seems remote, but i can't argue with the obvious.
more testing is required.
i can't prove there was actually a driver problem until i wiped the registry. there was some other unknown problem before that.
rap news 34
mostly spot on. the way this works is like this:
0) people like donald trump write trade treaties like nafta.
1) nafta allows a us factory to move from arizona to mexico, where it can pay workers a third of the price.
2) the workers at that factory lose their job.
3) the factory blows up the local economy in that region of mexico, forcing the locals into poverty.
4) that sets off a chain reaction of migration that pushes people out of mexico and into the united states, partially because
5) sub minimum wage pay in arizona is still more lucrative than work in mexico.
6) this benefits producers that create products for export but it reduces the pool of possible labour opportunities in arizona, creating structural unemployment levels.
7) what low education white arizonans are able to physically see and intuitively understand is that illegal mexican immigrants have jobs and they don't.
8) donald trump (carefully avoiding neatly shaved mustaches) stands up and blames it all on zee mexicans, in an attempt to generate a political base and distract from his own guilt and responsibility. mass unemployment creates social unrest that needs to be controlled.
9) the media agrees, in an attempt to construct a subscription viewer/reader base and further control the social unrest.
10) low education white arizonans vote for donald trump, but they do not expect him to reverse the policies that set off the chain of reactions.
it's a bit of a stretch to suggest it was planned from the start. but power has a tendency to perpetuate itself by profiting from it's own crises.
0) people like donald trump write trade treaties like nafta.
1) nafta allows a us factory to move from arizona to mexico, where it can pay workers a third of the price.
2) the workers at that factory lose their job.
3) the factory blows up the local economy in that region of mexico, forcing the locals into poverty.
4) that sets off a chain reaction of migration that pushes people out of mexico and into the united states, partially because
5) sub minimum wage pay in arizona is still more lucrative than work in mexico.
6) this benefits producers that create products for export but it reduces the pool of possible labour opportunities in arizona, creating structural unemployment levels.
7) what low education white arizonans are able to physically see and intuitively understand is that illegal mexican immigrants have jobs and they don't.
8) donald trump (carefully avoiding neatly shaved mustaches) stands up and blames it all on zee mexicans, in an attempt to generate a political base and distract from his own guilt and responsibility. mass unemployment creates social unrest that needs to be controlled.
9) the media agrees, in an attempt to construct a subscription viewer/reader base and further control the social unrest.
10) low education white arizonans vote for donald trump, but they do not expect him to reverse the policies that set off the chain of reactions.
it's a bit of a stretch to suggest it was planned from the start. but power has a tendency to perpetuate itself by profiting from it's own crises.
Tuesday, July 28, 2015
see, now that i'm doing an a/b on this specific track, i'm noticing that the initial mix through the new driver install has more clarity in the higher end and less bass. the new mix through the new driver install has too much bass and not enough clarity on the high end. that would suggest that the new driver install has more bass and less highs - that i exaggerated the bass on the old driver install (leading to too much on the new one) and undermixed the highs.
but, how can i be sure that this driver install is clean? the difference over the highs is much less audible on the laptop. the new mix has more of an oomph on the bottom, but has lost it's tightness. it's not less clear in the highs. that might suggest that the new driver install is a little flatter on the bottom, but is cut through the high end.
i need to be clear that the source is identical. it's a hardware difference. and presumably specifically a driver difference.
i don't like the fact that i can't determine what is the cleaner, least obstructed signal. and, i don't like the idea of using mixes that i can't reconstruct.
so, i think i need to spend some time tomorrow doing two things:
1) i'll need to check if the difference in the highs resolves itself tomorrow when the equipment cools down.
2) i'm going to need to try and break a few things to see if i can recreate a signal that nulls with the initial one.
3) i think i need to do a temporary vanilla xp install to try to and be sure that i'm getting a flat signal.
i don't think the highs were flat this morning. i think that happened when i connected to the internet. i'm leaning heavily towards disabling the network card in that machine altogether. it's integrated, so i'd have to take out in the bios.
the bottom line is that it still seems as though i'm not hearing what i'm actually creating. and i can't get anywhere until i'm sure that the sound quality is not being interfered with somehow.
i want to move forwards. but it's like trying to paint in the dark. you can imagine the result, and hope you're getting it right, but you can't actually see what you're doing. it needs resolution.
but, how can i be sure that this driver install is clean? the difference over the highs is much less audible on the laptop. the new mix has more of an oomph on the bottom, but has lost it's tightness. it's not less clear in the highs. that might suggest that the new driver install is a little flatter on the bottom, but is cut through the high end.
i need to be clear that the source is identical. it's a hardware difference. and presumably specifically a driver difference.
i don't like the fact that i can't determine what is the cleaner, least obstructed signal. and, i don't like the idea of using mixes that i can't reconstruct.
so, i think i need to spend some time tomorrow doing two things:
1) i'll need to check if the difference in the highs resolves itself tomorrow when the equipment cools down.
2) i'm going to need to try and break a few things to see if i can recreate a signal that nulls with the initial one.
3) i think i need to do a temporary vanilla xp install to try to and be sure that i'm getting a flat signal.
i don't think the highs were flat this morning. i think that happened when i connected to the internet. i'm leaning heavily towards disabling the network card in that machine altogether. it's integrated, so i'd have to take out in the bios.
the bottom line is that it still seems as though i'm not hearing what i'm actually creating. and i can't get anywhere until i'm sure that the sound quality is not being interfered with somehow.
i want to move forwards. but it's like trying to paint in the dark. you can imagine the result, and hope you're getting it right, but you can't actually see what you're doing. it needs resolution.
i should point out that i've been able to determine that i'm *not* hearing things.
i had all of the initial renders. i created a few new renders. now, if the gear was working correctly and i was hearing things, those files should be identical. you can test to see if that's the case via phase inversion. if they're the same, you should get a flat signal when you paste the inversion on top of the original. we then say that the two signals null.
the renders i created today did not null with the renders i created a few weeks ago. the cubase projects have not been modified in that period, i can be sure of that by checking the dates on the project files.
that should not make sense. they should null.
so, what that indicates is that the signal that was coming out of the mixer a few weeks ago was different than the signal that is coming out of the mixer today. that can only be true if something was broken at that time. so, that's a mathematical proof that the files are in fact different and i'm not tricking myself.
it's sort of strange, though. because in some cases the drums actually do null. the bass does not come close to nulling. it's normal for otherwise identical files to not null over reverb, and so i might expect some bleeding over the amp simulation. but, it's far too profound for that. the guitars also tend to roughly null, except at the high frequencies. put together, this is consistent with what i was experiencing - a floor in the sub-bass along with a cut in the high end.
i've been fairly certain that what i'm getting out today ought to be the clean, correct version. but, i'm not entirely sure if i mixed some of these things before or after it broke. the first track actually nulled perfectly. the next couple of tracks were mixed on the same day, but i re-rendered some of them. the result is that i'm lacking a control.
if i was absolutely certain the device is stable, i could start over, but i'm really not.
so, i guess i should take a step back and realize that i've built up a level of complexity that i'm better off finding a way to jettison. that's what i ought to be focusing on - ensuring clean drivers and starting over.
i had all of the initial renders. i created a few new renders. now, if the gear was working correctly and i was hearing things, those files should be identical. you can test to see if that's the case via phase inversion. if they're the same, you should get a flat signal when you paste the inversion on top of the original. we then say that the two signals null.
the renders i created today did not null with the renders i created a few weeks ago. the cubase projects have not been modified in that period, i can be sure of that by checking the dates on the project files.
that should not make sense. they should null.
so, what that indicates is that the signal that was coming out of the mixer a few weeks ago was different than the signal that is coming out of the mixer today. that can only be true if something was broken at that time. so, that's a mathematical proof that the files are in fact different and i'm not tricking myself.
it's sort of strange, though. because in some cases the drums actually do null. the bass does not come close to nulling. it's normal for otherwise identical files to not null over reverb, and so i might expect some bleeding over the amp simulation. but, it's far too profound for that. the guitars also tend to roughly null, except at the high frequencies. put together, this is consistent with what i was experiencing - a floor in the sub-bass along with a cut in the high end.
i've been fairly certain that what i'm getting out today ought to be the clean, correct version. but, i'm not entirely sure if i mixed some of these things before or after it broke. the first track actually nulled perfectly. the next couple of tracks were mixed on the same day, but i re-rendered some of them. the result is that i'm lacking a control.
if i was absolutely certain the device is stable, i could start over, but i'm really not.
so, i guess i should take a step back and realize that i've built up a level of complexity that i'm better off finding a way to jettison. that's what i ought to be focusing on - ensuring clean drivers and starting over.
you know, this is a piece of music to be proud of - maybe especially because i was 15 when i wrote it, although this version was created (initially with vocals) when i was 17. you've got that harpsichord part at the beginning, which was programmed into an ry30. bass parts inspired by tony levin. arpeggiated guitars, moving into a slow motion sweep pick on a big bass beat, opening up into those trills as the climax and falling into a big open chord grunge chorus. all kept together by a percussive use of noise as a rhythmic background, including a sample of a printer. it's something a mid 80s peter gabriel might have come up with. as art pop it's arguably rather revolutionary. this is old,, but it's really worth fighting for to get just right. i just really wish the gear would cooperate in stabilizing a sound so i can actually do it.
no. it's....
when you're dealing with subtle shifts in tone, it's useful to focus on certain subtle aspects. there's a trill in this song at about 3:06 fairly high up on the e string. that's a relatively high frequency, in the way it intersects with the guitar effects. it's also the most important part of the song, in my view. it seems to come in and out of the mix. when i can hear it, i know things are well. when i can't, i know i'm losing some high end.
as mentioned, the point of this replacement was to clarify the tone. i could initially hear it through the bandcamp stream. now i can't. and now i'm consistently missing it through the mixer, too.
i'm really back at square one with no further leads.
:(
when you're dealing with subtle shifts in tone, it's useful to focus on certain subtle aspects. there's a trill in this song at about 3:06 fairly high up on the e string. that's a relatively high frequency, in the way it intersects with the guitar effects. it's also the most important part of the song, in my view. it seems to come in and out of the mix. when i can hear it, i know things are well. when i can't, i know i'm losing some high end.
as mentioned, the point of this replacement was to clarify the tone. i could initially hear it through the bandcamp stream. now i can't. and now i'm consistently missing it through the mixer, too.
i'm really back at square one with no further leads.
:(
there's a corrected mix for this up.
https://jasonparent.bandcamp.com/track/aliens-are-more-likely-than-god
https://jasonparent.bandcamp.com/track/aliens-are-more-likely-than-god
the clarity is refreshing, but i have to say it's exposed a few problems, especially in the bass. for the first track, that's an asset - i'm finally getting the nice thump i wanted. for the fourth, it's creating something that needs serious attention from some limiters. and the fifth is going to need some compression. i was hoping this would be quick, but i'm going to have to be a little more systematic.
bass always takes a long time for me to get right. the source material is not the best. it will come through.
bass always takes a long time for me to get right. the source material is not the best. it will come through.
Monday, July 27, 2015
i'm finally convinced that i have this fixed, but it's bed time, now. i'm going to want to re-render pretty much everything for this project, but i actually think the mixing details will be pretty slight. even the stuff i was iffy on actually seems to sound pretty good.
my (hopefully) final analysis on this is as follows:
1) the initial problem was probably related to the codec install, although i can't state exactly what it did and will likely never know. it was a slightly different problem than showed up later on in the sense that it was at least consistent.
2) on the 21st, i ran the registry wipe. that would have broken the clock and put everything out of sync. i should have actually realized that, because i should have known to manually update the system drivers. i may have fixed the initial problem, but i wouldn't have been able to tell if i did because i broke the clock. since the 21st, this has been the primary problem, but i didn't realize it.
3) the reinstall ran the same registry wipe, which broke the clock again.
4) fixing the clock seems to have resolved the issue altogether.
i fully intend to get some serious work on this done tomorrow.
my (hopefully) final analysis on this is as follows:
1) the initial problem was probably related to the codec install, although i can't state exactly what it did and will likely never know. it was a slightly different problem than showed up later on in the sense that it was at least consistent.
2) on the 21st, i ran the registry wipe. that would have broken the clock and put everything out of sync. i should have actually realized that, because i should have known to manually update the system drivers. i may have fixed the initial problem, but i wouldn't have been able to tell if i did because i broke the clock. since the 21st, this has been the primary problem, but i didn't realize it.
3) the reinstall ran the same registry wipe, which broke the clock again.
4) fixing the clock seems to have resolved the issue altogether.
i fully intend to get some serious work on this done tomorrow.
as i went into device manager to disable one of the cards, i noticed that the microsoft streaming proxy device had an exclamation mark and a code 19, telling me that the registry was wiped. and, that jogged my memory.
one of the reasons that i'm sticking with xp is that it's winlited. rather dramatically. the iso is...well, it's pretty big because it has install scripts and added programs. but, if it was just the winlited iso it would be around 50 mb. it's the size of one of those mini-linux distros. and it's cut down just as much. on top of that dramatic haircut, i run an install script that deletes hundreds of windows files and wipes out half the registry. it's pretty comprehensive. mine is the only non-network computer i've ever seen where trying to hit the internet from windows explorer actually seriously fails.
i can't know what caused the problem initially because i've wiped it down. it may have very well been the codec install - or perhaps the uninstall. but, i do know that i've seen this problem with the streaming device before, and i know that the reason it's telling me it's not in the registry is because it's not in the registry - the install script wiped it. the script is almost ten years old. i was mixing in cool edit via cut and paste at the time. my sleuthing told me it was a windows media service. i've just never updated the script..
...because it's an easy fix - i take it out of my vanilla sp3 virtual machine that i keep around for these reasons and install via device manager. i've actually done this before, albeit not for this reason. i forgot to do it on the recent reinstall.
time will tell if that's actually what the problem was. but, i think it makes sense.
thanks.
one of the reasons that i'm sticking with xp is that it's winlited. rather dramatically. the iso is...well, it's pretty big because it has install scripts and added programs. but, if it was just the winlited iso it would be around 50 mb. it's the size of one of those mini-linux distros. and it's cut down just as much. on top of that dramatic haircut, i run an install script that deletes hundreds of windows files and wipes out half the registry. it's pretty comprehensive. mine is the only non-network computer i've ever seen where trying to hit the internet from windows explorer actually seriously fails.
i can't know what caused the problem initially because i've wiped it down. it may have very well been the codec install - or perhaps the uninstall. but, i do know that i've seen this problem with the streaming device before, and i know that the reason it's telling me it's not in the registry is because it's not in the registry - the install script wiped it. the script is almost ten years old. i was mixing in cool edit via cut and paste at the time. my sleuthing told me it was a windows media service. i've just never updated the script..
...because it's an easy fix - i take it out of my vanilla sp3 virtual machine that i keep around for these reasons and install via device manager. i've actually done this before, albeit not for this reason. i forgot to do it on the recent reinstall.
time will tell if that's actually what the problem was. but, i think it makes sense.
thanks.
This sounds like a phasing problem where the audio is following two paths through the system and the clock on one path is running slightly by about 1/120Hz faster than the other.
well....i'm at no point sending it out through two directions. older versions of cubase like that require you use one card at a time. but, a conflict is something i can test for by disabling the cards. it's worth a shot. i think anything is at this point. but, i'm not putting too much faith in it.
i think the idea of the clock being off some other way is maybe a possible explanation, though. thanks for that as a path to explore.
well....i'm at no point sending it out through two directions. older versions of cubase like that require you use one card at a time. but, a conflict is something i can test for by disabling the cards. it's worth a shot. i think anything is at this point. but, i'm not putting too much faith in it.
i think the idea of the clock being off some other way is maybe a possible explanation, though. thanks for that as a path to explore.
completely stumped, resorting to "magnetic interference" as a possible explanation
hi.
i've got a very strange issue, just wanting to run it through some people to see if anybody's seen this before, before i start lining my walls with tinfoil. i'm not joking.
i'm running xp. of the soundcards in the machine, two are of importance: an alesis 16 channel firewire mixer and an m-audio delta 3296 that connects over good old pci. my main daw is cubase sx 3. yes, it's all very old. it works just fine. i'm going to need to move up to 64 bit one day to access more ram, but that day does not appear to be on the horizon.
a few weeks ago, i installed a windows codec pack in an attempt to get firefox to natively read flac over ogg. i misread the documentation; that's impossible. it shouldn't be impossible, but so be it. i had previously identified this as the root of the problem, but i've recently been backing away from that.
basically, i'm getting random tone issues out of both of these cards over all interfaces: asio, wdm and kmixer. from time to time, it actually sounds "correct". but, then it randomly modulates between being floored by the subbass and being cut around 2000 Hz. it happens in cubase over asio. it happens in foobar over wdm and through the kmixer.
this afternoon, i was finally able to isolate something specific, but this is such a fleeting problem that it's possible that it could change in a few hours, or have already changed.
imagine this..
you have a snare. it's a closed snare. it's just one hit. you put that snare hit on repeat in cubase. after about two minutes, that closed snare sounds like an open snare. so, you reset your drivers - and you get the closed snare again. two minutes later, it's an open snare again. and, this is repeatable through all of the following signal paths:
1) cubase-->asio-->alesis
2) cubase--->asio--->m-audio
3) foobar--->wdm--->alesis
4) foobar--->kmixer--->m-audio
i've tried driver reinstalls. i've tried an os reinstall. i've swapped every cord you can imagine. i've swapped out amps. consistency seems unobtainable.
is it time to line the walls with foil? does anybody have a better idea?
i've got a very strange issue, just wanting to run it through some people to see if anybody's seen this before, before i start lining my walls with tinfoil. i'm not joking.
i'm running xp. of the soundcards in the machine, two are of importance: an alesis 16 channel firewire mixer and an m-audio delta 3296 that connects over good old pci. my main daw is cubase sx 3. yes, it's all very old. it works just fine. i'm going to need to move up to 64 bit one day to access more ram, but that day does not appear to be on the horizon.
a few weeks ago, i installed a windows codec pack in an attempt to get firefox to natively read flac over ogg. i misread the documentation; that's impossible. it shouldn't be impossible, but so be it. i had previously identified this as the root of the problem, but i've recently been backing away from that.
basically, i'm getting random tone issues out of both of these cards over all interfaces: asio, wdm and kmixer. from time to time, it actually sounds "correct". but, then it randomly modulates between being floored by the subbass and being cut around 2000 Hz. it happens in cubase over asio. it happens in foobar over wdm and through the kmixer.
this afternoon, i was finally able to isolate something specific, but this is such a fleeting problem that it's possible that it could change in a few hours, or have already changed.
imagine this..
you have a snare. it's a closed snare. it's just one hit. you put that snare hit on repeat in cubase. after about two minutes, that closed snare sounds like an open snare. so, you reset your drivers - and you get the closed snare again. two minutes later, it's an open snare again. and, this is repeatable through all of the following signal paths:
1) cubase-->asio-->alesis
2) cubase--->asio--->m-audio
3) foobar--->wdm--->alesis
4) foobar--->kmixer--->m-audio
i've tried driver reinstalls. i've tried an os reinstall. i've swapped every cord you can imagine. i've swapped out amps. consistency seems unobtainable.
is it time to line the walls with foil? does anybody have a better idea?
Subscribe to:
Posts (Atom)