Login

Transient loss

Tips & tricks, working results, technical support

Re: Transient loss

Postby Tim Petherick » Thu Nov 21, 2013 11:21 am

Masr wrote:I just checked the default settings of AlexB consoles and I was surprised to see him using only "classic - Freqd" mode (all the arrows pointing to the left). Is it possible that he would choose the worst setting for all his consoles, skipping the whole timed engine? The same applies to STN Tapes... :o



This is a default setting not nesserily a dev setting.

It's so the engine can use smooth. You can't use smooth in split mode. So you have a choice to go high CPU timed mode or low CPU freqd player when using smooth. Or no smooth in split mode. Each has pros and cons...

Sometimes smooth can be worse in artifacts depending on what your trying to get the preset to do
User avatar
Tim Petherick
Expert
Expert
 
Posts: 1351
Joined: Sat Apr 17, 2010 4:07 pm
Location: Bath , Uk

Re: Transient loss

Postby yr » Thu Nov 21, 2013 11:26 am

Masr wrote:I just checked the default settings of AlexB consoles and I was surprised to see him using only "classic - Freqd" mode (all the arrows pointing to the left). Is it possible that he would choose the worst setting for all his consoles, skipping the whole timed engine? The same applies to STN Tapes... :o


My guess is that some developers feel it's the best compromise between sound/performance. The timed mode is very CPU intensive, so if you are working @96khz, for instance, you may have a serious problem running a full console emulation that way.
Reuven | post-production & sound-design | scenography |
website | nebula presets
User avatar
yr
Beta Tester
Beta Tester
 
Posts: 438
Joined: Mon Mar 29, 2010 9:04 am
Location: Amsterdam

Re: Transient loss

Postby nonstandardryder » Tue Dec 09, 2014 6:30 am

Well it's been over 1 year since this thread ended. Have there been any updates or findings? I would love to hear them.

I am looking to offline render a ton of projects using console presets for Dance/House music and would like to do my best to keep my transients in place.

Any thoughts on RMS17 vs PEAK?

Also would changing the attack/release times help preserve transients on console programs?
nonstandardryder
Member
Member
 
Posts: 201
Joined: Sat Apr 24, 2010 5:23 am

Re: Transient loss

Postby kels » Tue Dec 09, 2014 8:08 am

it's a nice idea to bring back into practice this thread.
for offline rendering, i always use tweaked programs as transients are well kept in time mode. For console, I like RMS17. EVf17 is like a clean plate of glass and can sound precompressed but can be useful for console too. For compressors, I like PEAK most of the time. The idea behind rendering a massive amount of tracks with programs on time mode is to keep the initial transients in place which freqd bury most of the time. In fact, I just can't use freqd anymore (just for previewing).

Tim Petherick is the one to ask about "transients keeping". All his programs (well, I don't own all of them so I cannot generalize) are built around this approach.
kels
User Level XI
User Level XI
 
Posts: 166
Joined: Fri Oct 11, 2013 8:43 am

Re: Transient loss

Postby nonstandardryder » Tue Dec 09, 2014 9:09 pm

kels wrote:it's a nice idea to bring back into practice this thread.
for offline rendering, i always use tweaked programs as transients are well kept in time mode. For console, I like RMS17. EVf17 is like a clean plate of glass and can sound precompressed but can be useful for console too. For compressors, I like PEAK most of the time. The idea behind rendering a massive amount of tracks with programs on time mode is to keep the initial transients in place which freqd bury most of the time. In fact, I just can't use freqd anymore (just for previewing).

Tim Petherick is the one to ask about "transients keeping". All his programs (well, I don't own all of them so I cannot generalize) are built around this approach.


My findings so far for offline render. This applies only to Console Programs/AlexB

Always timed mode at 50ms or higher for clean,even,odd.

I actually don't like RMS17 for transients. I found the same as you did EVF17 is great. It sounds right in the middle of evf and peak. I find Peak keeps transients the best, and EVF has this cool "very lightly compressed" deep sound which I like. I also find (believe it or not) the "off" setting works well just for color and a touch of glue.

I also wonder if the new fast compressor technology could help in keeping transients with console presets.
nonstandardryder
Member
Member
 
Posts: 201
Joined: Sat Apr 24, 2010 5:23 am

Re: Transient loss

Postby giancarlo » Tue Dec 09, 2014 10:01 pm

we are fixing an awful lot of bugs... wait for next release
User avatar
giancarlo
Founder
Founder
 
Posts: 9182
Joined: Mon Sep 21, 2009 10:40 pm
Location: Italy

Re: Transient loss

Postby nonstandardryder » Tue Dec 09, 2014 10:02 pm

giancarlo wrote:we are fixing an awful lot of bugs... wait for next release


Will do! Thanks :)
nonstandardryder
Member
Member
 
Posts: 201
Joined: Sat Apr 24, 2010 5:23 am

Re: Transient loss

Postby kels » Wed Dec 10, 2014 8:37 am

My findings so far for offline render. This applies only to Console Programs/AlexB

Always timed mode at 50ms or higher for clean,even,odd.

I actually don't like RMS17 for transients. I found the same as you did EVF17 is great. It sounds right in the middle of evf and peak. I find Peak keeps transients the best, and EVF has this cool "very lightly compressed" deep sound which I like. I also find (believe it or not) the "off" setting works well just for color and a touch of glue.

I also wonder if the new fast compressor technology could help in keeping transients with console presets.


nice to see we have similar conclusions. Also, it's a pain that program rate modify itself when we switch kernels to time and that we have to put original value back in.

we are fixing an awful lot of bugs... wait for next release


I'm curious here as EVf17 is already a debugged version of RMS17 as I can read a few pages back. Or should that mean that frequd will be able to keep transients perfectly ?

ok, I'll wait. :)
kels
User Level XI
User Level XI
 
Posts: 166
Joined: Fri Oct 11, 2013 8:43 am

Re: Transient loss

Postby kindafishy » Wed Dec 10, 2014 3:53 pm

This is kind of interesting, but personally, I don't see why anyone would tweak any settings at all unless recommended specifically by the developer of the library.

The way they are programmed is the way they prepared them when they sampled them. Why would a user be able to make them sound better than the developer who created them?

Assuming that the developer created the libraries to sound as close as possible to the hardware, how would a user (who very likely doesn't have the actual hardware beside them to A/B) make improvements?

I have read about all the Nebula modifications, but I am extremely skeptical that they do anything positive at all to any programs.
kindafishy
Vip Member
Vip Member
 
Posts: 424
Joined: Tue Mar 22, 2011 2:08 pm

Re: Transient loss

Postby kels » Wed Dec 10, 2014 5:04 pm

To me, there are 2 points.
The first one is not trying to make those programs sound better at all cost, but to avoid the transient loss induced by the algorythm called freqd. A dev can't do anything about that, except going to time mode. And most of them are reluctant to do that, because it is so much cpu intensive.

The second one, indeed, is to try different algorythms (EVF17 for ex) that have been improved over time or debugged. They may actually sound better but inevitably, you can end up with something different than the hardware.

I try to never forget that my customers are here for the sound I can give them and if one library doesn't give me what I want, I don't hesitate more than a second to modify it.

Nebula is a tool and, thanks G, is not locked like every products on the market.
kels
User Level XI
User Level XI
 
Posts: 166
Joined: Fri Oct 11, 2013 8:43 am

PreviousNext

Return to Working with Nebula

Who is online

Users browsing this forum: No registered users and 10 guests