color changes when adding more tracks

  • Thread starter Thread starter mixaholic
  • Start date Start date
xstatic said:
Isn't it possible that the coloration being experienced here is just how audio assembles in a mix? It seems to me that as you add tracks, they could be stepping on each other. Basically, the more stuff you add, the more they affect each other which is true of any mix on any system analog or digital. Things like guitars stepping on bass etc...
True, but he's claiming that even muted tracks are adding color just by existing.

Now, frankly, that makes no sense to me; it sounds like the summing algorithm is being affected by the presence of anther track even though that track is not added to the sum.

In fact I can't think of ANY reason why that symptom should be happening. I'm not saying it's not happening to him, I'm just saying that I can't think of a single good reason why that should happen at all. That's why I was wondering about whether it happened in different software titles; I was trying to narrow down the cause.

I gotta ask mixaholic - nothing personal, forgive me for asking; but are you sure you're reporting the symptoms correctly?

G.
 
Good catch Glen. In reading through this thread I had forgotten by the bottom that he had said it was different even with tracks muted. I was thinking that it could have been frequency build up from multiple tracks that was changing the overall tonality of the mix.
 
he said in his original post it happened in all programs.. why do you think I narrowed it down so quickly to it being system or soundcard related...
 
its got to be imaginary....there is not a single person here who has not tweaked the eq on a track to where it sounds "perfect"...only to realize they were adjusting a totally different track than they thought by accident.
 
Mistral said:
he said in his original post it happened in all programs.. why do you think I narrowed it down so quickly to it being system or soundcard related...
Oh, Mistral, I really don't want to butt heads again, but I already gave the reason as to why it can't be the soundcard. And frankly the more I think about it, I don't see how the CPU, FPU or even amount of memory would have anything to do with it either. I could be missing something on that last part, perhaps, but I can guarantee it's not the sound card because the coloration is coming from far upstream of the card.

This sounds like one of those instances that falls under the old saying, "If you're sure everything is right, but everything doesn't fit together, something you're sure is right is wrong." The symptions as described when taken together just do not add up, which is why I'm doublechecking whether the symptions are indeed reported accurately and completly.

G.
 
I'm curious as to how the original poster defines "coloration".

I'd like to hear a sound clip of before and after as well.
 
FALKEN said:
its got to be imaginary....there is not a single person here who has not tweaked the eq on a track to where it sounds "perfect"...only to realize they were adjusting a totally different track than they thought by accident.
I did that just the other day!!!! :D :D :D
 
Yes i'm sure im posting the correct symtons. It happens in all my mixing programs such as acid and adobe. And it is not cause by me stacking tracks because even when the track is muted, it jus being the causes coloration.
 
Can you post samples of the individual tracks and then the mix?
 
Al and Glen nailed it.

The phenomenon is fairly common. Some systems rise to an audible level of inefficiency before others, with processing intensity. The other side of the equation is that some people can hear it sooner than others and some not at all.

~Tim
:)
 
Beck said:
The phenomenon is fairly common. Some systems rise to an audible level of inefficiency before others, with processing intensity. The other side of the equation is that some people can hear it sooner than others and some not at all.
Tim, the part I don't understand - maybe you have some insight here - is why a muted track is adding "processing intensity"? It seems to me that a muted track/thread should be ignored by - or rather not sent to - the summing engine altogether.

One might reply, well, maybe Brand X software is poorly designed that way. Then that begs the next question, "why does he say that it happens with multiple brands?" I find it hard to believe that they are all designed in such a way where muted tracks are adding burden to the summing engine or to the CPU/FPU.

It just doesn't seem to sum up (cheap lousy pun intended) to me. What am I missing?

G.
 
Muting a track is not the same as disabling or bypassing the plugin(s) being used on the track, though it may depend on how the software is written. In the software I use, muting the track will not change the processor usage, but bypassing or disabling the plugins on the track will lower it.

So any changes to the sound due to processor usage (or whatever it the cause of this) will not necessarily be improved by muting the track.
 
SonicAlbert said:
Muting a track is not the same as disabling or bypassing the plugin(s) being used on the track.
Albie,

Is that true even if that is the only track using that plug?

OK, if that's the case, then the workaround/solution to the problem should be the same as it would be for having too many active tracks, right? Namely, temporarily lock/prerender the tracks not currently being edited.

G.
 
well some DAW softies do have a mutes saves CPU cycles. Just having extra tracks do use up some CPU cycles regarless of plug ins instantiated. I guess it depends on the DAW and/or audio driver. So it could be that the driver/ CPU algo is crapping out and resulting in the sum crapping out=headroom being exhausted. I gather the audio engine driver is what makes the sum no?
But were talkin' Soundblaster right?

SouthSIDE Glen said:
Tim, the part I don't understand - maybe you have some insight here - is why a muted track is adding "processing intensity"? It seems to me that a muted track/thread should be ignored by - or rather not sent to - the summing engine altogether.

One might reply, well, maybe Brand X software is poorly designed that way. Then that begs the next question, "why does he say that it happens with multiple brands?" I find it hard to believe that they are all designed in such a way where muted tracks are adding burden to the summing engine or to the CPU/FPU.

It just doesn't seem to sum up (cheap lousy pun intended) to me. What am I missing?

G.
 
SouthSIDE Glen said:
Tim, the part I don't understand - maybe you have some insight here - is why a muted track is adding "processing intensity"? It seems to me that a muted track/thread should be ignored by - or rather not sent to - the summing engine altogether.

One might reply, well, maybe Brand X software is poorly designed that way. Then that begs the next question, "why does he say that it happens with multiple brands?" I find it hard to believe that they are all designed in such a way where muted tracks are adding burden to the summing engine or to the CPU/FPU.

It just doesn't seem to sum up (cheap lousy pun intended) to me. What am I missing?

G.

Generally speaking, on one level the system sees the process of muting as “work.” On another level the data representing the audio hasn’t really released any resources by being muted. It’s just that it can’t be heard or detected.

As far as standards go, it’s still a free-for-all when it comes to design, save that the software has to interact with MS Windows (most commonly anyway). Certain subsystems that share similar weaknesses regardless of software follow an industry adopted integration scheme with the Windows OS at that level. So brand X, Y and Z may all use the same scheme. Thus they have similar limitations, which are fundamentally hardware and OS limitations.

Windows 2000 & XP are resource hogs anyway. You have to go into XP and deliberately strip it down to a functional minimum… and don’t laugh, but a Windows 98 SE machine dedicated only for studio apps and nothing else is still an attractive alternative compared to the massive XP OS with all its bells and whistles enabled. Just think, that OS is designed to manage (control?) every aspect of one's life :eek: -- just overkill if you have a narrowly defined purpose for it in mind.

I know this is a simplification, but short of dissecting Acid Pro here on the table we can only speak in generalities.

On the other hand mixaholic might have SETI@home running in the background :D or somehow disabled UDMA. :p One never knows for sure. That would certainly exacerbate the problem.

~Tim
:)
 
Last edited:
From what I understand, any program running in real time would see the same load whether a track is muted or unmuted. If it did not, every time we unmute a track (mute automation comes to mind here) we would have to wait for that audio file to load and process before we could hear the results. Most apps do have a disable feature though which removes that track and its associated functions from the running load.
 
if there is no data in the track then i can't imagine the load would be significant.....
 
Could be to do with there being a whole bunch of vst's switched on in a particular track...just a guess...even if there is no audio file in the track those VST's are still going to be doing their thing...

The other possibly (from the experiences I have had recently) is just that computers are just dicks sometimes. I rebuild my computer every 6 months or so now because after a while pc's just seem to start fucking up.
 
I've found the load added by an empty track is insignificant, as is the load added by a track of audio with no processing on it.

What I was saying in my earlier post is that the *plugins* on a muted track will still be eating processor cycles. So if you remove the plugins from the track or put the plugins into bypass you will reduce the processor load. Or if you record the track with the processing and delete the original, or mute the original and disable the plugins on it.

But yes, in my experience the processor load is the same whether a track is muted or unmuted.
 
Back
Top