Everything you want to know about Studio One 3.2

[LawrenceF]

The input fx in Reaper isn't that unusual. A few different products have inout channels with fx chains.

Otoh, it's monitor fx is maybe not all that common. Aside from Cubase's control room mixer I'm not sure what other product does that, puts fx between the render stage and the monitors.

[ghettosynth]

The input fx in Reaper isn't that unusual. A few different products have inout channels with fx chains.

By no means was I suggesting that it was. It was simply the first example that popped into my head of having plugins in more than one place in an audio chain. I'm sure that there are other examples.

[LawrenceF]

Ah, ok. I didn't mean to imply that, sorry. Makes sense.

My (still unfufilled) wish is to have fx chains directly on aux sends. Not on the return but on the bus between the source and destination channels.

[ghettosynth]

Ah, ok. I didn't mean to imply that, sorry. Makes sense.

No worries, I'm really just trying to end this line of discussion as it's off topic since that isn't something new in S1 3.2. I posted because I want to hear from users how they are using noise and crosstalk and whether they think that's a good idea.

[LawrenceF]

I'm not a fan of the crosstalk knob personally but it's optional so I mostly leave it off. It does make interesting things happen to a mix though and you know the old sayin... "If it sounds good..."

I do sometimes like what a little noise does to the sound overall, depending on the mix and source material. Like with some other things, just don't overdo it. No different (imo) from running a digital mix through analog gear, which brings a tiny bit of noise with it unless you slam the I/O.

The plugin sound good to me, mmv. It's just another tool in the box. But no, I probably won't be spending much if any time thinking about the crosstalk knob on it.

[RockinMillie]

Input effects not withstanding, the larger discussion is on topic as it revolves around the way Presonus implemented the new feature of Console Shaping in v 3.2

The answer given to the rhetorical question posed by nIGhT-SoN in response to Bungle's comment about implementing it as VST based, demonstrates that from a programming perspective there would be a lot more processing involved to dynamically check which channels are routed to which bus to prevent spinning if it were VST based.

The Presonus approach whilst being proprietary, is more elegant from a programming perspective. The DAW already knows which channels are routed to which bus. From a user perspective it is much simpler and kinder on system resources as it does not require multiple VST instances.
Besides, Presonus are not in the business of developing VSTs, only their hardware, DAW, its stock plugs and add-on extensions.

However, one of the down-sides to the Presonus approach is that it gives the user less control on a per channel basis as woodsdenis correctly points out. Another down-side is that it will require the user to review their gain-staging approach in order to use Console Shaping.
As always in any DSP, there is always a trade-off between cost (CPU / memory usage) and benefit (what it is that one is trying to achieve).

As I stated previously, I am not interested in vintage / analogue emulations, whether it be noise, cross-talk, tape saturation or whatever.

In my opinion, 'vintage / analogue emulation' in DSP is the biggest load of marketing hooey around (seeing as marketing keeps being mentioned). Simply because you will always end up with a digital approximation of whatever analogue artifact is trying to be emulated.
Rather like trying to make water taste like wine. If you want to taste wine, drink wine.

However, where I think Console Shaping could be interesting in the future, is any scenario where one would want a generic effect applied to many channels or indeed all of them, from just one place. For example if one wanted to take the approach of applying a low cut filter (or high cut) at the same frequency for all channels.

[LawrenceF]

you will always end up with a digital approximation of whatever analogue artifact is trying to be emulated

Nothing to do with the subject matter of the thread, this particular plugin, but while that used to be true I'm not so sure it is anymore. Modeling has come leaps and bounds and I do believe it's often demonstrable that digital can successfully model analog sound in some cases, when done correctly. Whether it actually does in most cases is another product by product discussion.

Where the marketing really comes into play is selling people emulations of things that, for the most part, they've never personally heard, like an SSL 4k... or a Neve comp... where the vast majority of people being targeted have never owned or even heard those things in person and wouldn't know what they sound like anyway.

Case in point, I have a somewhat expensive tube leveler here... $500 for a mono channel... and I haven't heard a single plugin anywhere near as "warm" as it, but if a plugin dev told people it was that thing, they'd believe it because they don't know any better... and it's more about price anyway... plugins are cheaper.

But good modeling is probably not that easy. My buddy owns an old Ramsa desk that's way warmer than most any plugin. He just runs all of his daw outputs through it. It sounds great. You can probably buy Slate all day and never really get that warm of a sound.

[bungle]

The Presonus approach whilst being proprietary, is more elegant from a programming perspective. The DAW already knows which channels are routed to which bus. From a user perspective it is much simpler and kinder on system resources as it does not require multiple VST instances.
Besides

Wait, what ?
The nonsense around this new plugin format is so ridiculous it beggars belief, you actually think that this new plugin format is loading a single instance, but if it where in VST format that somehow magically that means it would use more CPU, sorry but your understanding of this is completely wrong.

This new plugin format will be very very very similar to VST, there is no way in cloud cuckoo land that Presonus are going to be stupid enough to allow any 3rd party developer to completely replace their Mix engine !!
What is actually happening here is that a plugin is being loaded, that plugin is being instanced across whatever channels there are in the project (Yes that's right, just like a VST would do) however, there is only one control panel for all instances (Note just one panel/UI/UX/whatever you wish to call it) but each channel WILL and indeed DOES add extra processing and WILL and DOES use extra resources (Just like a VST would do)
This plugin will have audio ins and audio outs for processing the audio of the particular channel/instance, there will be shared resources for crosstalk/bleed/whatever you wish to call it (Exactly like VST have already done in the past)

There is nothing special here, there is nothing BETTER than VST that all of a sudden means less resource usage, DSP is DSP, CPU usage is CPU usage, and no matter how much nonsense is spoken about this, Fact happens to also be fact.

Again, the reality is simply this, Presonus could and should (If they wanted to create something that would catch on and gather support, and not just some buzzword nonsense that will be forgotten in a few months) have chosen to do this in VST format with standardised extensions for the bleed/crosstalk, it could still have had the single UI, it could still have been loaded in at a mix engine level (not that that actually makes any difference whatsoever, 1+1 in the mix vs 1+1 at the first insert, oh wait hmmm, yeah, hmm, that's right, hmm, THEY BOTH EQUAL 2)
This approach would have allowed other hosts to begin to support it, this would have gotten many more VST developers to support it, and off we go we have a standardised VST extension that will be well supported.

I had actually gotten out of this silly argument because of all the "Why do you keep saying it" rubbish from some people, however, some of the utter nonsense that keeps being posted about resource usage and so on has dragged me back in to it.

Quick example, just to reality check all this silliness
Reaper, you can create a script that will load a particular VST plugin on each track
You can also create a JS that will control each of those plugins with a single interface
Do this with SKNote strip and you have exactly the same set up that this 'new' mix engine plugin format does
So with one click of a button in Reaper, I can add all the instances and the control UI, and the VST plugin itself is doing EVERYTHING, that would be EVERYTHING and more, that the Presonus plugin format is doing.
So nothing new, nothing special, just convenience. (Cue the "Just go use Reaper" comments)

Again, that convenience (Which admittedly is great) combined with an already existing format with extensions (VST) and wow, this is a killer feature, as is, it will die a death after a few developers write some plugins, they sell only to a limited market base (S1 users) and the support for it goes out the window.

[RockinMillie]

I wasn't suggesting for a moment that the Presonus approach would magically not use any system resources. Of course it will, any additional processing will have a cost.

This was my main point regarding extra processing

The answer given to the rhetorical question posed by nIGhT-SoN in response to Bungle's comment about implementing it as VST based, demonstrates that from a programming perspective there would be a lot more processing involved to dynamically check which channels are routed to which bus to prevent spinning if it were VST based.

I believe (however, I may well be wrong) that because the DAW already knows which channels are routed to which buses and knows when any changes occur to the routing, it would be simpler code wise to use the same notification messages to make the Console Shaper aware too. As opposed to a third party library (VST if you will) constantly polling the channel / bus routing to see if anything has changed.

However, I do take your point that it may well be that the Presonus code instantiates many instances of a class to do whatever processing is happening.

I am not privvy to the Studio One source code therefore am not able to get into debating the ins and outs of:

What is actually happening here is ...

The way of course to compare system resource usage between the two approaches would be to set up a proper structured test to compare them. However, life is just too short.

Quick example, just to reality check all this silliness
Reaper, you can create a script that will load a particular VST plugin on each track
You can also create a JS that will control each of those plugins with a single interface
Do this with SKNote strip and you have exactly the same set up that this 'new' mix engine plugin format does
So with one click of a button in Reaper, I can add all the instances and the control UI, and the VST plugin itself is doing EVERYTHING, that would be EVERYTHING and more, that the Presonus plugin format is doing.
So nothing new, nothing special, just convenience. (Cue the "Just go use Reaper" comments)

It all sounds fine. Until another channel is added to the the bus that you want to process: Add the channel, add the plugin, amend the script, amend the JS etc ...

[ghettosynth]

Quick example, just to reality check all this silliness
Reaper, you can create a script that will load a particular VST plugin on each track
You can also create a JS that will control each of those plugins with a single interface
Do this with SKNote strip and you have exactly the same set up that this 'new' mix engine plugin format does
So with one click of a button in Reaper, I can add all the instances and the control UI, and the VST plugin itself is doing EVERYTHING, that would be EVERYTHING and more, that the Presonus plugin format is doing.
So nothing new,

No, it wouldn't, which is what prompted my questions and comments in the first place. If we're just talking about plugins on channels and buses, like Slate, then your solution is equivalent at least in terms of function, if not convenience.

The one thing that S1's console does is this half ass attempt at modeling inter-channel crosstalk. This you cannot do by just putting plugins on channels and buses. That is the primary point of my longwinded explanations above.

Slate doesn't model that, and personally, I think with good reason. What they do model is intra-channel crosstalk on a bus, i.e., between the two bus L/R channels. I think that's smart as it will impact stereo perception which we are somewhat sensitive to and it might be an important part of capturing the vibe of a particular console.

Personally, I think modeling inter-channel crosstalk from channel strips is a dumb idea if you do it right, if you do it wrong, however, it's LOL dumb.

However, Presonus's entire justification for going to the mixer level is really based on this aspect and convenience/performance as discussed, discarding marketing, of course.

Does anyone really think that inter-channel crosstalk, as modeled by S1, is a good idea? Have you used it with good results? What did you think that it added? Do you have some comparisons?

[bungle]

[xcentric]

So true. That stand up never gets old to me.

[nIGhT-SoN]

What is actually happening here is that a plugin is being loaded, that plugin is being instanced across whatever channels there are in the project (Yes that's right, just like a VST would do) however, there is only one control panel for all instances (Note just one panel/UI/UX/whatever you wish to call it) but each channel WILL and indeed DOES add extra processing and WILL and DOES use extra resources (Just like a VST would do)
This plugin will have audio ins and audio outs for processing the audio of the particular channel/instance, there will be shared resources for crosstalk/bleed/whatever you wish to call it (Exactly like VST have already done in the past)

You seem to know what you are talking about, meaning you have some kind of inside information, right? Haha, I love when people are so sure of themselves and when they try to convince people just by saying "this is what actually happens" when they don't really know what actually happens. Assuming =/= reality. Come with some proof first, otherwise PreSonus is not guilty.

Anyway, I must say it's really fun to say MARKETING when you hate/don't like something, I started to use it in real life too, got some good laughs.

[Vintage73]

What is actually happening here is that a plugin is being loaded, that plugin is being instanced across whatever channels there are in the project (Yes that's right, just like a VST would do) however, there is only one control panel for all instances (Note just one panel/UI/UX/whatever you wish to call it) but each channel WILL and indeed DOES add extra processing and WILL and DOES use extra resources (Just like a VST would do)
This plugin will have audio ins and audio outs for processing the audio of the particular channel/instance, there will be shared resources for crosstalk/bleed/whatever you wish to call it (Exactly like VST have already done in the past)

You seem to know what you are talking about, meaning you have some kind of inside information, right? Haha, I love when people are so sure of themselves and when they try to convince people just by saying "this is what actually happens" when they don't really know what actually happens. Assuming =/= reality. Come with some proof first, otherwise PreSonus is not guilty.

Anyway, I must say it's really fun to say MARKETING when you hate/don't like something, I started to use it in real life too, got some good laughs.

[SLiC]

It seems strange to me that Presonus are being accused of making a new and unnessesey plug in format when pro tools has already done this (add the option of a paid alternative mixing algorithm) and no one seemed to cry about it?

http://www.prosoundnetwork.com/article. ... leid=37328

Avid 'heat' was not considered a plug in, but an 'add on' to pro tools (and it wasn't free!), they also did a lot of marketing (the bastards) when this came out....