DAW Automation Test

[stinkyfingers]

i will post some pics here to illustrate some things...

pic #1 is a zoom on the "peak" of an automated fade on a -12dB DC source, going from min > max > min values.
the +6dB (max) automation point was placed in the exact center (half-way point) of the audio file. (@ 264,600 samp out of total 529,200 samp file)
you can see from this picture that at the center of the audio file (yellow cursor) is where the 220 sample long rise to the final peak is...and the center of the peak is even further away...(about 977 samp ahead of center line)

pic #2 is the inverse of pic # 1 fade...max > min > max...so the center point here was at -inf instead of +6dB...but it is still the exact same point in time on the audio file...
looks like we still have a 220 sample "offset", but this time it is a little different...

(220 samp is +/-)

*all fades done @ 120bpm project tempo, i don't know if bpm matters yet, but i will make note here...

[Muser]

I take it you did a linear fade in the Automation Lane here.. both up and down.

If so, even though your Automation fade looks Linear in the Automation Lanes, the actual fade curves are not. this might just mean in that case that they are differently weighted when traveling in different directions.

This might mean that when you use Automation you might not end up at exactly the same dB value in real terms that you started off at. because the weighting patterns are different for moving (down) and moving (up).

there are ways you can get more precision but from what I saw, there's little point in trying, because it's possible that as soon as you alter the Automation in the Automation track itself, it will force any precision back to 7bit.

because of those different weights Logic will (decide) to make the change at a (certain) point. that would expose itself as an offset in time.

[stinkyfingers]

yes, part of that example was to show that a linear fade in Logic is not so linear...nor is it "sample accurate"...
and it doesn't seem to matter what the envelope of the fade is, it can be in one direction and you still have an "offset" from the point you set...

edit: i had a picture/post of an 32bf/24b automation time/level "mis-match" here but i removed it...
(i think it was just user error...)

[Muser]

That's odd.. because you can't marry those two by just pushing the red one up a notch.

[stinkyfingers]

yeh...i think i jumped the gun with that one because i just tried it again and the peaks line up now...
i keep getting mixed results so i will try and figure this out...

edit: pics/posts removed because i screwed up and i don't want to scare anyone with false information...

[Muser]

oh no!! not inconsistent performance results.
I hope to god that's just the automation engine. Logic has always been more errrm Analog ?

[stinkyfingers]

don't worry...this was Stinky's fault, not Logics...

i think this was a mono/stereo mis-match with my track/output/channel strip settings...
i made sure everything was set to mono everywhere and it is fine now...
i was using a new project every time and a few times i think i forgot to change the channel strip output to mono even though i had a mono track and mono output, so the export would be in stereo but the bounces would be in mono...
(sorry for any confusion, i had a rough weekend...)

[Lagerfeldt]

Thanks!

[valis]

So have we determined that it's possible to get more than 7bit automation in Logic yet? I've got some time finally today, I'll try to re-read this thread but if anyone can answer the question and save me some time I can dig in and do some tests (I'm watching my 16 month old daughter atm too so saving time might help...)

[gomfist]

heres mine

Cubase 5.5.3

24bit @88khz @170bpm

[stinkyfingers]

^ nice, thanks for doing that test...

@valis...i'm not sure about that...
i thought Muser mentioned something about using the environment and having some success (in an older ver. of Logic i think) but i was never able to duplicate it in Logic 9...

[gomfist]

no prob - just reading half way through the thread. not really understanding much yet - but if you need some more i can do.

[stinkyfingers]

i see that the Cubase fade was is stereo and was done @ 88.2 kHz...
could you do one in mono @ 44.1kHz ?
the one you did is helpful, it has new information, but i would also like one to compare with the others here at the same S.R.
we have one Cubase fade but it shows some weird artifacts at the beginning and i would like to see if it comes up again...
thanks

edit: attached a pic of Logic (top) and Cubase (bottom) with similar fades @ 88.2 kHz...
at better resolution it looks like Logic has 2x the amt. of "harmonics" / artifacts...

[stinkyfingers]

here is what is at the beginning of the first Cubase fade from this thread...
it is only on one side and it is an "impulse" at 512 samples and multiples of...
this is not in the 88.2 kHz Cubase fade, but in that one the left side is delayed about 20 samples or so...

[gomfist]

this is 44khZ at 24bit

what Software do you use for analysing those fades?

loading sox atm. can it be that sox has new features? last I checked it was for resampling and command line based when I remember correctly..

[stinkyfingers]

^thanks for the file...

sorry if this is not "correct" SoX terminologies but the command is...

sox "/directory/your_file.wav" -n rate 4k spectrogram -o "/directory/your_file.png"

> .wav can be .aif or whatever...
> 4k is the sample rate/spectrum range...it shows up to 2k...for full range enter 44.1k or leave that blank (no 'rate 4k')

it's in the manual...> http://sox.sourceforge.net/sox.html
you can adjust a few different parameters so it's worth reading for best results...


iZotope RX is good to look at the files, also...

[gomfist]

Originally Posted by stinkyfingers

sorry if this is not "correct" SoX terminologies but the command is...

sox "/directory/your_file.wav" -n rate 4k spectrogram -o "/directory/your_file.png"

> .wav can be .aif or whatever...
> 4k is the sample rate/spectrum range...it shows up to 2k...for full range enter 44.1k or leave that blank (no 'rate 4k')

it's in the manual...> SoX
you can adjust a few different parameters so it's worth reading for best results...


iZotope RX is good to look at the files, also...

thx! just fiddling with it

http://www.abload.de/img/spectrogramdfjyt.png

[stinkyfingers]

there seems to be something "strange" with the new 44.1 kHz Cubase file...
i'm noticing a similar "glitch" at the beginning with intermittent spikes in the run of the stepping but this new one looks to have an "extra" HF component in the signal at times...

edit: attached pics > pic 1 = glitch in first Cubase fade / pic 2 = glitch in 2nd Cubase fade...
they are not the same points in time or even the same scale but just to show what is there...

[Muser]

Originally Posted by valis

So have we determined that it's possible to get more than 7bit automation in Logic yet? I've got some time finally today, I'll try to re-read this thread but if anyone can answer the question and save me some time I can dig in and do some tests (I'm watching my 16 month old daughter atm too so saving time might help...)

you (should) be able to get 10bit with mackie control / HUI.
I think at one point i did create a 14bit fader in the environment but,
I think I somehow I tricked the environment into operating in a way
it isn't normally supposed to. I could see the fine values being entered
into Logics (yellow bar) readout if I remember correctly.

I can't remember if I tried to record it. but the thing is, from what I can
tell, when you do any work in the Automation lane using the normal Automation
system, Logic probably defaults back to 7bit.

what I am unsure of is (if) HUI 10bit is being used, will the 10bit be retained
when doing this Automation lane editing.. or will it be lost. This should be the
thing of concern to mackie control users as they may have invested capital for that resolution.

if that works great! if not I reckon it's the best avenue to leverage a change in Logic to higher bit depth Automation.

[stinkyfingers]

i really wanted to test the Volt fader plug in in Logic but i can not get it to work with automation...
if anyone can figure it out and they want to run a test or tell me how to get it working that would be great...thanks
(i did read the manual but honestly i am lost when it comes to MIDI and such things...)
i try and automate it in Logic like any other plug-in but Volt does not respond, it stays at unity gain...
in not so many words, the manufacturers claim that Volt is "the shit" for automations and fades so i am very curious...

"... people who actually tried Volt were saying things like "wow! that is the smoothest fade i've ever heard..."
(they must have been Logic users..)

Volt Precision Fader :: cerberus audio

edit: also, if anyone has any insight as to what is going on with the Cubase fades that would be good to know...
i attached a pic of the beginning of the fade from post #135...

[Muser]

I won't be able to run volt.

that cubase fade looks wonderful. it looks like it's having a party at sample rate.

[Aiyn Zahav]

Sorry to be an idiot, can we have a summary here?

Are we saying something like: DAW automation is inaccurate OR DAW automation may not always deliver the results you think it will

I have a few automation problems in Studio One 2.5, for example:

If I automate a MUTE, lets say to mute a kick drum at the last bar in an 8 bar loop, when the mute is removed I lose the transient of the first kick in the following bar

For this reason I prefer to simply automate the volume, however if I can sharp curves such as resemble a square wave I encounter the same problem, so I have to draw in a ramp, which unless I am careful can still cause problems.

Perhaps I'll post this on Presonus, but I hate to have to provide audio examples, I wish developers would consider this their job and I not have to spend my time demonstrating it.

[UnderTow]

Originally Posted by Aiyn Zahav

Sorry to be an idiot, can we have a summary here?

Are we saying something like: DAW automation is inaccurate OR DAW automation may not always deliver the results you think it will

I have a few automation problems in Studio One 2.5, for example:

If I automate a MUTE, lets say to mute a kick drum at the last bar in an 8 bar loop, when the mute is removed I lose the transient of the first kick in the following bar

For this reason I prefer to simply automate the volume, however if I can sharp curves such as resemble a square wave I encounter the same problem, so I have to draw in a ramp, which unless I am careful can still cause problems.

Perhaps I'll post this on Presonus, but I hate to have to provide audio examples, I wish developers would consider this their job and I not have to spend my time demonstrating it.

Personally I never use mute automation in any DAW. I select the clip (cut at the right place if needed) and mute the clip. For me that is a much faster workflow and gives a very clear visual indicator that something is muted.

It also means I can quickly mute and unmute tracks while producing/mixing without having to worry about any automation.

Not exactly an answer to your question but it might help.

Alistair

[Muser]

Originally Posted by Aiyn Zahav

Perhaps I'll post this on Presonus, but I hate to have to provide audio examples, I wish developers would consider this their job and I not have to spend my time demonstrating it.

sadly if you don't do it, no one else will.

not sure about your mute event issue.

with PDC plug-in delay compensation, real time muting has been relegated to being a lost proposition. muting is a fast and creative way of trialling a new quasi arrangement. it makes me want to use a desk again. DAW's have this special way of killing spontaneity. I guess a pluggin that simply mutes, might be handy.

in any case, I'm not sure why (if you say you removed a mute event) some odd muting artifact is still remaining.. off hand I would say that possibly something is wrong with the plug-in delay compensation scheme routines.

say this is a Block of your Audio.

Track ---> (AUDIO PART)

if PDC has move everything earlier you won't generally see it earlier on the arrange page. the problem with that is, what you see in graphics is not actually where it IS. so if you cut the part on the time line, the cut might not actually be where you though it was. because the PDC is not correlating with the visual representation position on the screen part.

so if you were to make a bar accurate cut on a kick drum and delete a bit of the Audio before the kick, you can lose the start of the Kick. even though you still see it.

so if you thought you cut here.
Track ---> (AUDIO PART)
--------------I

you might have actually cut here
Track ---> (AUDIO PART)
---------------------I

This is another one of the joys of latency. you can't use mutes easily live, and you can't always cut your audio in any visually intelligible way. of course this depends on the software interface design. they also need a Graphics User Interface compensation scheme implemented as well, to account for this I guess.

Software need to do this as well as make a secondary mute so automation mutes can be over-ridden by a secondary mute and also be able to be over-ridden in solo completely.

personally I would like a bleed level as well. so when the main levels are at zero, they aren't actually at zero. so you can set the level of bleed through. but that's another matter I guess.

This thread is about how fine grain the level automation is in DAWs.
or more to the point, how not fine grained enough they might be.

[UnderTow]

Originally Posted by Muser

sadly if you don't do it, no one else will.

not sure about your mute event issue.

with PDC plug-in delay compensation, real time muting has been relegated to being a lost proposition. muting is a fast and creative way of trialling a new quasi arrangement. it makes me want to use a desk again. DAW's have this special way of killing spontaneity. I guess a pluggin that simply mutes, might be handy.

in any case, I'm not sure why (if you say you removed a mute event) some odd muting artifact is still remaining.. off hand I would say that possibly something is wrong with the plug-in delay compensation scheme routines.

say this is a Block of your Audio.

Track ---> (AUDIO PART)

if PDC has move everything earlier you won't generally see it earlier on the arrange page. the problem with that is, what you see in graphics is not actually where it IS. so if you cut the part on the time line, the cut might not actually be where you though it was. because the PDC is not correlating with the visual representation position on the screen part.

so if you were to make a bar accurate cut on a kick drum and delete a bit of the Audio before the kick, you can lose the start of the Kick. even though you still see it.

so if you thought you cut here.
Track ---> (AUDIO PART)
--------------I

you might have actually cut here
Track ---> (AUDIO PART)
---------------------I

This is another one of the joys of latency. you can't use mutes easily live, and you can't always cut your audio in any visually intelligible way. of course this depends on the software interface design. they also need a Graphics User Interface compensation scheme implemented as well, to account for this I guess.

This isn't usually how PDC works. If the audio is in sync, all the edits and cuts are in sync too and what you see visually is in sync with the rest. (How could it be any different?) The same applies to automation.

It is actually good that the tracks are not moved visually. That would mean it would be impossible to align things by eye. If one track, say the snare drum, has a heavy plugin with heavy latency it would be impossible to align it with the kick drum as it would visually be ahead of the kick drum when they are actually playing at the same time. That would be a very bad idea. If the kick and snare are playing at the same time, they should visually be at the same time regardless of the PDC. That is how every DAW I have worked on behaves.

You are right about live muting though. If there is a significant amount of PDC being applied by the mix engine, what you hear is not in sync with the "play head". Any live automation will be late by the amount of PDC (and possibly the audio interface latency too).

But I haven't worked with Studio One so maybe it is broken...

Alistair

[Muser]

Originally Posted by UnderTow

But I haven't worked with Studio One so maybe it is broken...

Alistair

I have encountered this GUI issue in Logic. ideally it should do as you say but I'm not sure it always does. I've had a kick transient disappear for exactly these reasons. I could see the transient but It was not sounding. I think Valis has noticed similar happenings as well. also maybe in other apps.

[valis]

I've had it happen in the past but imo it's due to plugins not handling the hybrid buffer properly and I've not seen it in a while. There were some issues with plugins not handling switching in & out of the hybrid buffer properly, and others just didn't properly report latencies.

The SPL (playhead) position being 'not with the audio you're hearing' issue is also common to DAWs but in the case of Logic the hybrid engine's processing buffer size again makes PDC latencies 'stack up' much more than in other apps.

Also when I want *truly* sample accurate automation in Logic I always set more than 1 point surrounding the area where the transition occurs. For instance if I automate a mute, you'll see only 2 datapoints representing the 'unmuted' and 'muted' state. 1 per 'state'. If I double up these points it (imo) forces the automation to calculate a more accurate position. This makes sense to me because I use a lot of graphics applications, 3d applications, video applications & audio apps that implement various forms of b-spline or nurbs curve for the timeline (and within the app). I know in other applications to properly calculate a RAMP or b-spline you actually need a minimum of 3 points, and to handle NURBS you need 4. So imo in Logic's timeline if you rely on points 'very far away' and just 1 point 'per state' where you want to automate a fast transition, Logic's "interpolated" result on your audio may not be what you expect. Set 2 additional points manually and things become more predictable.

I've had this workflow since 5.x introduced 'plugin automation' (versus hyperdata/object based automation), and you'll note that in modern versions of Logic many of Logic's own editing functions now create 2 points per edit point as well.

[UnderTow]

Ah it is possible that Logic behaves differently than the DAWs I use regularly. I haven't used Logic in years...

Alistair

[valis]

Last time I checked Cubase it had linear splines for its plugin automation display. Even with the new automation curve & triangle etc tools in Studio one, it still appears to use these functions to create linear splines as well (I have v1 only so not sure here).

Logic *appears* to be linear until you encounter some of the oddities I mentioned, or start using the curve tool. It's possible to define different segments of a curve with a different order: linear here with only 2 points, bezier there with 3 but I have no idea if Logic does this. It doesn't *seem* to, by the type of bezier curve you get with the curve tool (when you make the 'S' style curve) I'd say that you have 2 'control' points and 2 points on the curve by default. It just moves both control points together in relation to the mouse movements and they are 'not visible', but otherwise the behavior is 100% the same as if I used Illustrator, Maya, Softimage or any other tool with a Bezier curve type and selected the 2 control points and 'scaled / rotated' them together as one around the center of that curve segment.

Live 9 has a curve tool but I'm not really sure what's it's doing tbh.

In any case it's not so much that "logic does something different" as each application has potential to do something different, it's entirely up to the implementation the devs choose. It's also worth noting that the automation hasn't changed much since v5, long before Logic had samplerate as its timebase in arrange and before automation was sample accurate as well. Often two points at the start of the automation (one to 'prime' the calculation of the automation event by making it more precise interpolating off the following point) followed by two points at the other 'side' or state seems to be much more...predictable to me. That was the case in v5 & v6, so I developed habit of setting double points to define a transition better improved timing of automation. It still seems to help in some situations for me now.

This is different however to events being 'drastically shifted' in the timeline, I'm referring to the example where the initial transient of a sound may be cut off by mute automation specifically. If i were to try to rationalize I would suggest that the mix buffer might be a factor here since

[Aiyn Zahav]

Ah I should clarify, you guys assumed I was working with audio clips but I'm not, all VSTi I rarely work with audio (though if I could it would make things a heck of a lot more predictable)

The other day I actually automated some plug-in bypasses. When I played back I had the first part of the audio dry, then the plug-ins were unbypassed and the signal was wet.

When I exported it consistently totally ignored these changes and the sound remained dry!

What PIA honestly.