Fender Studio Pro 8.0.2 - Discussion Thread

[Number6]

Confirmed Bug by QA:

Confirmed Bug: Controllers don't arm correct tracks when using folders

This is an issue since the beginning of time it seems, and I can reproduce this issue in 8.0.2 Windows (unfortunately!). If somebody could try to repro this with any Faderport or Mackie or Atom SQ (Song Button -> Page 2 - Rec) that would be great - thx! Here are the steps to repro: Create say...

studiooneforum.com

 

[js1]

okay, I'm now sitting at my desk after some experiments.

no matter what I do, S1v8 just doesn't work stable with a buffer size of 64 samples. once in a while there's a spike in the CPU, no clues in performance monitor, no clues in system-wide activity monitor (that's a mac) and the sound goes 'click'. just after that S1v5 on the same computer with the same projects works fine.

it's not the plugins, I can reproduce this in a project with no plugins. it happens to me at an empty project as well, I just create a new project, start the recording and it drops out once in a couple minutes. the S1v5 works fine, but not the v8. I even don't need to start the recording to reproduce, I create a track, enable input monitoring and listen to it and it will drop out.

I'm able to reproduce this on two different computers (both ARM Macs) and two different audio interfaces. S1v5 doesn't drop out while using 64 samples, S1v8 just needs it to be set to '128'. Ableton also works stable on 64 samples. didn't check Reaper, but it definitely worked with 64 samples a while ago.

user impact? uhm, monitoring latency while recording is now 5ms, not 3ms, i.e. almost twice the latency.

not sure how do I report this regression, but I'll try.

There was a change in the V7 cycle with Mac processor handling. Prior to the change, S1 only used performance core. After the change, S1 could also take advantage of efficiency cores. Sounds good, BUT...

In my case, using the efficiency cores with low latency caused all manner of spiking, even with lightly loaded projects. Which is now default setting. I disabled the efficiency cores, and I was back to running with 32 sample latencies.

If you're near the limit of processing on your project, then enabling the efficiency cores would give you additional headroom. But, you'll probably have to increase your latency.

Or, it could be something different in your case. Anyways, here's the setting:

 

[Lukas]

In my case, using the efficiency cores with low latency caused all manner of spiking, even with lightly loaded projects.

Which in fact is expected behavior.

Efficiency cores work best in large buffer scenarios. There is a high risk of dropouts when used in a lower buffering scenario. This is the reason why many DAWs don't use efficiency cores at all. They're not designed for real-time / low-latency audio.

 

[TheNeil]

Yeah, they really shouldn’t be enabled by default.

 

[LiveFromPFD]

Efficiency cores work best in large buffer scenarios. There is a high risk of dropouts when used in a lower buffering scenario. This is the reason why many DAWs don't use efficiency cores at all. They're not designed for real-time / low-latency audio.

Oh! That is so helpful to know. Thanks.

 

[Rambler]

Which in fact is expected behavior.

Efficiency cores work best in large buffer scenarios. There is a high risk of dropouts when used in a lower buffering scenario. This is the reason why many DAWs don't use efficiency cores at all. They're not designed for real-time / low-latency audio.

Isn’t that exactly what a hybrid audio engine is for - processing record-enabled tracks with the smallest buffer possible (and therefore on the p-cores) and playback tracks with a higher buffer (therefore on the e-cores)?

Since Studio Pro has a great zero-latency monitoring option with a dedicated playback buffer I don’t get why the described behavior is as expected. In case of Cubase and ASIO guard I do not notice such behavior. Efficiency cores work well even with lower buffers sizes (since asio guard adds 20 or more ms of buffer anyway except for tracks that are record enabled). Reaper with its anticipative FX processing (which excludes record enabled tracks) also does not have this problem.

 

[Number6]

Well no demo yet, which is good news (perhaps). That may signify another bug fix release, fingers crossed for a 8.0.3 rather than a 8.1.0.
(Pure speculation).

 

[boo]

There was a change in the V7 cycle with Mac processor handling. Prior to the change, S1 only used performance core. After the change, S1 could also take advantage of efficiency cores.

yeah, thanks, I've tried changing that setting, but no effect for me.

 

[boo]

Any specific reason you "need" to be @ 64 samples? That is lot to ask from any CPU depending on what you are doing.

yup. latency.

anyway, it worked for me with this specific interface for a decade, and still works in S1v5, so there's definitely a regression.

I've been meanwhile trying to record the affected new project in Logic (I need some extra stuff re tempo track and maps that's absent in S1v5, v8 has it, but appeared to be pretty buggy, Logic appeared to work just great) and it's also being rock solid on 64 samples.

that's a Thunderbolt interface BTW, 64 samples are pretty usable in those.

AND - are you using AU in Studio One? If so - that should be avoided at all times. VST3 is the way.

I'm not.

 

[Number6]

yup. latency.

anyway, it worked for me with this specific interface for a decade, and still works in S1v5, so there's definitely a regression.

I've been meanwhile trying to record the affected new project in Logic (I need some extra stuff re tempo track and maps that's absent in S1v5, v8 has it, but appeared to be pretty buggy, Logic appeared to work just great) and it's also being rock solid on 64 samples.

that's a Thunderbolt interface BTW, 64 samples are pretty usable in those.



I'm not.

I was scrolling around trying to work out if you are on Apple or Windows, then I noticed I had already asked you to update your signature.
You probably stated the OS already, but I've given up hunting around. If you are running Windows close all apps and download/install/run latencymon I suggest. I also suggest you start a new thread for this.

(Edit looks like Apple, nevermind).

 

[Vocalpoint]

Well no demo yet, which is good news (perhaps). That may signify another bug fix release, fingers crossed for a 8.0.3 rather than a 8.1.0.
(Pure speculation).

An v8.1.0 - would include bug fixes as well as new features.

Have never seen any S1/SP release that did not include fixes.

And FWIW - have never seen a x.0.3 release since S1v2 (circa 2011)

VP

 

[Number6]

An v8.1.0 - would include bug fixes as well as new features.

Have never seen any S1/SP release that did not include fixes.

And FWIW - have never seen a x.0.3 release since S1v2 (circa 2011)

VP

Minor poing releases are mostly regression bug fixes plus other bug fixes.
Major point release contain new features that are more likely to introduce other bugs that get ironed out in following minor point releases. All releases contain bug fixes however.

I wait until the first major point release and then install the previous version, that generally guarantees stability, and that's what Presonus has done historically when they introduced demo versions (or release it when they knew that the next version is a major point release, in this case 8.1.0).

Although this time around I bypassed my usual behaviour and I upgraded to 8.0.1 straight away and had no extra issues, and got away with it. I'm updating minor point releases as they come..then I'll wait for the last minor point release for 8.1 (back to what I normally do).

We shall see.

 

[Lukas]

And FWIW - have never seen a x.0.3 release since S1v2 (circa 2011)

7.2.3? x.x.3 doesn't count?

 

[Vocalpoint]

7.2.3? x.x.3 doesn't count?

I meant within the first initial x.0.x cycle.

VP