Sonar 5 has arrived...

[Forever Sun]

Brandon(Cakewalk) quote:
"Clip based effects and envelopes with full PDC. Again, quite useful. "

Are these clip based effects active only when the clip plays ( like in Samplitude) ??

If they are not, then the whole FX per clip would be useless due to CPU usage. I wouldn't want to have lots of clips with chains of FX clogging up the CPU. Freezing each in turn would also be a logistical nightmare. So...?

They work like effects on tracks. Properly implemented DX and VST effects should use less CPU when dormant than when audio is passing through them so CPU usage should be no higher and conceivable lower.

However, there is another important point to the clip FX. If you have a multi-lane track with say vocal takes. And you don't want to apply a delay or distortion for example to all clips (using the FX bin) then clip based effects are very useful because you can just apply that effect to the clip of choice and not the entire track. Not to mention you can draw effect clip automation and this automation (as well as the plug) will go wherever the clip goes allowing you freedom of arranging without having to worry about the effects and/or their automation. HTH

So Cakewalk has missed an opportunity. 'FX per Clip' should really be active when the clip plays only!


Even with those "properly implemented DX and VST effects", as you say, doing what you describe in the second paragraph, is going to cause CPU overload, at least in a full project with plenty of audio and VSTi stuff !

Imagine I have many of these tracks each with a few clips with effects...

If you implement a feature, why not do it properply ?
This 'FX per clip' is currently a half-baked idea.

[whyterabbyt]

That's one thing I don't quite get - why wait until version 5 before adding native support for VSTs?

I'm sure there is some reason that must have been discussed at length on the forums here in the past though.

Because the entire audio engine was developed around an internal standard which wasnt VST (just like FL, Orion, ProTools and just about everything else that ever came with its own non-VST plugins).

By the way, most hosts which have their own plugins, or support multiple plugin types, actually use 'internal' wrappers anyways. Sonar just happened to utilise an external wrapper. Now, with S5, it would appear to incorporate an internal wrapper. Woot. The major difference? Hopefully it'll eliminate whining from the people who say 'but I hate having an external wrapper'.

[whyterabbyt]

The thing is that dx was going to be the "next big thing" but stienborg's vst/i's have won out in the real world.

No, it was hoped to be a unified, MS-supported, non-proprietry standard. At the time, Steinberg controlled the VST standard, and they changed it constantly. There was also no such thing as a reference host implementation. DXi was an attempt to

They did the wrapper thing to try and "patch" and appease, now they have announced native.

They did it because their customers wanted it, and people who werent customers bitched about it being a 'flaw'. Cakewalk listen, and respond to that kind of thing.
Of course, some people will complain about them doing it, or not having done it soon enough, or how what they did before didnt suit them, but, really, folk like that are never going to be happy, are they? They have more fun bitching.

Dx is not a good format imho, I have had terrible problems with it vs vst's.........vst's are not perfect but it's the "popular" format.

I think a lot of DXi implementations sucked. That doesnt mean DXi itself did. A lot of VST implementations sucked when Sonar actually came out. And meanwhile Steinberg's VSTs continued to rely on subtle changes to Cubase and the supposed 'standard' for years.

[whyterabbyt]

Well, I don't know if it is from "sratch" or not......but I am suspicious. The reason is that sonar was never it's own animal, it's an update of cakewalk pro......which had several versions.

This is speculation unless someone has the code and knows with certanty.

Indeed it is speculation. Doesnt seem to stop you running with that though.

Even if you love sonar, let's face it.........their vst wrappers sucked wang and we'll have to see if native means native or if it's another coat of paint.......

The VST wrapper has worked on my system prefectly well for several years, with hundreds of plugins. The only plugins that ever caused problems were Steinberg plugins, which were usually because they'd been written to a slightly 'altered' API behaviour from that generally accepted.

It's the bucks that get me down on sonar. Why? because instead of getting a kick butt program when I paid 500 bucks for pe3, I got a terd.

I needed 50 bucks for the "real" version of vsampler

No you didnt. The supplied version worked fine within Sonar.

then another 50 for dxier, then that didn't work and support stoped

How is that a fault with Sonar?

and then it's "hey, kick another 180 to upgrade to 4".........

That wasnt mandatory either. Upgrades never are. Unless you have to get them merely because your OS version changed.

that's more money than I've spent on protools/bfd//vst/rtas adaptor...........and that stuff is more usable..

Oh so you're happy to buy a wrapper for RTAS but not DX. Why? Both were developed by the same company.

And dont you pay for ProTools updates? Or have you just not bought any?
We have to, and they're not that cheap. £45 UK for a minor revision, with no instruments, and no major features, and you've got to buy it just because you upgraded to the latest version of OSX? Hah. Not that much of a bargain.
Especially when you have to pay £600 just to get timecode support.

But hey, nobody made you pay for upgrades, so it was up to you to spend, or not spend, that money. So complaining about it being 'expensive' compared to some arbitrary other thing you spent money on is just bollocks.

I see more complaints/bugs with sonar (and cubase, to be fair) than anything else.

Most of the complaints I see seem to come from people who dont actually use it, or havent used a recent version. And they mostlky complain about features which are purely workflow issues, most often. Most of the stuff people dont like gets changed, but they still bitcvh about that stuff, long after its been changed or removed, or replaced. Funny that.
And most of the bugs get fixed.

But of course, it much more fun to sit in a thread about the new version of a program you dont own, and bitch about it endlessly, than just go 'hey well, I got a solution that suits me fine, so what the hell', isnt it.

[whyterabbyt]

So Cakewalk has missed an opportunity. 'FX per Clip' should really be active when the clip plays only!

Im pretty sure that would give their PDC solution problems. Since they've spent a lot of time and effort addressing complaints about gapping in their audio engine, a major problem for a fully-PDC'd implementation, I'd guess they probably dont want to dump a whole load more issues into the fray until the engine is validated.

Even with those "properly implemented DX and VST effects", as you say, doing what you describe in the second paragraph, is going to cause CPU overload, at least in a full project with plenty of audio and VSTi stuff !

All sorts of things can cause that anyways, like just plain old using too many effects. At least we now have new, useful options, and still have a damn good Freeze solution. Oh yeah, and much faster processors than last year.

Imagine I have many of these tracks each with a few clips with effects...

Imagine having many single tracks without such clips, but tons of effects... same issue.

If you implement a feature, why not do it properply ?
This 'FX per clip' is currently a half-baked idea.

No, it just doesnt suit your idea of how it should have been done. Would you have preferred them not to do it all, then?

[Forever Sun]

No, it just doesnt suit your idea of how it should have been done. Would you have preferred them not to do it all, then?

Respectfully disagree, Whyterabbyt.

Firstly, this feature is already implemented in several other programs. There, FX on clips are only active when the clip plays. Hence this is an estabilished idea/feature. Now, we have Cakewalk introducing it to Sonar and they implement it in an opposite way to the estabilished trends.

So what is happening now you have people reading the spec and assuming that this feature will adhere to the current trend/standard, as set by Samplitude and Traction. OK I know these programs are not as famous/estabilished as Cubase, Logic or Sonar, hence thay can't surely set a standard ( one could argue), but if they bring a feature which greatly aids the workflow and CPU consumption, then why on earth another company introduces the same feature but without these benefits ? Thats the problem here. Oversight.
Or, as you have mentioned, the PDC problem that would have resulted.

It's just a shame. I love Sonar, but can't stand wasted ideas.

Quote:
Imagine I have many of these tracks each with a few clips with effects...
-------------------------------------------------

Imagine having many single tracks without such clips, but tons of effects... same issue.

Imagine CPU saving FX on clips...we can go in circles, but just imagine this feature developed to to its logical conclusion: FX on clips active when clip plays.

[cptgone]

Currently in Sonar, if you load a dxi synth, say Atmosphere, you get an audio track and a midi track. So you start playing. The midi track “records” the midi info. The audio track does not load audio data. That track does not even have a Record button. You can load effects into that track that will be added when you bounce down, but you can’t actually record audio data using a dxi synth in real-time. Am I right so far?
It would be nice to be able to do that in order to use some of the midi-uncontrollable controls in a given synth.
For example, say you load a Reaktor-5 synth and begin playing. Meanwhile, you slide the morph control gradually between two patches. You would like to record the transition in real-time, but when you bounce to track, you receive whatever is the final position of that control. Am I missing something here?

You can do that with Voxengo Recorder.

[whyterabbyt]

Respectfully disagree, Whyterabbyt.

FAir enough

Firstly, this feature is already implemented in several other programs. There, FX on clips are only active when the clip plays. Hence this is an estabilished idea/feature. Now, we have Cakewalk introducing it to Sonar and they implement it in an opposite way to the estabilished trends.

Not really 'opposite', IMO.

So what is happening now you have people reading the spec and assuming that this feature will adhere to the current trend/standard, as set by Samplitude and Traction.

Not being aware of any 'standard' (or in fact any existing implementations), I can't comment on that, but I think its a stretch to assume that all features will be implemented the same way on all hosts. I mean, at what point does this become a 'de facto' expectation? Is it possible Cakewalk's implementation was already planned and implemented by the time people started assuming that there was a de facto way of doing things?
Also, I dont believe Traction implements full all-tracks all-buses PDC yet, does it? Does Samplitude?

OK I know these programs are not as famous/estabilished as Cubase, Logic or Sonar, hence thay can't surely set a standard ( one could argue), but if they bring a feature which greatly aids the workflow and CPU consumption, then why on earth another company introduces the same feature but without these benefits ?

Parallel ideas, different implementations, and the constraints of other factors in the audio engine combined with when these ideas are planned and implementation starts in one host's development cycle compared to when they are actually implemented 'in the wild' in another?

Thats the problem here. Oversight.
Or, as you have mentioned, the PDC problem that would have resulted.

It's just a shame. I love Sonar, but can't stand wasted ideas.

I agree with you that it would be 'ideal' to have it done on an on-demand basis, but I dont think it 'spoils' having that feature in at all.

And to be honest I wonder if people would have more issues with an unpredictable CPU usage which varied depending on the number of active clips. Do you know which tracks/clips to freeze to ensure your CPU doesnt top out? Aren't you wasting time if you guess the wrong one/ones and it still tops out?

Anyways, I find it a neat feature as is. If its improved in time, that'll be better still...

[stag]

offline processing is broken on Sonar5 then... what a pitty...

[whyterabbyt]

offline processing is broken on Sonar5 then... what a pitty...

What are you talking about? How do you come to that assumption about an unreleased application?

[christianmusicmaker]

offline processing is broken on Sonar5 then... what a pitty...

Eh?

[cptgone]

'FX per Clip' should really be active when the clip plays only!

Indeed. I'll have to stick with Cubase SX then.

[Forever Sun]

And to be honest I wonder if people would have more issues with an unpredictable CPU usage which varied depending on the number of active clips. Do you know which tracks/clips to freeze to ensure your CPU doesnt top out? Aren't you wasting time if you guess the wrong one/ones and it still tops out?

....

Now, that's an important issue you've raised, one I've overlooked. You are right, it would ba rather unpredictable.

However, this problem could've been solved like this:
each time an FX is inserted onto a clip, Sonar measures the CPU usage of that plug-in in that clip( somehow, I'm not a programmer...but it should be possible ?) This happens in a micro second, so no time is wasted waiting for this. Then I can look at the estimated CPU usege in an additional (new) CPU meter which deals with estimating CPU for plug-ins inserted on clips.

I know I'm describing a fanciful idea here, but maybe it could work and no one would experience the unpredictable CPU hikes, as it would be always displayed in the meter, and I would now when the CPU is exceeded.

[Forever Sun]

'FX per Clip' should really be active when the clip plays only!

Indeed. I'll have to stick with Cubase SX then.

So does Cubase work like Samplitude, Traction then,?
It appears that IT IS a standard then ? Three major PC apps have it. Sonar chose to ignore it. Hmmm.

[kp]

But play back any projec with plug-ins anyway and the CPU usage fluctuates, so do you take the low value, the high value or an average value? It's a neat idea you've proposed, but not sure it's practical.