I confirm
It only works with faderport 1

Jumping buses issue

Hi all, first post here. Somebody over at Gearslutz suggested that I report this here because apparently it was supposed to have been fixed a few releases back. I've never reported it because I found a workaround for it. Anyway, here goes.

The issue:

- "keep bus channels to the right" is unchecked.

- You have a number of buses shown next to their corresponding tracks in the mixer. You create a new track or move an existing one up in the arrange window / to the left in the mixer so that it ends up to the left of the buses.

- Now, in the arrange window, you move that track to the bottom.

- All the buses jump to the far right in the mixer.

Workaround: if you move the track in the mixer rather than the arrange window, the buses stay in place. The problem is that, when you have many tracks, it's much easier and faster to move one around in the arrange window where you see all of them than in the mixer, where you have to "push" the track to the left / right so that the mixer scrolls until you find the spot where you want to drop it.

Variations: if the track is created in / moved to a location where some buses are to its left and some to its right, it's the ones to its right that will jump when you move the track.

Short video: first I reproduce the issue, then the workaround, then the variation where the track isn't all the way up / left:

http://www.screencast.com/t/MK9y6R5G

My system: Windows 7 Pro 64bit, Studio One Pro 3.5.1. I have Studio One in four different computers, right now I only have access to two, a desktop and a laptop with the same config and in happens in both.

Cheers,

CL

abraham754 wroteI recently opened up some heavy mixes I had done in 3.5 and noticed that 3.5.1 isn't as effecient on CPU as 3.5. Has anyone else noticed this? I had to render several channels and subgroups to audio just to be able to play the songs.

I feel your pain, abraham754. I'm seeing 100% spikes constantly when trying to play a mix I did on 3.3.4 which had 7 VI instances (incl. Presence, Analog lab, Strum GS-1, Lounge Lizard). It never came close to hitting the 100% cpu usage in 3.3.4.

Also the best latency I can get with Studio 192 with DP set at Maximum and utilizing instrument latency is 28 ms. Can't get under 10 ms like I'm seeing in others youtube videos demoing the instrument latency feature. I can't even go below a 256 device block size without Studio 192 failing to initialize and crashing Studio One.

I've been pretty frustrated with the new updates to the point of wanting to leave Studio One. This is my fault because I updated in the middle of an important project. PreSonus updates are always solid so i didn't think twice.

That said, here are the issues I've been having and here's is how I've been able to solve them.

1) Multiple CPU spikes at 16 Samples Device Block Size ( DBS ) on the Audio Device and Maximum Dropout Protection ( DP) in the Processing section.

2) Multiple Crashes during sessions and during closing studio one. Also while pulling up plugins while the session was playing.

3) Crashes when changing DP

4) No input meters while tracking. Audio was still being recorded and the wave form was visible. ( still having this issue from time to time)

**The first thing I did, was look at the crash logs as painful as that is. I found that the following plug-ins were on the list as having crashed. Slate, Lexicon, Melda. I updated, uninstalled and reinstalled. That seemed to fix some of the issues.

** Deleted settings folders less the license file and let Studio One rebuild it. Nothing improved.

** Re-mapped VST folders. Re-scan plugins, reset black list. Gave a touch more stability.

** Updated Focusrite Control App to latest version. There was a release June 16 which most users with focusrite interfaces may not know about.

The above fixed my crashes.

However, for me, And I will list my full specs below, the thing that seem to fix it all was my screen resolution.

I'm on a 27" iMac and normally use a rescaled resolution of 1080P so that Studio One looks a little bigger and easier to read.

At 1080P, 16 samples DBS, Max DP I I was getting 18ms Monitoring latency and multiple CPU spikes, Pops and clicks.

At 1080p, At 1080P, 512 samples DBS, Max DP I I was getting 32ms Monitoring latency and no CPU spikes, pops and clicks.

Well, I changed my screen resolution back to default for my computer and immediately my CPU spikes, Pops and clicks went away. I'm now down to 16 samples DBS and High DP with 2.4ms of RTLatency.

at 512 Samples DBS and High DP i'm down to 8ms of RTL. This while on default screen resolution.

I went back to 1080p scaled screen resolution, and it seems that resetting my screen resolution also fixed the issue I was having with a 1080 res. it almost seems like the Video card was clogged up. Layman's terms.

As of typing this, on a session that has 178 tracks, I'm using a Device blocks size of 32 samples, High Dropout protection with a process block size of 1024 samples with 3.40ms of RTL

I could not be happier.

RIG SPECS

iMac ( 27-inch, Mid 2011 | Processor 3.1 Ghz intel Core i5 | 16 gb 1333 mHz DDR3 | Graphics AMD Radeon HD 6970M 2048 MB | Clarett8PreX Audio Interface | MCU | Faderport 1 |

George

As of typing this, on a session that has 178 tracks, I'm using a Device blocks size of 32 samples, High Dropout protection with a process block size of 1024 samples with 3.40ms of RTL

I doubt 99% of the S1 audience would get that good of performance with a 6 year old i5 computer.

Should be able to. It meets all the specs.

AriAhrendt wroteNew features and improvements:

• Browser selection lost after searching.

Not entirely working here yet.

Look at the image below, I select Kick 808x 4.wav, the blue bar and the player both show Kick 808x 4.wav is selected. However mind how Kick 808x 2.wav is actually focused after the search update. So from the moment I push the down arrow to go to the next sample, it won't go to the one below the selected file, Kick 808x 1.wav. But instead it goes to Kick 808x 3.wav, which is below the focused file.
With a short list this isn't an issue, but with a long list it's pretty annoying because you don't have a clue where the initial selected file is.

jorgepinto1 wroteShould be able to. It meets all the specs.

Not many interfaces are going to run well in even top of the line systems at 16 and 32 sample buffer settings. Some Thunderbolt and PCIe interfaces with great drivers might be able to pull off the task, but I'm even skeptical then. Even 64 samples is tough for all but some of the best interfaces.

When it comes to "meeting all the specs," I'm assuming you mean system requirements. Those are the bare minimum specs for the software to run, not the requirements for bleeding edge performance. You're welcome to try other DAWs at 16 and 32 samples and see for well you do with them. I'd be shocked if that Focusrite interface could get 16 samples out of any DAW.

When it comes to Studio One, 1) set your instrument buffer size "as low as it will go without artifacts" then, 2) set your dropout protection accordingly in relation to that. Those are the instructions. If the latency is still too high, you can always press your ear up against your speaker to shave off another 2ms or so.

Funkybot wrote

jorgepinto1 wroteShould be able to. It meets all the specs.

Not many interfaces are going to run well in even top of the line systems at 16 and 32 sample buffer settings. Some Thunderbolt and PCIe interfaces with great drivers might be able to pull off the task, but I'm even skeptical then. Even 64 samples is tough for all but some of the best interfaces.

When it comes to "meeting all the specs," I'm assuming you mean system requirements. Those are the bare minimum specs for the software to run, not the requirements for bleeding edge performance. You're welcome to try other DAWs at 16 and 32 samples and see for well you do with them. I'd be shocked if that Focusrite interface could get 16 samples out of any DAW.

When it comes to Studio One, 1) set your instrument buffer size "as low as it will go without artifacts" then, 2) set your dropout protection accordingly in relation to that. Those are the instructions. If the latency is still too high, you can always press your ear up against your speaker to shave off another 2ms or so.

I have a clarette8PreX and I can track at 16 samples on Software Low Latency at 16 no problem. in fact my RTL is only 2.4ms if not less. After 3.5 and 3.5.1 I started having lots of issues as you can see from my detailed explanation above. I used other DAWs already and have no issues. But as of today, My Studio One is running like a champ.

Actually my comment was a bit side tracking as I as mixed up on your point.

I had gone through your OP with a fine tooth comb as almost every one of your finding where not as expected. ( example: 16 buffers and 18ms latency )
I then go to the end and realized you were very happy with your new results.

You performance is as good as one could expect.
But I believe that was not really the point of your OP.
Were you not really trying to call out an issue with running DPI at something greater than 100%?

I was just sharing my experience. Hoping it would help others.

Oh good,

Yes, this is happening to me also and was quite frustrating.
Problem is for me that when stuff like this happens, I usually assume it's a setting that I've not got quite right and spend an inordinate amount of time looking at and trying nearly every potential setting (that I don't normally use) to see if it's the cause.

Nice to see it's common among us and should be deemed a bug to be fixed... eventually.

My point to both of you.
If you see an issue call out the steps to replicate it, other wise it will never get fixed.

I am still having cpu spikes that I got in 3.5 and still now on 3.5.1 that I didn't have in 3.4 It is making an issue when I have to work on something that was nearly done and rendered properly in 3.4 and it won't render out without audio dropouts in 3.5.1 I have a monster computer (Windows 7, 64 gigs of ram, 6 cores at 3.30 Ghz with a Digigrid IOS). Anyone else having problems? Has the dev team noticed and working on this?

It is possible to get 3.5 working exactly like previous versions. Try not using LLM or even dropout protection. Just set a high playback buffer as you normally would. But also the whole point of DP is to prevent sessions not playing out properly. Have you tried various combinations etc.. If anything I am seeing better results with 3.5.

jpettit wroteMy point to both of you.
If you see an issue call out the steps to replicate it, other wise it will never get fixed.

I hope this doesn't account i.e. to the horrible instability of using third-party plugins. How could you replicate a random occurrence? I, a slightly tired and annoyed Finnish S1 v3 customer, vote for proper beta-testing on behalf of a company called Presonus, and wish that the rock-solid feel of Studio One v2 would be a truth one day.

Peace.


Best regards,

Studio One has quit unexpectedly.

I am gonna update today and we'll see.

jpettit: I know I owe you a video test of my issue. I didn't forget.

Hi! my name is Philippe. I am having an issue with the 3.5.1 it can't use it at all . it was great before . I am using MacBook Pro (15-inch, Early 2011) (Sierra). so I was wondering what I can possibly do to make it work. Please