trim automation not out of sync

[amoretam]

Yes very strange indeed...
I draw automation to the trim plugin GAIN, but the automation happens before the playhead gets to the actual automation in the automation lane..

Meaning that I hear the automation happening before the actual automation written on the lane...

know what i mean?

how is that for strange??

Anybody had this issue ??

Thanks

EDIT: it happens in every track and just with the trim plugin, I do the same with track VOLUME and is fine

[amoretam]

no one?

[jasonthurley]

Just curios but why are you automating the Input Trim? The purpose (the only way I have used it for years) is to bring up or down the automated volume without recording the automation again (by raising the input trim up or down to what you needs are..)

The only other reason I use it is to bring the 32bit float engine down to not clip my master fader (my sessions are at 24 bit so sometimes my mix is above the ceiling and instead of using the input trim to lower all the tracks I just lower the master bus trim....)

Automation is meant to be written in the volume view or for midi and VI its called audio volume.... Ive never had to or wanted to automate the trim

So to answer your question, no Ive not ever seen that because I would never automate the input trim... just raise or lower the entire thing (meaning no volume nodes/dots adjusting it through the session)

Do you have delay compensation enabled? If you do If you turn it off does it visually look right?

[amoretam]

Originally Posted by jasonthurley

Just curios but why are you automating the Input Trim? The purpose (the only way I have used it for years) is to bring up or down the automated volume without recording the automation again (by raising the input trim up or down to what you needs are..)

The only other reason I use it is to bring the 32bit float engine down to not clip my master fader (my sessions are at 24 bit so sometimes my mix is above the ceiling and instead of using the input trim to lower all the tracks I just lower the master bus trim....)

Automation is meant to be written in the volume view or for midi and VI its called audio volume.... Ive never had to or wanted to automate the trim

So to answer your question, no Ive not ever seen that because I would never automate the input trim... just raise or lower the entire thing (meaning no volume nodes/dots adjusting it through the session)

Do you have delay compensation enabled? If you do If you turn it off does it visually look right?

hello, I use trim gain to automate track volume rides....I use it pre inserts, and another one post inserts for triming when necessary...I dont like using track fader cause I like it to be free ... it is just my workflow...

I have delay compensation enabled... I will see if turning it off will make it look right... I dont see why pdc would cause that tough, it does not make any sense to me....

Thanks

[jasonthurley]

To each their own... thats what I use clip gain for.... Still have yet to reproduce this...

[amoretam]

Originally Posted by jasonthurley

To each their own... thats what I use clip gain for.... Still have yet to reproduce this...

i have no clip gain in pt 9.... this still hasnt been solved
thanks

[jasonthurley]

Clip gain is a plug in in all versions of pro tools... Plugins.. Other... Gain

All "Clip Gain" in PT 10 does is the same thing but process that is real time instead of changing the waveform... It takes me just as long to throw 2 nodes on the trim data line than it does to select the waveform and gain it up or down... plus this way will alleviate any "extra" processing you are making the engine do with automation nodes.... just my point of view, if it works cool... that's why Pro Tools is my favorite.. there are many ways to do the same thing.

Still cant reproduce this on my system on PT 9 or 10

[amoretam]

Originally Posted by jasonthurley

Clip gain is a plug in in all versions of pro tools... Plugins.. Other... Gain

All "Clip Gain" in PT 10 does is the same thing but process that is real time instead of changing the waveform... It takes me just as long to throw 2 nodes on the trim data line than it does to select the waveform and gain it up or down... plus this way will alleviate any "extra" processing you are making the engine do with automation nodes.... just my point of view, if it works cool... that's why Pro Tools is my favorite.. there are many ways to do the same thing.

Still cant reproduce this on my system on PT 9 or 10

ok, then i believe clip gain plugin , would be the same as trim plugin ,... isnt it??
you have to go to the gain or trim gain lane and adjust your automation there...
and it all depends on where you place it in the track rack
no difference, correct me if i am wrong

[jasonthurley]

True, but what I added is that using automation nodes adds processing... when you use the gain plug you no longer have the engine automating multiple trims (meaning more nodes to process ontop of your session/plugins in real time....

So if you automation nodes are not acting in real time, I would simply stop using them and process the wave instead.. you can even setup a quick key to open the gain plug for processing, simple undo quickey if your not happy with the results and reprocess with a different setting.

So yes its essentially the same thing but your having to process it differently by using automation in real time.... from what I have heard PT will drop automation data to prevent from having an error... If you understand what that means in terms of using automation when you need it versus not using it if you dont need to (ie, clip gain). Although the computers these days should have no problem with this I assume if you have nodes on input trim, nodes on output trim, nodes on the volume, nodes on the pan, etc and then you have a lot of tracks it adds up....

I will try to replicate the issue on my home rigs which are not HD systems

[jasonthurley]

The difference between the trim plug and gain plug has been described in other threads as reducing the source/quantization error ratio when gaining down... as it is processed at 32 bit floating point but has to be within your bit structures headroom... like 16 bit has less headroom than 24 and 24 less than 32, etc... Trim maintains the original source signal/quantization error ratio, it only scales is down within the 32-bit framework the engine runs at 32 bit so to have a 24 or 16 bit session has less headroom than the 32 bit engine so it lowers this scaling to be within your bit ratio's headroom).