In this post I am just trying to clarify the thread a little bit here...
If I am understanding you right Garyb you do agree that straight up summing is the same BUT...
That is not the point as the scope mixer sounds better as a tool when used in real world situations.
Is that right?
There is no sarcasm here. I am just trying to clear things up. I was afraid that this thread was going to get all bent out of shape. And it seems that it has gotten to that point.
Another thread about summing in scope
-
Mike Goodwin
- Posts: 170
- Joined: Sun Dec 02, 2007 8:42 am
- Contact:
Re: Another thread about summing in scope
I'm afraid the only operations feasible in that time is the null operation or maybe the level raising (summing with a constant). I don't know for sure about those plugins but obviously speed depends upon the processor speed (and rest of system) and the only technology which ensures 0-1 sample delay is "time compensation" which means more latency added to all the signals to sync them with the processed one.Mike Goodwin wrote:Ok there is zero latency and then there is zero sample latency. The audio interface will introduce latency sure. I am not talking about that. All I am trying to say is that there is software that can do what it needs to do in less than 1/44100th - 1/96000th of a second.
That means this chain:
you send an analog input to a whatever soundcard, then to the sequencer, then to the plugin with 0 latency declared plus latency added for compensation, then to the sequencer again, then to the soundcard and finally out: wow, how much time it took? how many samples?
Sorry, but I don't believe in the zero latency mirage, I prefer quality and accuracy, and quality and detailed (complex) algorithms are more likely to take more time than less.
Said that, in my experience - tests made some years ago - cubase and logic sound very different on the same audio tracks w/o any effects, being the last much deeper and rich in bass sounds, don't know why. Don't know about scope mixers I rarely needed them.
Different algos use different approximations and produce different results, even a stupid operation like volume leveling produce an approximation because it requires a multiply/divide op on an integer that will produce a float: how is that float handled? is it truncated, mathematically rounded or dithered by one more algo?
..I was forgetting: happy new year
Fede
Re: Another thread about summing in scope
Mike Goodwin wrote:In this post I am just trying to clarify the thread a little bit here...
If I am understanding you right Garyb you do agree that straight up summing is the same BUT...
That is not the point as the scope mixer sounds better as a tool when used in real world situations.
Is that right?
There is no sarcasm here. I am just trying to clear things up. I was afraid that this thread was going to get all bent out of shape. And it seems that it has gotten to that point.
i'm sorry if i made things more confusing.
mpodrug, i'm sorry to be a little sarcastic, i'm really in the best of humor, REALLY! in no way do i feel that there is warfare here. if you reread my posts, i think you'll see that.
Re: Another thread about summing in scope
I don't think so - with a timeslice of 1/100.000 of a second you could execute 10 instructions at a 1 MHZ clockrate (assuming 1 instruction per cycle). In the current 2 GHZ environment this adds up to 20k simple instructions. Even with complex ones the CPU might still process 4000 instructions in 1/100k of a second.Fede wrote:I'm afraid the only operations feasible in that time is the null operation or maybe the level raising (summing with a constant). ...Mike Goodwin wrote:Ok there is zero latency and then there is zero sample latency. The audio interface will introduce latency sure. I am not talking about that. All I am trying to say is that there is software that can do what it needs to do in less than 1/44100th - 1/96000th of a second.
So here's the source of your 'optimized' code, Mike
which it certainly isn't - after all it's just an equalizer
add the fact that a regular $100 CPU has more high-speed cache memory within the CPU than a corporate mainframe in the 80s had Ram ...
now we can focus on summing again
cheers, Tom
Re: Another thread about summing in scope
yes, in single-task real-time environment it is theoretically true but under NT kernel with other "unoptimized" code running together with the plugin...astroman wrote:I don't think so - with a timeslice of 1/100.000 of a second you could execute 10 instructions at a 1 MHZ clockrate (assuming 1 instruction per cycle). In the current 2 GHZ environment this adds up to 20k simple instructions. Even with complex ones the CPU might still process 4000 instructions in 1/100k of a second.
it cannot be latency free by design, they should put an "almost" somewhere in the statement.
Re: Another thread about summing in scope
you see ? I just can't deny my Mac heritage - still assuming that an OS behaves well 
even if your 'realistic' approach spoils the party, 2 billion cycles per second are a lot...
but then - that's just 125 times faster than 16 MHZ...
and if 125 tasks (of which 100 are likely nonsense) compete for the CPU...
that explains why those 16 MHZ machines from the past weren't 'feeling' slow at all
cheers, Tom
even if your 'realistic' approach spoils the party, 2 billion cycles per second are a lot...
but then - that's just 125 times faster than 16 MHZ...
and if 125 tasks (of which 100 are likely nonsense) compete for the CPU...
that explains why those 16 MHZ machines from the past weren't 'feeling' slow at all
cheers, Tom
Re: Another thread about summing in scope
well... my 'realistic' approach would say that we're not considering threads (they're usually more than 125), priorities, context switches, semaphores.... but it's going to be an endless discussion... in the end I've not understood what's your position about scope *mixers*.
ciao
Fede
ciao
Fede
Last edited by Fede on Sat Jan 03, 2009 4:32 am, edited 1 time in total.
Re: Another thread about summing in scope
Everytime this thread heads in a direction that might reach some form of conclusion (even if that conclusion is inconclusive) something else gets roped into the discussion under the 'summing' umbrella.
The softare eq's referred to in this thread are being touted as 'zero latency' because they aren't using any calculations that require delaying output to know the state of future samples. Ie, their state isn't dependant on what comes after (or before) and so they simply crunch whatever their host hands to them and then returns that back after processing. Software plugins that are *not* zero latency will have their own internal buffer; either for IR calculations, for 'soft-clip' or 'lookahead' functions, and so on.
This isn't to be confused with the total latency of an input signal, through the ASIO buffers and then the host's internal combined processing overhead, back out through ASIO outputs to analog DA. But I think you guys finally sussed that one out in this conversation...
Scope's internal processing (for eq's etc, beyond simple 'summing') may have some small overhead but for something as simple as the stock eq's there shouldn't be any more latency than the buffer present on the dsp chip. However the phase (time-based) inaccuracies that are referred to with the Scope platform also occur when data is passed from one dsp chip to another, in particular previous discussions have focused on when dsp code overlaps two or more chips. Even the mixers can do this when additional channels are added, which is why some of these have 'phase compensation' as a toggle.
All things being considered, when you have a mixing environment that doesn't automatically compensate for phase shift (time-based) the only time you'll have a problem is when mixing things in parallel. A multitrack recording of several instruments, parallel processing techniques (like parallel compression) or effects mixing where you return some of the dry signal) and so on. These are the only situations where the sample accuracy is really going to matter, at least in theory. If you're doing an all electronic composition, or mixing instruments recorded individually (without bleed-through on the mics from other instruments around) then having a few samples timing shift will make no difference whatsoever (imo).
However even in situations like a drum kit multi-mic'd with a guitarist and bass player doing funk/fusion that 'should' be phase-coherent, there are even reports here of users using the Scope environment and preferring those results to mixing ITB. For situations like that, where phase innacuracies are certain to be present and yet people still 'prefer' the 'inaccurate' results ('ala GaryB) it's good to keep in mind that mathematical accuracy in a musical context isn't as important as Musicality (a PURELY subjective thing). I believe that there was a quote from a developer several pages back that was saying essentially that.
Personally the way that Scope's dsp allocation shifts things across dsp chips seemed somewhat random at first, but once Red Muze showed me that this was present (and provided a Phasefix & Phasefix-x set of tools for me to play with) it doesn't bother me in the least. I was used to manually compensating for processing overhead in digital sequencers/daw hosts before they gained "automatic latency compensation" 6-7 years ago, and these same techniques apply to the Scope environment and even to mixing with live gear (where some of your outboard fx may be using dsp). The key here is to be cognizant of the places that phase shift may be a problem, test for this shift upon loading your project *before you do your final mixing*. For drums and bass/subbass heavy instrumentation I tend to pay particular attention during the entire production as phase errors here can have a large impact upon my perception of what needs to be done to sculpt the sounds, but otherwise all of this is intuitive and easy to do after you learn it and practice a few times.
The softare eq's referred to in this thread are being touted as 'zero latency' because they aren't using any calculations that require delaying output to know the state of future samples. Ie, their state isn't dependant on what comes after (or before) and so they simply crunch whatever their host hands to them and then returns that back after processing. Software plugins that are *not* zero latency will have their own internal buffer; either for IR calculations, for 'soft-clip' or 'lookahead' functions, and so on.
This isn't to be confused with the total latency of an input signal, through the ASIO buffers and then the host's internal combined processing overhead, back out through ASIO outputs to analog DA. But I think you guys finally sussed that one out in this conversation...
Scope's internal processing (for eq's etc, beyond simple 'summing') may have some small overhead but for something as simple as the stock eq's there shouldn't be any more latency than the buffer present on the dsp chip. However the phase (time-based) inaccuracies that are referred to with the Scope platform also occur when data is passed from one dsp chip to another, in particular previous discussions have focused on when dsp code overlaps two or more chips. Even the mixers can do this when additional channels are added, which is why some of these have 'phase compensation' as a toggle.
All things being considered, when you have a mixing environment that doesn't automatically compensate for phase shift (time-based) the only time you'll have a problem is when mixing things in parallel. A multitrack recording of several instruments, parallel processing techniques (like parallel compression) or effects mixing where you return some of the dry signal) and so on. These are the only situations where the sample accuracy is really going to matter, at least in theory. If you're doing an all electronic composition, or mixing instruments recorded individually (without bleed-through on the mics from other instruments around) then having a few samples timing shift will make no difference whatsoever (imo).
However even in situations like a drum kit multi-mic'd with a guitarist and bass player doing funk/fusion that 'should' be phase-coherent, there are even reports here of users using the Scope environment and preferring those results to mixing ITB. For situations like that, where phase innacuracies are certain to be present and yet people still 'prefer' the 'inaccurate' results ('ala GaryB) it's good to keep in mind that mathematical accuracy in a musical context isn't as important as Musicality (a PURELY subjective thing). I believe that there was a quote from a developer several pages back that was saying essentially that.
Personally the way that Scope's dsp allocation shifts things across dsp chips seemed somewhat random at first, but once Red Muze showed me that this was present (and provided a Phasefix & Phasefix-x set of tools for me to play with) it doesn't bother me in the least. I was used to manually compensating for processing overhead in digital sequencers/daw hosts before they gained "automatic latency compensation" 6-7 years ago, and these same techniques apply to the Scope environment and even to mixing with live gear (where some of your outboard fx may be using dsp). The key here is to be cognizant of the places that phase shift may be a problem, test for this shift upon loading your project *before you do your final mixing*. For drums and bass/subbass heavy instrumentation I tend to pay particular attention during the entire production as phase errors here can have a large impact upon my perception of what needs to be done to sculpt the sounds, but otherwise all of this is intuitive and easy to do after you learn it and practice a few times.
Last edited by valis on Sat Jan 03, 2009 5:12 am, edited 1 time in total.
Re: Another thread about summing in scope
I'm going to follow up to my own post with an additional thought or two...
It seems to me that once a certain technique is introduced to your toolset, using it in your overall workflow is purely a discretional thing. Many techniques that we use in creating music and other human endeavors have as much to do with recognizing the limits of our tools and our selves, as they do with the possibilities beyond those limits. So phase issues are an achilles heel of Scope (and MANY other dsp environments that aren't host based!) but in addition to manually compensating for each point in a mix where there's a problem there are MANY other options.
For instance let's take the example of a drum submix. Say the rest of your instrumentation from a live session was relatively isolated (or far enough separated that 3-4 extra samples latency won't be critical for what is essentially room noise/early reflections) but your drummer had the typical individual mics for the 2 overheads, 2 kick mics, snare mic, toms and so on. Well instead of fussing with Scope to keep this phase accurate each time you load a project you have other options as well: submix this in your sequencer and send a single stereo pair out, submix this in scope where you only need to deal with phase issues ONCE and then render to a stereo pair, ignore final summing in Scope and use Scope for some of its other possibilities during this session, and so on.
Scope can be a final summing environment, a creative sound design environment, a synthesist's toolbox, a live mixing environment, etc etc. How you use it is largely going to be a combination of what your current project provides and how deep your understanding of Scope runs (as well as what other tools you have on hand).
Again though all of this falls a lot further afield than just a simple 'summing' discussion, though that's intimately wrapped into that blanket along with the rest of the warmth (digital warmth though it is).
It seems to me that once a certain technique is introduced to your toolset, using it in your overall workflow is purely a discretional thing. Many techniques that we use in creating music and other human endeavors have as much to do with recognizing the limits of our tools and our selves, as they do with the possibilities beyond those limits. So phase issues are an achilles heel of Scope (and MANY other dsp environments that aren't host based!) but in addition to manually compensating for each point in a mix where there's a problem there are MANY other options.
For instance let's take the example of a drum submix. Say the rest of your instrumentation from a live session was relatively isolated (or far enough separated that 3-4 extra samples latency won't be critical for what is essentially room noise/early reflections) but your drummer had the typical individual mics for the 2 overheads, 2 kick mics, snare mic, toms and so on. Well instead of fussing with Scope to keep this phase accurate each time you load a project you have other options as well: submix this in your sequencer and send a single stereo pair out, submix this in scope where you only need to deal with phase issues ONCE and then render to a stereo pair, ignore final summing in Scope and use Scope for some of its other possibilities during this session, and so on.
Scope can be a final summing environment, a creative sound design environment, a synthesist's toolbox, a live mixing environment, etc etc. How you use it is largely going to be a combination of what your current project provides and how deep your understanding of Scope runs (as well as what other tools you have on hand).
Again though all of this falls a lot further afield than just a simple 'summing' discussion, though that's intimately wrapped into that blanket along with the rest of the warmth (digital warmth though it is).
Re: Another thread about summing in scope
That's not correct - Many digital effects needs the previous sample for processing inclunding filters (EQ's).valis wrote:The softare eq's referred to in this thread are being touted as 'zero latency' because they aren't using any calculations that require knowing more than the current sample set's values. Ie, their state isn't dependant on what comes after (or before)..........................
Re: Another thread about summing in scope
I wasn't saying that no filter (eq) design needs the additional data. It would just seem that if they're touting zero latency then they're saying their particular filter (eq) implementation doesn't have the latency. It's been over a decade since I played with algorithms but when AD sharcs were still running 'realtime csound' there were csound filters that didn't incur a time-related penalty as a product of an internal buffer in the algorithm itself, or am I mistaken?Warp69 wrote:That's not correct - Many digital effects needs the previous sample for processing inclunding filters (EQ's).valis wrote:The softare eq's referred to in this thread are being touted as 'zero latency' because they aren't using any calculations that require knowing more than the current sample set's values. Ie, their state isn't dependant on what comes after (or before)..........................
Re: Another thread about summing in scope
afaik the accuracy of a Fourier transform depends on the width of the time slice considered.
Fede
Fede
Re: Another thread about summing in scope
They also need the previous sample for processing. The need for the previous sample has nothing to do with latency.valis wrote:I wasn't saying that no filter (eq) design needs the additional data. It would just seem that if they're touting zero latency then they're saying their particular filter (eq) implementation doesn't have the latency. It's been over a decade since I played with algorithms but when AD sharcs were still running 'realtime csound' there were csound filters that didn't incur a time-related penalty as a product of an internal buffer in the algorithm itself, or am I mistaken?
Output = (1-coefficient) * Input + coefficient * previous sample has zero latency.
Re: Another thread about summing in scope
A more accurate statement on my part would have been that there wasn't a need to delay output as a part of the calculation, you were being precise in your response. I understand and concede that I had worded that poorly. What I had meant to say was that the current sample position's operation didn't need to know the state of 'future' samples, as would be the case with Fede's FIR filter example (for instance).
Re: Another thread about summing in scope
Ola Mike!
you are totally correct. there is no benefit in summing in scope.
however you should take into account two things:
1) the placebo effect - a powerful effect, that affects music very much and should not be underestimated. if you think it sounds better, than you will make other musical decisions. however, once you know there is no gain the placebo effect is diminished, even with shiny knobs.
2) the real strength of scope is all of the years of RnD and some of its great algorithms. using scopes eq's and effects gives another great color, and usually its just more comfortable to mix some busses in scope.
3) the most important thing: music creation process. making music with scope is not like making music with ableton live. and the creation process is eventually what guides your music and defines allot of its rules and boundaries.
specifically for the summing issue - its all voodoo for pseudo golden ears.
i remember a specific meeting with israel's top producer and top engineer (i will spare the names). where they were trying to convince me that copying files from hard drive to hard drive changes the sound "shh! listen to the top end!!", and backups of tracks sound not as vibrant. i did the phase inversion and normalization technique to prove them wrong, but the response was - "fuck computers, i know what i'm hearing".
ho well... whatever works for them.
you are totally correct. there is no benefit in summing in scope.
however you should take into account two things:
1) the placebo effect - a powerful effect, that affects music very much and should not be underestimated. if you think it sounds better, than you will make other musical decisions. however, once you know there is no gain the placebo effect is diminished, even with shiny knobs.
2) the real strength of scope is all of the years of RnD and some of its great algorithms. using scopes eq's and effects gives another great color, and usually its just more comfortable to mix some busses in scope.
3) the most important thing: music creation process. making music with scope is not like making music with ableton live. and the creation process is eventually what guides your music and defines allot of its rules and boundaries.
specifically for the summing issue - its all voodoo for pseudo golden ears.
i remember a specific meeting with israel's top producer and top engineer (i will spare the names). where they were trying to convince me that copying files from hard drive to hard drive changes the sound "shh! listen to the top end!!", and backups of tracks sound not as vibrant. i did the phase inversion and normalization technique to prove them wrong, but the response was - "fuck computers, i know what i'm hearing".
ho well... whatever works for them.
Re: Another thread about summing in scope
just my 2 cents.
summing is not mixing, and mixing is not summing, but summing is a part of mixing, or is mixing a part of summing?
happy new year!
summing is not mixing, and mixing is not summing, but summing is a part of mixing, or is mixing a part of summing?
happy new year!
Re: Another thread about summing in scope
Summing in a certain environment is not an abstract thing, it means that all the mixing operations will be performed in that environment with the provided tools for it. Those operations (processing) are what make the difference in sound. Scope offers a set of tools the average level of which is pretty high quality and much more musical, which doesn't mean scientifically accurate, but made by people with music in their mind and with a musical approach.
Re: Another thread about summing in scope
Even though I'm no math wizard I do know how summing works since math cannot get more basic than that...and I really cannot see how software could sound different based on the way it's adding numbers since there only is one way to do that.
Still I have many times to my great surprise found differences in what easily is perceived as simple summing, but I guess there is something different at play.
First time I realized that digital mixers does not all sound the same was when I was working with Cubase and an Yamaha 02r mixer.
First I was running a stereo pair as digital from Cubase into the mixer via SPDIF on an Korg 20/20 card, and then I got a ADAT I/O card for the 02r and when plugging that in and sending eight tracks into the 02r I totally unexpectedly noticed a difference in sound.
I tried finding a reason for the difference, but all processing was off on the channels in the 02r and levels should be the same.
I asked my friend to confirm and he could spot the difference blind as well.
This was back at version 4 of Cubase which was not only very unreliable, but included processing was really awful. I don't think I ever heard as awful EQ's. Although there was no processing involved I started wondering...if there was a difference in sound when comparing mixing on the 02r could that be the case comparing say Logic and Cubase as well?
Again there seemed to be a small difference, and enough to convince my partner who insisted on using Cubase to switch to Logic.
I know there are a lot of variables involved even if it on the surface might have seemed like only straight summing. But the way hosts handle different input formats, truncating/dithering down to interface bit depth and format used in the actual summing are examples of variables that need to be accounted for.
I know that when I make tracks in for example Orion, Reason or FL that after some 8-10 tracks I have to work much harder to separate instruments or things start turning into a mud. Here it's even more variables involved.
The quality of the processing plugins is not the issue because with Orion and FL I would use the same VST's as in Logic. And for example an unprocessed kick will start to loose definition really bad when mixing with many other tracks, so it seems like the sound of the whole mix breaks down rather than all the components of the mix being lesser quality.
But even when disregarding the processing there is more happening than simple summing when doing a whole mix.
What could be a likely culprit I still do not know. I never head any sound technical argument for what could cause this and the explanation the would make most sense would be placebo.
It's not easy to exactly recreate a mix in different hosts and make an ABX test, but in my experience, unless I'm making very minimal tracks it's very apparent and I in no way had a preconception that mixes would break down after adding a certain number of tracks.
I remember it was a discussion about audio engines and sound quality at isratrance forum where they set out to test different sequencers aiming to disprove the audio engine myth. It never was carried out properly, but they did test fruity loops and from what I recall they started with just simple summing.
To their surprise they found that each channel added contributed some noise to the mix, so after some eight tracks the dynamic range started to get reduced significantly below the capabilities of your regular converter.
Image Line was informed about the issue and from what I understand it should have been resolved in later versions.
I would be amazed if Orion and Reason had the exact same issue back when I tried them, but it goes to show that what one could think would be only straight summing infact can go wrong.
With Scope I usually use Kick-Me and Flexor for kick and bass, and on occasion I have tried to record them down in Live instead....and for some reason I don't get the same separation.
I tried different ASIO drivers including float and record in 32 bit float, but having it running straight trough the scope mixer just sounds clearer. If I send them back to scope on separate channels it's a bit better but still not the same.
I have no idea what the reason can be, but it's a very real problem for me since it would be convenient to be able to record them down sometimes.
In the end I think the main thing is what works for you. I know people making very nice music in FL, Reason and Orion even if it may not sound like a pinnacle of fidelity, but that is a lot less important than the content and the general balance of the mix.
But when I produce myself it helps my inspiration to have a sound I like. Maybe although I tried I have missed some workarounds to make A sound as good as B and although it's one 32 bit float engine vs another 32 bit float engine there . For example I made a lot of tracks in Orion since I liked the work flow, simple is good, but in the end I just had to give up because I just could not get it to sound nearly as deep and clear as when using Logic.
I'm well aware of placebo and have corrected my own misconceptions on for example sound quality of mp3's by ABX testing, but this is something I just cannot find a way to get around. So why struggle?
Even if it's placebo, until I manage to find a way to get rid of it, it is affecting my inspiration and I just have to go with it and use the tools that I find give me the sound quality I'm used to.
Still I have many times to my great surprise found differences in what easily is perceived as simple summing, but I guess there is something different at play.
First time I realized that digital mixers does not all sound the same was when I was working with Cubase and an Yamaha 02r mixer.
First I was running a stereo pair as digital from Cubase into the mixer via SPDIF on an Korg 20/20 card, and then I got a ADAT I/O card for the 02r and when plugging that in and sending eight tracks into the 02r I totally unexpectedly noticed a difference in sound.
I tried finding a reason for the difference, but all processing was off on the channels in the 02r and levels should be the same.
I asked my friend to confirm and he could spot the difference blind as well.
This was back at version 4 of Cubase which was not only very unreliable, but included processing was really awful. I don't think I ever heard as awful EQ's. Although there was no processing involved I started wondering...if there was a difference in sound when comparing mixing on the 02r could that be the case comparing say Logic and Cubase as well?
Again there seemed to be a small difference, and enough to convince my partner who insisted on using Cubase to switch to Logic.
I know there are a lot of variables involved even if it on the surface might have seemed like only straight summing. But the way hosts handle different input formats, truncating/dithering down to interface bit depth and format used in the actual summing are examples of variables that need to be accounted for.
I know that when I make tracks in for example Orion, Reason or FL that after some 8-10 tracks I have to work much harder to separate instruments or things start turning into a mud. Here it's even more variables involved.
The quality of the processing plugins is not the issue because with Orion and FL I would use the same VST's as in Logic. And for example an unprocessed kick will start to loose definition really bad when mixing with many other tracks, so it seems like the sound of the whole mix breaks down rather than all the components of the mix being lesser quality.
But even when disregarding the processing there is more happening than simple summing when doing a whole mix.
What could be a likely culprit I still do not know. I never head any sound technical argument for what could cause this and the explanation the would make most sense would be placebo.
It's not easy to exactly recreate a mix in different hosts and make an ABX test, but in my experience, unless I'm making very minimal tracks it's very apparent and I in no way had a preconception that mixes would break down after adding a certain number of tracks.
I remember it was a discussion about audio engines and sound quality at isratrance forum where they set out to test different sequencers aiming to disprove the audio engine myth. It never was carried out properly, but they did test fruity loops and from what I recall they started with just simple summing.
To their surprise they found that each channel added contributed some noise to the mix, so after some eight tracks the dynamic range started to get reduced significantly below the capabilities of your regular converter.
Image Line was informed about the issue and from what I understand it should have been resolved in later versions.
I would be amazed if Orion and Reason had the exact same issue back when I tried them, but it goes to show that what one could think would be only straight summing infact can go wrong.
With Scope I usually use Kick-Me and Flexor for kick and bass, and on occasion I have tried to record them down in Live instead....and for some reason I don't get the same separation.
I tried different ASIO drivers including float and record in 32 bit float, but having it running straight trough the scope mixer just sounds clearer. If I send them back to scope on separate channels it's a bit better but still not the same.
I have no idea what the reason can be, but it's a very real problem for me since it would be convenient to be able to record them down sometimes.
In the end I think the main thing is what works for you. I know people making very nice music in FL, Reason and Orion even if it may not sound like a pinnacle of fidelity, but that is a lot less important than the content and the general balance of the mix.
But when I produce myself it helps my inspiration to have a sound I like. Maybe although I tried I have missed some workarounds to make A sound as good as B and although it's one 32 bit float engine vs another 32 bit float engine there . For example I made a lot of tracks in Orion since I liked the work flow, simple is good, but in the end I just had to give up because I just could not get it to sound nearly as deep and clear as when using Logic.
I'm well aware of placebo and have corrected my own misconceptions on for example sound quality of mp3's by ABX testing, but this is something I just cannot find a way to get around. So why struggle?
Even if it's placebo, until I manage to find a way to get rid of it, it is affecting my inspiration and I just have to go with it and use the tools that I find give me the sound quality I'm used to.
Re: Another thread about summing in scope
My head is spinning from this thread and all of the scientific explanations, but I use combinations of Busses and AUX's for my live gig, as I noticed my stereo outs to FOH sounded distant, confined & cramped. So I guess we are all hearing the same thing inside of the box.
I use a combination of VDAT tracks, mic pre's, synths and instrument pre's. When I am just using my synths in a traditional way this isn't necessary, but when mixing the entire band and combining VDAT tracks,etc. it becomes quite clear that some seperation is needed.
Maybe 96k is a good alternative for an all in the box project, I don't know.
But I know sending groups solves the live approach.
Using the Barbetta's is a good start, but I can see the need for another piece of hardware I will be getting for gigs where I can't use my Powered stage monitors.
Using a pair of the Sona 32C's I get a final stage of control and also bring in my Rotary Cabinet output via the 2 XLR low Z's. The 2 outs can go to the FOH with much better quality.
I use a combination of VDAT tracks, mic pre's, synths and instrument pre's. When I am just using my synths in a traditional way this isn't necessary, but when mixing the entire band and combining VDAT tracks,etc. it becomes quite clear that some seperation is needed.
Maybe 96k is a good alternative for an all in the box project, I don't know.
But I know sending groups solves the live approach.
Using the Barbetta's is a good start, but I can see the need for another piece of hardware I will be getting for gigs where I can't use my Powered stage monitors.
Using a pair of the Sona 32C's I get a final stage of control and also bring in my Rotary Cabinet output via the 2 XLR low Z's. The 2 outs can go to the FOH with much better quality.
-
Mike Goodwin
- Posts: 170
- Joined: Sun Dec 02, 2007 8:42 am
- Contact:
Re: Another thread about summing in scope
Could you please clarify this for me?Psilion wrote: I tried different ASIO drivers including float and record in 32 bit float, but having it running straight trough the scope mixer just sounds clearer. If I send them back to scope on separate channels it's a bit better but still not the same.