- you have all used plugins installed [(Fabfilter Pro-C2 VST3 // Devious Machines Duck VST3] - you have increased/decreased the number of Ampires, so that your offline render speed is between 1.4x and 2x (plugin nap needs to be disabled). After 25 minutes render-time the progress bar will freeze and from this point on the automation is no longer represented in resulting wave file.
Last edited by stefanrauch1 on Tue Nov 02, 2021 4:26 am, edited 1 time in total.
OS: Win10 x64 || Software: Studio One Pro [latest version]
Hardware: AMD Ryzen 9 3950X || Asus Prime X570-PRO || 64GB DDR4 RAM || Asus Dual-RTX2070S-A8G-EVO || UAD2 Octo & Duo PCIe Peripherals: RME Fireface UFX II (+2x ADA8200) || Faderport Legacy || Atom || NI Komplete Kontrol A25 Audio Settings: 44,1/48kHz, 256 Samples, DP Off, 64 Bit |
saekone wroteJimmiG wroteIn my experience, automation failure during mixdown is at least sometimes related to the progress indicator "freezing" during the export. Note that only the progress indicator freezes, the actual export continues in the background and eventually completes. If this happens, it's almost guaranteed that automation will have failed, at least partially. For me, this doesn't happen often, but I've had it happened once or twice. Yes, I've been having this problem since Studio One 3 and I can't believe they haven't fixed it yet after two major version upgrades and numerous minor updates. At this point, I'm not using Studio One for any new projects, nor will I be upgrading to the next major version, unless I see confirmation this is fixed. That said, I can offer this additional observation about the "shake the box" workaround. The period with which you need to move it around varies based on the point the freeze is happening in a particular mixdown. If the freeze is happening 1 minute and 30 seconds into the mixdown, then you can move the box once every 1 minute and 20 seconds and prevent the freeze. It's as if moving the box resets some kind of freeze countdown. And since this workaround seems to reliably avoid the problem, and also since PreSonus hasn't found any other way to fix it, maybe at this point they should just make the box start moving around by itself in a future update. That suggestion would be a joke if the problem hadn't persisted this long, but at this point I am serious. |
williammountney wroteAnd since this workaround seems to reliably avoid the problem, and also since PreSonus hasn't found any other way to fix it, maybe at this point they should just make the box start moving around by itself in a future update. That suggestion would be a joke if the problem hadn't persisted this long, but at this point I am serious. Funny thing is someone actually made a macro that automatically moves the box around, although it requires a third party program to work. Thanks to this workaround, it's not a dealbreaker. However it does make the program feel very unprofessional and it makes you wonder what kind of testing procedures they have at PreSonus and what other bugs might slip through in the future. |
Hi,
About a year or so I noticed that the progress indicator would stop and the update mastering process would seem like it took forever. I also noticed that the progress indicator would start again as mentioned when you moved the box around. Not sure why i did this as there was no indication that the CPU was maxed but I increased the buffer size and the result was - the progress bar didn't stop anymore and the master update was quicker. I'm not saying this will resolve this issue, however, I thought it was an easy thing for someone to try.
Desktop
Windows 10 Pro ASUS X99 Deluxe MB 32G Ram i7 5820K 3.3 GHz ASUS R5 230 Series graphics MOTU 424 PCIe 2408 MK II Studio One Pro 6.01 Faderport 8 M-Audio Keystation 88 M-Audio Oxygen 8 Laptop Acer Nitro Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz 2.59 GHz 16.0 GB Ram SSD and M.2 drives SSL 2+ Audio interface Few Hammonds/Leslies Vintage keys (Rhodes 88, Solina strings, ARP Odyssey, Hohner D6, etc) |
JimmiG wrotewilliammountney wroteAnd since this workaround seems to reliably avoid the problem, and also since PreSonus hasn't found any other way to fix it, maybe at this point they should just make the box start moving around by itself in a future update. That suggestion would be a joke if the problem hadn't persisted this long, but at this point I am serious. Sorry, people - this dialogue-moving-around workaround is NOT actually reliable - it can produce WAV with chunks missing out of it - as I reported previously
...said Halo
Studio One Pro v4.6.2 / v5.5.2 / v6.5.2 Serum, Diva, Repro, Synthmaster, Syntronik Bully, MTron Pro, Kontakt 6/7, AIR synths, Cherry Audio synths, Battery 4, PPG Wave 3.V, Generate 3XS SQ170 Music Studio PC Windows 10 x64 (22H2) i7 8700 Hexcore 3.2GHz, 16GB, 2TB 970 EVO+ M.2 NVMe SSD + 1TB SATA HD Scarlett 2i4 (G2), Korg Taktile 25, Faderport 2018, ATOM Beyerdynamic DT990 Pros, JBL 305P II speakers |
Interesting. There's definitely some kind of race condition that happens during Offline render, which is why shaking the box "unlocks" the stuck thread responsible for reading and applying the automation. It's not surprising that in some cases, this would instead cause the audio rendering to cut out.
Really makes you question the long-term viability of using Studio One for larger projects. |
Sure is. I had a Zoom call with the devs at Tegeler and showed them this ridiculousness, said they were going to contact Presonus directly and get some answers. I've also reopened my ticket with Presonus.
If this issue isnt fixed next patch, along with a host of super basic usability issues (plugins causing freezes because of OpenGL, no FREEZE option with realtime rendering [Pipeline XT], no multi-channel support), and this, I'm finding another DAW. |
firegs wrote That is really bad. I just switched over to S1 as one of my main DAWs and I haven't encountered this bug yet, but this makes we worried about using too many automation lanes. Unacceptable bug. |
stefanrauch1 wroteGood chance of Repro, if So I've rendered the whole thing, in a few seconds, and I can not reproduce the issue. |
If this hasn't been fixed in V6 then it's just an epic fail. This bug has been there since v3 (that's 2015, folks), I reported it a few times and found that it happens only when the rendering window moves to background - the top frame goes white. You have to "shake it" every 20-30 seconds and the mix renders fine. Still, it's an embarrassment for the developers of Studio One.
PC: AMD Ryzen 3900X, 32GB RAM DDR4 3600MHz CL16, ASUS ROG Strix X570-F, Gigabyte Radeon RX 570 8GB, SSD CORSAIR SSD MP510 960GB M.2 NVMe (OS)
OS: Windows 10 Pro x64 DAW: Studio One Professional x64 Gear: RME Fireface 802 + RME Advanced Remote, Prometheus Acoustics monitors, Avantone Mixcubes, JBL 305p, Softube Console 1, Presonus Faderport, AKAI Advance 61, Presonus Faderport, Beyerdynamic DT-990 Pro |
I'll have a look a little later and see if something works since I have 6 up and running well.
Like was mentioned by a mod way back, I also don't use a ton of automation so it's not something that I was aware of. Also, I'm not in need of having to do it w/o "realtime" rendering. Still, if it's still there, EEEEEEEEEK for those who really need this to work! (7 years is just WAY too long) |
I wonder if this in the same realm as midi cc automation not working in an offline bounce. I was doing a rough mix for testing purposes: did an offline bounce and my Hologram Microcosm didn't switch patches and parameters via CC automation.
The Microcosm did all it's CC automation moves when doing a real time bounce. |
Users browsing this forum: No registered users and 64 guests