Hi, bear with me, as this will be a long post. I also believe for anyone interested in dsp testing, it will be a rewarding post and is written in a detailed, clear manner.
My mac stats:
1) iMac Pro 8 core, 64GB ram, ATI Vega 56, Mojave 10.14.6, Apollo 8 Thunder Bolt.
2) Macbook Pro 16" 8 core 2.4ghz, 64Gb ram, ATI 5500M, Catalina 10.15.1, Motu M4 USB-C.
3) Macbook Pro 2015 quad 2.8ghz, 16GB ram, Nvidia 750M, High Sierra 10.13.6, Avid Mbox 3 USB.
On the iMac Pro and Macbook 16", I also have win 10 pro bootcamp installed, and S1 is performing at least twice as well than on the same machine with mac OSX. I have also tried on board audio with the standard mac os core audio driver for all 3 macs. I have done a variety of dsp tests, comprising around 10 different popular VI's and 10 popular FX.. each one from a different developer for fairness. I have also tried forcing the intel GPU on the two macbooks to see if the discrete cards were an issue. I have even gone as far to reformat, install NOTHING on the system other than S1 latest version, audio interface drivers and a few plugins for testing! Nothing helps.
Logic Pro gets 5x the performance when arming tracks to record, and almost double the performance for playback tracks (S1 audio dropout protection mode, setting "high" is used, 1024 samples, Logic setting "medium" used, 1024 samples). Pro Tools performs much better than S1 but not as well as Logic. Reaper, ditto.
Let's talk about real cpu usage.. S1 can take the cpu to around 45 percent maximum before pops and clicks occur. Logic can use about 75% of the real cpu power and so can PT. To give you an example to highlight this, on an 8 thread machine with theoretical 800% maximum use (what one would see if using istat to measure the cpu, for example), S1 can take it to about 365%.. Logic to almost 600%!. Sure, S1 can keep adding VI's and effects and never stop playback till the cpu is maxed out, but the more you add, the more pops and clicks there are. I am talking about the level I can take it to where there are no pops and clicks and integrity of audio playback is 100% assured. See, Logic and PT will stop playback and will NEVER allow a single pop or click.. You'll instead get an overload message. Some lament this, personally I love it, cause I know that if something can play back, the audio is 100% intact, including for real time bounces.
It's better in V4 than it was previously, sure, but it's still what I consider very poor performance.
I've been complaining about S1's performance on mac overall since V1.. so this is nothing new to me.. But after I saw a video claiming that it's just SO efficient now with V4.5 and beats Logic, and realising that I was not having that experience at *all*, I decided to put it to the test myself cause I knew what "studio one expert" youtube channel were saying was complete and utter BS.
Sometimes in S1 I have a moderate project going, and just record arming ONE VI track will take it over the edge..
Let's talk about some testing results. For this first result we will use the quad core macbook.
We'll use the popular sylenth synth (latest version) in this case.. I used the AU for both Logic and S1 so there'd be no variance, and the same 4 chord, 4 bar midi file.. This file was copied and pasted to an overall length of 128 bars at a project tempo of 128 BPM. The goal here is that the DAW has to complete a single play through without errors.
To find out the maximum instances, much like any DSP test, we just keep duplicating the track and midi clip till we can't reliably do any more. Logic in this case got 71 instances, S1 was 38. Even just 40 would cause intermittent peak distortions and pops and clicks in the audio.
The original VI track mixer channel is set to VERY quiet, so therefore all the copied tracks are too. The Peak meter on the master is no where near 0 whatsoever. It has nothing to do with audio distortion. It's performance related clicks and pops.
Logic's meter was PEGGED on all 8 threads. S1's meter showed about 50% or so usage. Real cpu via istat menus was as explained above. I even had istat menus disabled during testing to conserve every last resource, only enabling it when I was ready to record the cpu load amount. I did everything right (I am experienced at controlled DAW efficiency testing, and have been kind of obsessed with it since the year 2000).
Now, the major issue.. You see.. I can almost live with S1's inefficiency on playback tracks, cause of track transform which is easily the best form of freeze in the multiverse.. Nothing comes close. But this is not going to help us when are record arming tracks to use them at a low buffer in realtime.
To do the low buffer tests next, I created a brand new project and created one sylenth track, same patch, would arm it, and then duplicate it and get the maximum result before pops and clicks. It would play the same 128 bar midi file.
There is a huge issue with S1 & record armed tracks. Using just 128 buffer at 44K, which is not an unreasonable expectation, S1 could only muster 5 tracks before constant pops and clicks. Logic was able to muster 23! Now when record armed, Logic does NOT have an overload message.. It will just click and pop when the performance cap is breached like S1 does.. So to be 100% fair to both, I also put a spectrum analzyer and waveform meter on the master output, as to not rely solely on my ears.
The other thing is, that Logic will only use half the available system cores for record armed tracks.. That means in this case, it would only use 4 threads.. It doesn't matter if i were to continue adding record armed VI tracks, it would never encroach on the remaining 4 threads. Apple explained that this is by design, so if you start arming VI tracks in an already heavy project, all high buffer playback tracks are shuffled to half the system cores, and you get the other half for recording tracks. This gives Logic a chance to be able to drop in and record large chunks of tracks in a single pass alongside large numbers of playback tracks already in the project. It works well! But what it also tells me is, that logic can get more record armed tracks using just half the threads that other DAWs can! This is a testament to Logic's efficiency.
To really hammer the point home, Logic was able to get 13 record armed VI tracks at a buffer of 32.. This is more than double what S1 can do at a buffer of 128!
On the imac Pro, Logic got 152 tracks playback, S1 was 80.
Record armed was 50 vs 11.
I then tested with other VI's such as Kontakt6, Fab Filter Twin 2, Air Music Loom and so on to similar relative results. I can give precise results of every instrument if anyone wants it.. It's just that this post is already so long as it is, and we still have to talk about audio tracks.
Ok.. one could argue that the above test was not a real world usage scenario, as no one would arm 23 VI tracks at once.. of course, those doing large orchestral sections might do something like 10 VI's at once, and in my case, I once used Sylenth to make an entire track including drums, and I had one instance of sylenth dedicated for each drum sound, so all were armed at once as I played, so different sounds could automatically be recorded to the correct VI track and have their own mixer channel. So, there ARE some usage scenarios for it, but not so many in every day use.
BUT.. for recording a large number of outboard tracks at low buffer, there IS a real world use for this and is very common.
Anyway.. in this test we will use mono record armed audio tracks being monitored natively through the DAW rather than using the Apollos' DSP, at a buffer of 128. That's a very high buffer to use at 44K but any lower and the results are way, way worse. Because there is a Catalina computer in the mix, I have only been able to use plugins that work with Catalina as the projects must be compatible with all three computers, even though this particular project is only being tested on a computer with Mojave.. It just makes sense to keep the testing uniform with plugins that are Catalina compatible. Since reverb plugins are what put the most stress on record monitoring, I will be using Liquidsonics' excellent Seventh Heaven reverb plugin for this test. I will try two approaches.. Adding a single, default instance of the plugin on the audio track and then duplicating tracks and seeing how many we get. Logic does not allow record monitoring on multiple tracks with the same input, so for this test I moved solely to the imac pro which has 64 separate inputs via 4 apollo 8's (8 onboard inputs and 8 adat x 4 chained units). The other way will be to record arm say 32 mono audio tracks with no effects and see how many reverb busses we can add before issues occur.
In Logic, we are able to achieve 40 audio tracks each with an instance of Seventh heaven.. This is at 32 buffer size! Likewise I can do this with 40 reverb busses instead, and no reverb inserts on the audio tracks. To really test it, i kept the buffer at 32 and added a Fab filter EQ and Pro Q on each channel! LOL! No issues. At 128 buffer there was plenty of headroom to spare. I have gone so far to 64 audio tracks record armed at 128 buffer with a reverb plugin on each track and NO pops or clicks!
Wanna know how many S1 could do at a buffer of 128? Ten. And that was pushing it. Ten tracks with one instance of the reverb plugin each. Similar results replacing Seventh Heaven with FabFilter ProR. Similar issue removing the inserts and using busses. FORGET adding compressors and EQ's to each track.
Let's go to 32 buffer.. Um.. 4 tracks. WOW.
Sure, if i remove all reverb plugins, THEN I can record arm 32 tracks in S1 at 32 buffer and add an EQ and Compressor to each one. But then even ONE reverb BUS being sent to just one of the monitored audio tracks will cause issues.
It can't be my mac, cause I have tried 3 (and many more in the past). It can't be my interface cause each mac has a different one, and I also tried the built in audio on each mac, which means I have effectively tried 4 interfaces. It can't be the OS, cause each mac has a different OS (again, with all past testing included, I have tried basically every iteration of OSX that S1 has been compatible with since day one). The issue is that S1 can not deal with any type of serious load when tracks are record armed and using plugins that require a decent amount of CPU resources.
Before anyone asks why don't I just use Logic.. Well, I LOVE Logic.. I used it since 1997 and know it back to front. However, there is a show stopping bug that was made worse in Logic X, which Apple refuse to fix.. I have reported it 4 times a year, every year, to no avail. Basically, on audio tracks and instrument tracks in Logic, if you insert any native or dsp(uad) plugins with latency into a track insert on that track, ALL effects automation for that track is out of time by a random multiplier of the total track effect latency. For example, draw some filter automation for a zero latency filter plugin on the grid, and it's bang on time. Insert a UAD plugin or any native plugin with latency, before OR after that filter plugin on the same audio or instrument track, and now the automation of the FILTER plugin is out of time.. The more latent plugins you add on that track, the worse that ALL automation goes out of time.. If you are on a VI track, the automation of the Vi itself will also be out of time. It's infuriating, and means I no longer use my library of over 80 UAD plugins in Logic cause I can't draw automation on the grid and have it play back in time.. so I started the hunt for a new DAW.. and I soon realised, S1 does NOT have this issue.. It is able to automate bang on time regardless of plugin latency. PT is the same. Bang on time. Cubase is actually variable and completely unpredictable, which is why I didn't switch to that (as I very much liked it as a DAW).
To those who think it's no big deal, I can guarantee you that over time you will want to throw your mac out the window.. when you realise all your automation is suddenly out of time cause you added a plugin to the track that added some latency. Solution? Don't use ANY plugins with latency. LOL! No thanks.
Last edited by TNM on Mon Dec 02, 2019 4:55 am, edited 1 time in total.
Thanks for doing this test. I’m glad it’s not just me- “low latency monitoring for virtual instruments” is basically impossible to use on many VIs on busier projects because loading the two instances of the VI for the dual buffer system to work will inevitably put one core over the edge. And I have an 8 core 3.0 GHz Mac machine- it’s not a PoS.
Here’s a FR you can vote on about this here
https://answers.presonus.com/30104/impr ... 249#a30249
There was a very interesting song file Alan sent me in that thread using mostly Native Instruments plugins that performed much much worse when Dropout Protection was enabled than when it wasn’t. Some plugin brands don’t have this issue, really not sure what the reason is. Someone asked Acustica in their forum about a similar issue in Cubase which has ASIÓ Guard and they blamed it on core synchronization methods, no idea though
robertgray3 wroteThanks for doing this test. I’m glad it’s not just me- “low latency monitoring for virtual instruments” is basically impossible to use on many VIs on busier projects because loading the two instances of the VI for the dual buffer system to work will inevitably put one core over the edge. And I have an 8 core 3.0 GHz Mac machine- it’s not a PoS.
Hi, you are more than welcome.. Because I actually enjoy doing this, if there's any particular plugins you want to test please do let me know and I will do it, gladly .
What you say is correct.. There is something wrong with the dual buffer system that doesn't seem to affect Logic (Cubase also out performs studio one when using Asio Guard, but it too has it's issues).
No, that's not a POS at all.. It should be able to do what you described.. If you tried it in Logic I bet you it would do it.. I am not suggesting moving to Logic.. I myself am moving away.. but if you have access to it at least, it would allow you to confirm 100% that it's S1 that's the issue here.
Look, I'll be honest.. if Apple changed just two things about Logic 1)The automation timing issue I described and 2) Allowed a choice of midi input per track like every other DAW in existence does, then I wouldn't have even bought the upgrade to S1 4.5.. I'd never have tried Pro Tools.. I knew Cubase cause I had to know it for a bunch of large projects about 13 years back, so I extensively learned SX3 and currently own 9.5.. You see.. my thing is about having the fundamental performance rock solid and then worrying about other things.. as bug free as possible.. Pro tools loses many features to other DAWs but I gave it a decent chance because the timing is very good, and I loved how it had the delay of every channel right there in the mixer. Also, the clip gain handling is unique and no other DAW I have tried can do it that way (basically, no need to split clips to have individual gain handles, you just use the smart tool and highlight anywhere on a clip and drag up or down and it instantly does the volume adjustment.. It's SO easy to level a clip in PT). However, PT is broken at any buffer under 128 when using core audio. It makes S1 look like a masterpiece in comparison LOL. 128 everything changes, and it then performs close to Logic.. but if I am going to monitor a bunch of outboard stuff, I want a LOW buffer.. ad mys low as possible.
If Presonus fix S1's performance on MAC, i'll be all over it an instant.. Goodbye everything else! I have nothing against the program (other than the cluttered GUI when left and right side inspector/browser are open) and am glad they have done well with it. However, they can't seem to nail the performance on mac unfortunately. Windows is an entirely different ballgame.. It's great there!
I just don't like shilling BS saying how it WAY outperforms Logic and rubbish like that, which misinforms people and you have to wonder if someone asked them to say that.. Not accusing, but wondering....
PS Have you tried windows 10 on your mac just out of curiosity to see the performance? You can install win 10 pro by downloading the ISO direct from microsoft, and you don't have to activate it for a month or something, so you can fully test it and S1!
Sorry, I have zero interest in installing Windows just to benchmark test a program out of the goodness of my heart
And yes people who don’t experience issues in this program do tend to minimize the issues of others, not sure why.
robertgray3 wroteSorry, I have zero interest in installing Windows just to benchmark test a program out of the goodness of my heart
That's fair enough.. perhaps you could install another DAW on OSX then and you can say "here presonus, this DAW performs fine on the same mac"..
i'll be sending them an email soon with all my findings as well as videos for evidence and all sorts of data.. The more of us that tell them, the better chance we have of getting it fixed.
That said, I am a bit concerned that they don't know how to.. I understand the recent upgrade uses it's own special multithreading for multi output VI's, which is quite unique, but it's not going to change the underlying performance issue..
You’re probably right that comparing Windows and OSX capabilities on an identical machine will be the strongest argument here.
Comparing DAWs is not 1:1 since only Logic and Cubase have similar dual buffer systems, and they aren’t completely comparable. I’m not really sure why Green z monitoring / dropout protection has so much overhead but it’s not the same as any other DAW so comparisons like that aren’t super helpful.
If someone has a dual boot on Mac, you could be a hero by testing comparative monitoring overheads!
robertgray3 wroteComparing DAWs is not 1:1 since only Logic and Cubase have similar dual buffer systems, and they aren’t completely comparable. I’m not really sure why Green z monitoring / dropout protection has so much overhead but it’s not the same as any other DAW so comparisons like that aren’t super helpful.
Sorry, I disagree with this completely. My attitude is that it doesn't matter how it gets there, but what it can actually do when it does. In other words, it doesn't matter that they all use variations on the dual buffer theme.. the ultimate point of this topic is to show that whatever studio one does, it's producing track counts/Vi polyphony/FX plugin instances of a much smaller number than other DAWs. Logic and Cubase aren't the only other DAWs to do it btw.. S1 was the LAST to do it. PT has been doing it for years. Reason now does it do.
DP/Live/Bitwig/Reaper don't do it. I am not entirely sure about Tracktion but will look into it.
Live is more efficient than S1 and it's not using any kind of "cheat" buffer whatsoever.
I don't know why you think the Presonus implementation is so very different to the others anyway.. The only difference as far as I can tell, is that as of V4.5.5 Presonus allows each output of a multitimbral VI to be processed on a different thread. Who cares, when I can crush it's performance with Logic in any scenario? I am pretty sure Logic does that too for a while now btw but I *could* be wrong, so will check into it to be 100% sure. I may be wrong indeed.
Thanks for this post!
Did some recent (re)testing, because I’m hovering between Cubase and Studio One (from S1 =>Logic X =>REAPER =>Cubase 10.5) and also experienced what you are describing in your post. Was a bit surprised by the performance meter at barely 25% and unable to use low buffer settings with maxed-out dropout protection. (Mojave 10.14.6; 4 GHZ i7; SSD etc…)
Intel Core i7
Memory: 32 GB
Radeon RX Vega 64
OS X 10.14.5
Apollo X6 Thunderbolt
Studio One latest version
Robert Johnson III wroteThanks for this post!
If you have all three DAWs (S1, Logic, Cubase) and some disposable time-
It's a totally thankless annoying mission should you choose to accept it but what I think one thing Presonus honestly needs is a simple video showing those three DAWs set to comparable dual-buffer settings using Dropout Protection, ASIO Guard, and whatever Logic's system is and what the limits of monitoring Virtual Instruments is on each DAW.
Plugins that I see perform worse with Dropout Protection than comparable single-buffers:
xfer Serum, VPS Avenger, HeatUp 3, Carbon Electra, most Native Instruments EFFECTS (I think their Instruments are fine), there's probably more honestly- Acustica plugins do too but I'm not convinced that's not their fault...
Although I can't blame you if you don't want to take the time to really spell out how Dropout Protection still needs some work. Even if someone bought me Cubase and Logic I'd still grumble about doing it lol. The reason I see this kind of being the status quo is that usually it's people trying out the DAW on the 30-day demo who notice this, and it's ridiculous to expect a potential customer to extensively benchmark Studio One to explain how other programs' low latency monitoring schemes are still ahead of ours.
Also not sure if this helps add some more evidence to the pile:
Turning on dropout protection causes dropouts Studio One 4.5.1
Generally Presonus' position seems to be "if you're maxing out a core with a plugin nothing we can do can help that" but I genuinely don't understand how if we're loading two instances of a plugin (with Dropout Protection's dual buffer system) that on their own only uses 25% of a core each the result of both of them running maxes out a core. Alan's tests in that thread spell this out better than I can, especially since I don't have mutliple DAWs to test this. Thanks for pointing out that Logic does it a lot better, that's good to know for people who want to test and improve this.
robertgray3 wroteRobert Johnson III wroteThanks for this post!
I notice some stuff performs better with dropout protection off also, it goes back to pre 3.5 ways of working.. That said, S1 was never efficient on Mac (always was on Windows).
I really think something needs to be cleared up here and please undersstand I am only trying to help.
What dropout protection does is quite simple.. If you enable the "z" for low latency monitoring, it sets record armed tracks to the buffer setting you have chosen in preferences. All other tracks can be considered "playback tracks" and work on the buffer chosen in S1's dropout protection settings..For example, for my tests I used high, which Presonus claims is 1024 sample buffer.. so quite simply, if i chose a 64 buffer in the main prefs, record armed tracks sit on 64 buffer, non record armed tracks play back on 1024 buffer. I matched this with logic's "medium" playback buffer setting, which can NOT be turned off and has never been able to be turned off, even as far back as windows days, and this medium is also 1024. Logic's choices are small (512), medium (1024), large (2048).
Truth be told, I have my Logic one at small at all times, but I was trying to be fair and give S1 a fighting chance.
Cubase as of V9 offered 3 similar choices but I think they changed something about that in V10. I am not entirely sure.
What Presonus added in 4.5, was the ability to process each channel of a multi timbral plugin on a different processor thread. This means that say if I opened an instance of Kontakt, and created 8 instruments inside this instance of kontakt, each with their own midi channel and output, S1 in theory should be able to put each instrument within the one kontakt instance on a different processor. THIS is quite special and unique amongst DAWs and I do applaud Presonus for thinking out of the box on that one. PS, to use this setting effectively, whatever you do, DISABLE Kontakt plugin's (for example) own multi processing feature.
In any case, even with this feature, S1 sits at the bottom of the pile for me regarding performance.
Since my first post I have added Cubase 9.5 and Reaper to the mix.. Reaper does NOT have a dual buffer system.. It has some pre anticipative trickery which is basically a look ahead, but the higher you set it, the less responsive the playback functions are cause they are mandated to that look ahead delay.. so you have to sort of find the right balance. In any case, Cubase and Reaper THRASH S1 4.5.5 in both VI playback count, record armed VI tracks, and record armed audio tracks as far as performance is concerned.
I absolutely detest Reaper as a DAW.. words could never describe how much, but I wanted to test the latest version as it's been a while since it was in a performance shootout of mine.
If dropout protection in S1 is disabled, quite simply, S1 works at the realtime buffer you have chosen at all times. The lower it is, the harder it is for S1 to cope.. that's like any DAW without a dual buffer system though.
I have tested Avenger as I bought i on the BF sale just two days ago, and I'll have some results for that soon.. IN a nutshell, Logic is once again thrashing S1 with both dropout protection enabled or disabled. Note.. i can NOT disable it in Logic itself.. but I wanted to see how well S1 did without it. Cubase with dropout protection disabled performs sort of on par with S1 when it's disabled.. but cubase with it *enabled* beats S1 with it enabled.
Pro Tools as always sits right in between.. If you are willing to work at 128 buffer or higher, it's performance is close to Logic's.. At lower buffers, it's completely useless.. about the same as S1 with a 32 or 64 buffer.
Now, the big elephant in the room as far as I am concerned, is the quantum. I am honestly thinking about buying one and I'll return it if the performance is not improved.. But I have a theory that since Quantum "talks directly" to S1, the performance *may* be leagues better.. Maybe that's the key with S1.. a tightly integrated system like that. Unfortunately, I can't find anyone to help me and tell me if quantum performs better for them than the interface they replaced it with..
If someone who owns a quantum could pop into this topic, it would be very much appreciated. I am happy to pay you for for an hour of your time, your standard hourly rate, to do some tests for me.. I can provide all the projects. It's also for mac only users I'm afraid, as S1's performance in Windows is fine.
I use a Quantum, so my general dissatisfaction with Low Latency Monitoring for Virtual Instruments is based on using the Quantum.
A question I'd love to have answered is (and I suppose I can figure it out with CPU activity when I get some free time aka never) are the 2 instances of the plugin always loaded on the same core? from my understanding one instance of the plugin takes user input via the mouse and synchronizes with the one actually playing back... is this how it works for virtual instruments too? Because if those instruments are always getting put the same core then it's no wonder why S1 can handle half the monitoring VIs as other programs...
robertgray3 wroteI use a Quantum, so my general dissatisfaction with Low Latency Monitoring for Virtual Instruments is based on using the Quantum.
Well there you go, you just saved me a lot of time and money! What would be fascinating IMO is testing the quantum with another DAW when you have time. I have pre prepared performance tester projects ready to go and can provide them to you, as well as pay you for your time which I'd require about half an hour of once you downloaded the projects.
As far as your question, I'll try to answer but I may be misunderstanding you.
What I CAN do it explain how DAW multithreading, including S1's, works, and that might cover the answer you need?
It's processed on a track by track basis.. It's really quite simple...
Track one (whether audio or Instrument) and all the insert plugins on one core, track two on the next, and so on.. So of course, if track one has a really heavy synth on it with effects, and track 2 has a light synth with no effects (just an example), then the core usage will be imbalanced.. Most DAW's will then shuffle things as you add them to put them on cores that have processing headroom. But the basic logic remains.. it's 1 track per core. Make sense?
Now, with 4.5.5, presonus has done some trickery to allow ONE instance, i.e one track of an instrument, to use multiple cores, IF that instrument has multi outputs.. Like kontakt as I said, or say a drum machine with 8 or 16 outs.. S1 will endeavour to process each output on a different core.
So yes, if you have 10 instances of one plugin on one track, they'll all be on the same core.
If you have the same VI on different instrument tracks, then it's different cores.. my performance tests are made to maximise the possible performance of any DAW.. cause each track has an identical instrument and clip and is just being duplicated, and each duplicate shuffles to the next core, and of course cycles once all are used up. There's more to it than that but that's a simple overview of it.
Basically, with the tests I do, they do not benefit or handicap any DAW vs another.. they are identical tests in each daw, with identical clips/fx/instruments. There are no variables the way I do it. It's just a stereo instrument duplicated over and over to see how many can play..
With Audio track tests, it's just the same thing.. a single audio track with a certain chain of effects, duplicated till you get a count of how many S1 can handle..
So no, that's not why S1 has issues arming tracks.. it just has problems with low buffer monitoring on OS X specifically.. Even on empty projects.. completely empty.. add a really heavy instrument and arm it so you can play it with the keyboard and S1 performance meter goes nuts. This is a coding problem, nothing more. ONLY Presonus can fix it. I was hoping this topic would gain more traction but I suppose it's early days yet.
My next test will be a multi output one, for VI's that use multiple outputs, as S1 may gain some ground here with some serious benchmarking focusing on that.
TNM wroterobertgray3 wroteI have pre prepared performance tester projects ready to go and can provide them to you, as well as pay you for your time which I'd require about half an hour of once you downloaded the projects.
I'd like to test these on my 7980xe hacks, and I only charge $1500/hr...
Just kidding of course, I'm curious to know and it would save me time.
ryanconway1 wroteTNM wroterobertgray3 wroteI have pre prepared performance tester projects ready to go and can provide them to you, as well as pay you for your time which I'd require about half an hour of once you downloaded the projects.
Curious to know what? Sorry I didn't really catch the point you were making.
If it was about spending hours to try and volunteer to improve software, yeah, I don't like it either. like improving the software I use but there are limits, as you mentioned. That's why I'm not really digging into this much anymore. Alan (mostly) and I tested it for a few hours and then gave up when nobody really showed interest. Can't blame them, considering the reward for this multiple days of testing is gonna be somebody maybe looking into it sometime within 1-4 years.
In the meantime, I just know it doesn't work great and try to work around it as best I can
robertgray3 wroteCurious to know what? Sorry I didn't really catch the point you were making.
Well I've done all the work this time. All the time consuming stuff is done.
If no one speaks up about it it will never get fixed. That's my philosophy.
I already regret buying S1 4.5.5, and because my demo is still activated and the purchased one has not been, I am actually going to ask for a refund.
See, I *can't* just work around it. My projects are big and use tons of VI's.. Right now in this state, the DAW is of no use to me on OS X. There is just no way I can do the sort of projects I am used to and have them play back.. I'd have to track transform everything and set the buffer higher for incoming recordings, the latter which I am not willing to do..
TNM wroterobertgray3 wroteCurious to know what? Sorry I didn't really catch the point you were making.
Well I spoke up plenty, nobody was interested, now more people will have to run these tests and comment here and vote on that FR at the top.
Yes, you should ask for a refund, but you might want to send a Support Ticket before you do stating that Logic is vastly outperforming them on this front. The three or four people who brought the most valuable input on this in the past were also on demo periods and they (understandably) just didn't purchase the software when nobody seemed interested in what they had to say about Low Latency Monitoring issues.
When 3.5 came out a handful of users tried to notify PreSonus about the curious CPU behavior of the double buffer system. Apparently back then it was a waste of time too. Not surprising since it was the main selling point for the Quantum.
In my opinion Studio One runs best when dropout protection is at Minimum and the device block size is balanced for the specific system, its tasks and the user's expectation. Like how it was prior to the whole double buffer thing.
niles wroteWhen 3.5 came out a handful of users tried to notify PreSonus about the curious CPU behavior of the double buffer system. Apparently back then it was a waste of time too. Not surprising since it was the main selling point for the Quantum.
I agree but I’m still going to keep using Dropout Protection. It is a flagship feature and there is room to improve it, even though it is surely annoying to them that we’re not all just using Mai Tai and Presence exclusively Apparently from what the OP says the similar schemes in Logic, Pro Tools, and Cubase work better and do a similar thing.