Hmmm ... we might have a misunderstanding, here.
I was not talking about Gain adjustement, but about Gain Reduction ....
as I just wrote, my problem seems to be caused by the Link parameter.
Regarding Fluffy, Aleksey said :
"Fluffy mode is simply a 'square of the gain' mode. If you have 3dB of gain in the non-fluffy mode, you'll have 6dB in fluffy."
... err ... wouldn't that be 9db than ...
About the colours:
I tried designing a new envelope editing area which is dark but with colour coded envelope lines to match coloured buttons underneath. I've sent this idea to Aleksey. If you don't like a dark background you won't like my idea but I think it's clearer. It could go the opposite way and be very light but an in between shade will make it more difficult to see things in my opinion.
Andrew, I'm sorry, but remembering the shape all the time is not a realistic approach for me. This is not a graphic design program.
Jan, I'm on TFT, too, and I don't really see much problem with the new darker envelope field. I'll try to find both better 'overlay env' colour and make in/out spectrums more in contrast to each other.
Yes, I've returned the resolution to the linear scale. I've had to do this, because Soniformer should interpolate values for intermediate bands. Linear scale interpolation is better for both Attack and Release envelopes. You may hold the ALT key to have 10x more precision. If you have some ideas please write these here.
Fluffy is exactly 'power of 2' gain in linear volume scale. In dB scale the gain value is doubled.
Ryan, I've checked your design, but I don't think I can implement it. Having several envelopes at once is not an approach I wish to see in Soniformer. It's just too clumpy.
Well, I think I can get used to the dark background. I would prefer the bright one, but that's a matter of taste
( and contrast, of course ... )
I wouldn't have a problem with a log. interpolation of Attack / Release.
( ... don't know if it's a problem to code, or consumes more CPU, though )
Maybe You can add a switch.
Will try the alt modifier, but the problem is also about 'seeing the values'.
About CPU usage:
- As the Link function still has effect, when Soniformer is used on a mono track, I guess Soniformer still processes both channels.
Wouldn't a plain mono versions, cut down the CPU usage ??
- Is it really true, that Soniformer works without any delay ( Cubase shows : 0 Samples ), i.e. realtime ??
As Soniformer would probably never be used as an input FX, wouldn't a slight latency reduce CPU load ??
Soniformer is able to work in a mono-to-stereo configuration, so that stereo linking does not consume CPU at all.
Yes, Soniformer is a zero-latency effect, but an increased latency won't add any CPU efficiency. 32 band processing Soniformer has is the same as having 32 channel compressors, each with a pretty advanced functionality PLUS 32 band-splitting filters.
Log.interpolation does not add any CPU load... OK, I'll rethink my approach, possibly log.scale is even more correct.
Thanks Aleksey ... much appreciated !
Regarding Stereo/Mono processing :
If Soniformer would switch to a 'process left channel only' mode on a mono track, wouldn't that save some CPU cycles ???
The 32 channel Compressor design, brings up an idea ( probably for Soniformer 3.x ) :
I know the inital idea of Soniformer is to interpolate between control points.
But, with the new 2.x design, it would be easy, to implement a '32 sliders' UI, alternatively.
The rest would stay the same. I.e.: there are still all parameter switches, but each one would be controlled by 32 sliders.
The sliders would not need a fader handle. The existing Gain bars would be sufficient.
The actual reduction could be overlayed in a different colour ... or splitted like the combined In+Out display.
What do you think ...
I'm liking SF 2.0f so far this morning. I just used the 'Gains' monitoring for the first time and that is very cool for determing dynamic gain chances - 100% improvemnet over the 'color dynamics' indicators of Soniformer 1 !
For the log interpolation vs log scale issue - I'm wondering if a switch might be in order - it's costing a few cpu cycles already on my P4 2.6GHz (not surprising for what you get though) and if the degree of quality improvement is somewhat subtle I could switch log-scale mode on during rendering.
I am thinking that the dynamic gain reduction (ratio=compression) and gain increase (ratio=expander) real time spectrums are a little over-enthusiastic however. I am able to 'notch' a fairly narrow band successfully according to the scope I'm using (using pink noise to test) but the amount of compression gain reduction or expander gain increase is not what Soniformer2 spectrum indicates. Upward expansion is about right when in 'Fluffy' mode but the Compression gain reduction is way off. BTW I just have Soniformer2 followed by Ozone3 uisng its full scale resolution scope.
PS I forgot to mention: The test is simply to start Soniformer2, create a 1/3 octave notch at the 95Hz band and the 1K band (actually sweep the notch) and drag the ratio bar from max compression to max expansion. Pretty extreme maybe in real life - more like what a de-esser might do.
BTW when I open the notch up to about 1 octave (3 bands) then the spectrum more or less indicates the correct gain reduction or increase I see on the Ozone3 scope - to be fair most multiband compressors (I have) act this way (don't compress a narrow band range as much as you think) on extreme narrow settings, I guess I'm just pointing out that Soniformer2 spectrum can be misleading when using extreme settings.
Jan, mono-to-stereo processing should be engaged by the host itself. At least, Soniformer supports this VST feature. Your idea about sliders is not what I actually would like to implement. Sliders are OK for equalizers, but when you have to tweak several parameters sliders become a burden.
Kyle, you are right with your observations. I'll try to get more precise spectrums.
This topic was last updated 180 days ago, and thus it was archived. Replying is disabled for this topic.