78 postsPage 2 of 4
1, 2, 3, 4
bailatosco wrote
robertgray3 wrote
(Good thing is we are past the dark ages of this forum, when this kind of thread would get deleted)


Wait, I missed this. There was a time when Presonus would delete threads? Holy crap, that is so shady :|

Presonus Featured Artist (Italy)
My Latest Feature Requests :arrow:
https://answers.presonus.com/73692/s1-essential-feature-plugin-racks
https://answers.presonus.com/72506/zoom-to-selection-improvement-vote-if-you-agree
Studio One Pro 6
Win10 - AMD Ryzen 9 5900X - 32gb ram DDR4
Gigabyte RTX 3060
Interface: Focusrite 18i20 3rd gen
Prophet XL + KeyStep Pro
Atom SQ
Revelator
User avatar
by robertgray3 on Fri Apr 30, 2021 1:30 pm
bailatosco wroteIt may sound harsh but I think after all this time the only thing left to do is to keep this kind of threads alive and hope that at some point the developers take a look at what the hell is happening in the code that produces this behavior.


Hope this doesn’t sound harsh but a thread alone is not going to fix anything. There was a long thread a while ago with tons of pages going on and on about an issue and what appeared to get it fixed was one user finally narrowing the issue down to a simple condition, not pages/years of posts, articles, and bumping.

The problem with this issue is it a) is not common, b) seems to occur in “real mix” projects only [ie not well suited to a one track “here’s your problem” song] and c) is not present in other programs so the people that get unlucky and have this issue tend to ditch the program pretty quick.

The closest I’ve seen to this getting reproduced and fixed was a couple years ago two users were helping Presonus nail it down. One of them was on a 30-day demo of Pro, the other was a longer term user, and they both got tired of dealing with it and switched DAWs. I don’t blame the users one bit, it’s totally understandable, but from my experience helping other companies find and fix bugs that’s just the way things go.

Mac OS X Catalina 10.15.7
Mac Pro 6.1
3 GHz 8-Core Intel Xeon E5
32 GB 1066 MHz DDR3
Dual AMD FirePro D500 3072 MB
Quantum 2
User avatar
by bensizer on Sat May 01, 2021 6:16 am
webhamster wroteI've wondered the same thing. I can't imagine Presonus instructing their support team to avoid bug reports this way.


I can, sadly. I reported a separate bug with a clear test case to them a few months back and I kept getting useless replies from their customer service telling me I should just do something different which would have changed the whole output. It was only after many frustrated replies and trying to alert other employees of my problem that they finally took me seriously. And by "take me seriously" I mean "tell me that they've mentioned it to a developer, and to keep an eye on patch notes to see if it ever gets fixed".

I also had a problem related to automation, in that automation in a Song isn't always rendered correctly when mixing down from the Project view. Possibly related to the issue in this thread. Customer service just told me "It is best practise to use the Song view to fully render the audio" even though that is the exact opposite of one of the supposed key benefits of Project view. Then they demanded to see a list of all the software installed on my system "just in case" it was interfering, which is ridiculous. I escalated my ticket to a manager who just said I should switch to realtime processing.

So sadly I can believe that they're just not that interested in addressing this. I'm unlikely to switch DAW any time soon but I'm not buying any of their other products until customer support improves.

[Windows 10 64bit | Studio One 6.2 | Focusrite Clarett 4Pre | ESP Ltd EC 1000 | Line 6 Helix | Novation 61SL Mk III]
User avatar
by kisnou on Sat May 01, 2021 7:33 am
I can share a similar experience. When the Atom SQ used to freeze Studio One, I had to create 3 tickets (over the course of 2 months) to finally get the reply 'This bug will get fixed in the next update'.
It just feels like they treat us like kids, when I have years of experience on my back. It's really not good for Presonus. I will probably make a video about this whole mess and let other people know about it for sure.

Presonus Featured Artist (Italy)
My Latest Feature Requests :arrow:
https://answers.presonus.com/73692/s1-essential-feature-plugin-racks
https://answers.presonus.com/72506/zoom-to-selection-improvement-vote-if-you-agree
Studio One Pro 6
Win10 - AMD Ryzen 9 5900X - 32gb ram DDR4
Gigabyte RTX 3060
Interface: Focusrite 18i20 3rd gen
Prophet XL + KeyStep Pro
Atom SQ
Revelator
User avatar
by Lokeyfly on Sat May 01, 2021 3:47 pm
bailatosco wrote: "It may sound harsh but I think after all this time the only thing left to do is to keep this kind of threads alive and hope that at some point the developers take a look at what the hell is happening in the code that produces this behavior."


Just adding to Robert's point, all the visibility in creation to this issue (and I don't wish to minimize this one) is unless there is a concrete scenario and/or fix that has been verified repeatedly, and is clear, there won't be much done.

As the thread started with many of us experiencing one time or another automation failure at some point not working via mixdown, or stemming, I have not ever encountered that. In fact, going over fixes where I had to fix 0 1 dB peaks via automation Studio One hasn't missed a beat, either due to internal 32 bit FP processing (now 64 FP), AD/DA conversion, etc. Or through effects processors, if my metering showed 0.2 dB over peak, or converting audio or mixing down, and I resorted to a highest peak trimmed to 0.3dB right from automation, the result was the expected 0.1 dB under. Always! I know that's cutting it close, but the point is on several computers using Studio One, I've never seen automation accuracy error, and cutting audio with expected results happens I'm my experience reliably at one-tenth dB accuracy effortlessly. Real time prosessing had no difference unless CPU resources where so close to being potentially problematic such as above 80%. That was most likely mentioned directly by support.

Given that, there are a number of issues to check either from sends, phase issues potentially increasing or doubling a signal and getting +3 dB right from that alone, or related clock issues causing jitter (which screw with D to A conversion. It wouldnt mean there's some behavior via code to fix anything. Interfaces clock differently and thats often a potential issue. To think that if a thread remains visible is going to fix a difficult to uncover issue, is likely not going to happen.

Hoping you whittle down the variables just the same and you get it resolved. If I had such any automation failure, I'd have NO problem sharing it.

S1-6.2.1, HP Omen 17" i7 10th Gen, 32 GB,512 GB TLC M.2 (SSD),1 TB SSD. Win10 Pro, Audient iD14 MkII, Roland JV90, NI S49 MkII, Atom SQ, FP 8, Roland GR-50 & Octapad. MOTU MIDI Express XT. HR824, Yamaha HS-7, NS-1000M, Yamaha Promix 01, Rane HC-6, etc.

New song "Our Time"
https://youtu.be/BqOZ4-0iY1w?si=_uwmgRBv3N4VwJlq

Visit my You Tube Channel
https://youtube.com/@jamesconraadtucker ... PA5dM01GF7

Latest song releases on Bandcamp -
 
Latest albums on iTunes

All works registered copyright ©️
User avatar
by JimmiG on Sun May 02, 2021 11:39 am
In 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.

The bizarre workaround is to "shake the box" - if you keep moving the progress window around continually during export, it won't freeze, and automation most likely will render correctly.

There are also certain plugins where automation simply doesn't work with offline rendering, in any DAW. One example is Izotope Vinyl, which has problems with automation in other DAWs too, like Ableton and Cubase, requiring you to use realtime recording.
User avatar
by Lokeyfly on Mon May 03, 2021 6:27 pm
webhamster wrote
robertgray3 wroteYeah but how CPU intensive? You said 100%. That’s asking a little much.

Why would that be asking too much? It didn't used to be a problem, even if it was a 10.000%. It just takes a bit (or a lot) longer.

It looks like, and I will need to try this on more projects, that a simple 'fix' is to keep moving the rendering 'countdown' dialog. Somehow that seems to keep it alive (and appears to render the automation as well).


Again, I have to side on a very legitimate point made (and was exactly my thought before reading this). No it never was that way with Studio One. 100% cpu is plain and simply a place you don't want to be when monitoring, or mixing down, or stemming. The onus isn't on Presonus support for telling you to render in real time first. The onus is on the user to resolve ways of either gaining back CPU from their system. One way is to pre render some of the more resource demanding plugs or instruments. How much? I don't know as its different among one's specs, tracks, and system demands. To think well, it use to work at 100% is not any legitimate path in fixing your issue.

Let's perhaps discuss and shave ways of skimming that very high load. A lot of folks here can help with that. If throwing a target CPU percentage out there, I'll go with 60%-70% at playback, max
Because that will likely rise during the processing. Real time processing will help, in maybe as much as 20% CPU and co processing, may still produce spikes, and fail the mix again, as you're nearing 100%.

Really meter check you're performances throughout, first. Keep weighty effects such as look ahead compression/limiting, and multi band compression. In check. Pre render is only going to help, so I hope that sinks in, and gets you to some reliable mixes.

That was my point earlier about shaving one-tenths of a dB. That becomes achievable with less strain on resources. That is in the 40+ stereo track area, with both Instruments, external MIDI, Audio tracks, and all effects running on a 7 year old laptop. So I'm not talking wonder PC (though I have a newer PC now).

Suggestion: you needn't render every track to gain back a good portion or CPU resources. Open the CPU meter. Open all plugins by checking expand plugins box. Sort the CPU column to.show highest at the top. It's likely only a few tracks are drawing perhaps 15% to 20%. Those are the few to render a track with. That should almost immediately cut 30 to 40% off the CPU. Then you're good to go. Make a copy of the song you just rendered parts with for any track recall. Though you don't have to, it's a little insurance.

Lastly, I'm convinced with a little track cleaning, you won't need to worry about real time, spikes, or having to "keep moving the rendering 'countdown' dialog.".

S1-6.2.1, HP Omen 17" i7 10th Gen, 32 GB,512 GB TLC M.2 (SSD),1 TB SSD. Win10 Pro, Audient iD14 MkII, Roland JV90, NI S49 MkII, Atom SQ, FP 8, Roland GR-50 & Octapad. MOTU MIDI Express XT. HR824, Yamaha HS-7, NS-1000M, Yamaha Promix 01, Rane HC-6, etc.

New song "Our Time"
https://youtu.be/BqOZ4-0iY1w?si=_uwmgRBv3N4VwJlq

Visit my You Tube Channel
https://youtube.com/@jamesconraadtucker ... PA5dM01GF7

Latest song releases on Bandcamp -
 
Latest albums on iTunes

All works registered copyright ©️
User avatar
by JimmiG on Tue May 04, 2021 4:05 am
The point is Offline rendering should be using as much of your CPU as possible. If it's not using 100%, it means it's not processing as fast as it could. E.g. if your project used 25% normally during playback, it should be able to render at 4X faster than Realtime, using 100% of the CPU in theory. If you artificially limit the CPU usage to 50%, it's only going to render at 2x faster while half your CPU just twiddles its virtual thumbs.

Also, less than realtime speed shouldn't be a problem when doing Offline rendering, because it's Offline rendering. If your computer can't manage playback at all, you should still be able to render at e.g. 0.7X Realtime, using Offline rendering, with no glitches or errors. Offline rendering (if coded properly) should not be dependent on timing or being able to playback in realtime.

It's the same in 3D graphics rendering. Some of those Pixar movies take months to render for just 1.5 hours of animation, because no computer exists that could render those sequences in realtime... but that's OK, because it's Offline rendering.

Of course due to the serial nature of some audio processing, it will never scale perfectly like that, but the point remains. You *want* a high CPU usage when doing Offline renders because it means it's using as much of your CPU as possible to increase render speed. No point having parts of your CPU idle just because some poorly coded section of the DAW loses sync and drops automation otherwise.
User avatar
by Lokeyfly on Wed May 05, 2021 3:06 am
@ JimmiG. I'm not sure about points youre making. Processing faster is not eliminating automation error which is the root of the discussion.

How did the nead to fix webhamster's (OP') automaton error  change from  having or being near 100% CPU load on resources, move to your point (JimmiG) about reaching 100% CPU otimimum efficiency?
I'm also not linking automation failure to your point about "shaking the box". I suspect you're preventing an error message, but we likely are arriving at an automation fix, from two very different ways. Agreed, 4x processing speed should be about the rate when rendering.

I'll hold off on any points until the OP is clear about what occurred during their automation failure, and some CPU percentage they had during such failure(s). Some of us have haven't had automation error occur if CPU load is not high. So numerous suggestions have been made to prevent that.

@webhamster - Please state what happened during you're automation failure(s). Not what support said because there still needs to be clarity to assist helping with your issue. Thanks!

The point made by support was real time, based on high CPU load. Let's move on to root cause.

S1-6.2.1, HP Omen 17" i7 10th Gen, 32 GB,512 GB TLC M.2 (SSD),1 TB SSD. Win10 Pro, Audient iD14 MkII, Roland JV90, NI S49 MkII, Atom SQ, FP 8, Roland GR-50 & Octapad. MOTU MIDI Express XT. HR824, Yamaha HS-7, NS-1000M, Yamaha Promix 01, Rane HC-6, etc.

New song "Our Time"
https://youtu.be/BqOZ4-0iY1w?si=_uwmgRBv3N4VwJlq

Visit my You Tube Channel
https://youtube.com/@jamesconraadtucker ... PA5dM01GF7

Latest song releases on Bandcamp -
 
Latest albums on iTunes

All works registered copyright ©️
User avatar
by wdkbeats on Thu May 06, 2021 3:24 pm
Lokeyfly wroteI'm also not linking automation failure to your point about "shaking the box". I suspect you're preventing an error message, but we likely are arriving at an automation fix, from two very different ways.


Actually, "shaking the box" is the only way to have automation rendered during an offline export. I discovered this a few years ago, reported it too many times to even remember and finally gave up. Presonus' support is an embarrasment and a laughing stock. Years later this bug is still there and I'm still "shaking the box" during export every 20 seconds whenever I'm using Studio One (very rarely, fortunately).

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
User avatar
by bailatosco on Thu May 13, 2021 8:07 am
robertgray3 wroteHope this doesn’t sound harsh but a thread alone is not going to fix anything. There was a long thread a while ago with tons of pages going on and on about an issue and what appeared to get it fixed was one user finally narrowing the issue down to a simple condition, not pages/years of posts, articles, and bumping.


No harshness here brother. Yes. I know, I know, but I just think this is a special case bug... and I think you agree with me on your next sentence: it's an atrocious bug, one that makes people like me just ditch the DAW altogether (even tho I really really like it).
And I sure did my fair share of trying to reproduce it back in the day (2016 I think), so I'm done with that.
I'm sorry if, for some people, this just seems like littering the forum for no reason. I don't think it is... it's just keeping this 6 year old problem in the spotlight so maybe (big maybe) they are forced to take a look at it.
Sometimes things get hard and you can't expect the paid users to do the work for you.

Lokeyfly wroteAs the thread started with many of us experiencing one time or another automation failure at some point not working via mixdown, or stemming, I have not ever encountered that. In fact, going over fixes where I had to fix 0 1 dB peaks via automation Studio One hasn't missed a beat, either due to internal 32 bit FP processing (now 64 FP), AD/DA conversion, etc. Or through effects processors, if my metering showed 0.2 dB over peak, or converting audio or mixing down, and I resorted to a highest peak trimmed to 0.3dB right from automation, the result was the expected 0.1 dB under. Always! I know that's cutting it close, but the point is on several computers using Studio One, I've never seen automation accuracy error, and cutting audio with expected results happens I'm my experience reliably at one-tenth dB accuracy effortlessly. Real time prosessing had no difference unless CPU resources where so close to being potentially problematic such as above 80%. That was most likely mentioned directly by support.


Glad it works for you! :thumbup:
Just to clarify, this is not about automation rendering inaccurately, it is either rendered or not rendered.

Lokeyfly wroteLastly, I'm convinced with a little track cleaning, you won't need to worry about real time, spikes, or having to "keep moving the rendering 'countdown' dialog.".


In my case it doesn't seem to be related to CPU consumption.
Earlier in the thread I mentioned a post-production project that was at 60% at the time of mixdown and didn't render properly no matter what I tried. Window freezing thingy happened, of course, shaked it, of course, exporting went ahead but automation was not right.
By the way, try staying at the computer moving the window every 30 seconds or whatever FOR A 46 MINUTE MIXDOWN, every damn time you have to export. Pretty fun, ha. The project is already divided into 2 parts, can't do more than that.
Oh but you know what I did? I got it to 37/40% consumption by rendering some event fx and stuff, and the result was exactly the the same.

Intel i7 - 11700k 5.0Ghz / 32Gb RAM
WIN 10 Pro 64bit
Studio One v5.4.0 Professional
Presonus Studio 192 USB 3.0
User avatar
by jsljustin on Fri Jun 04, 2021 9:18 am
Insert text here.
Last edited by jsljustin on Fri Jun 04, 2021 12:45 pm, edited 2 times in total.
User avatar
by robertgray3 on Fri Jun 04, 2021 10:18 am
jsljustin wroteI am surprised if others think this is a rare issue.


I am not, since there are something like 100,000+ Studio One users and the threads about it tend to attract 10-20 commenters (plus I've never seen it). There was an issue when using the DAW disconnected from the internet in 4.0.0 and there were social media comment sections with hundreds of people commenting in the first 2 days.

Not saying it's not a real issue, I'd love to see it fixed but what tends to happen is people who have it have it all the time switch to realtime or use another DAW and move on. I'm not blaming anyone- getting to the root of rare issues is not fun at all but unless somebody does it it's just up to luck and hoping the next large change in the audio/automation engine fixes it by accident.

Add to that the fact that I've never personally seen an audio company contract with firms whose job it is to find these issues like Fortune 500 companies do and it's a real mess for a select group of users. G'luck!

Mac OS X Catalina 10.15.7
Mac Pro 6.1
3 GHz 8-Core Intel Xeon E5
32 GB 1066 MHz DDR3
Dual AMD FirePro D500 3072 MB
Quantum 2
User avatar
by Lokeyfly on Fri Jun 04, 2021 11:26 am
jsljustin wroteJust to validate what others have said here, I first noticed automation issues in S1 when doing non-realtime exports many years ago.

For me, sometimes automation simply didn't work, or I had other issues, like pops and clicks at the automation points; such pops and clicks were not present during playback, and were present when doing offline (non realtime) exports.

The only fix (and I think I did contact support, but it was many years ago now) was to only export using the realtime rendering option. I don't know if this issue ever got fixed, to be honest, I use a fair amount of automation in my mixes, including plugin parameter automation, plugin mix automation, plugin bypass automation, etc, and I only ever export now using realtime rendering.

I never heard this issue got fixed, and I am surprised if others think this is a rare issue. Automate enough parameters, particularly plugin parameters, and try an offline export. I'd be surprised if this issue doesn't present itself to you, unless it has been in fact fixed since.


In all due respect, I don't believe you're validating anything.

Some good folks take some time to proof out an issue, or provide an answer here in the forum. Just because we can't duplicate the issue doesn't mean you don't have one. Obviously, some, the OP, and yourself are experiencing an issue. So to help that cause be resolved, I'd recommend something here which at least I'm seeing as a potential snag in this thread. Please don't shoot me as I'm only the piano player. ;)

1. There is none, not one description in this thread of what "automation" is failing, nor any real description of by how much, where, how mixed down, were there dropouts by some dB, at the beginning, middle end (it can point to something)? While that might not be easy to present, verbally or by pictures as it's been said to vary, I don't see one real example, period. Even though it's been asked to provide some detail, sample, something. Even a semi worthy descripion. Not asking for a case study, but c'mon guys. If there was more detail, and less emotion of who is ignoring, or company's reputation percentages, someone might and I believe would, assist as best to resolve what seems to be a genuine issue.

It seems we have a half story from the OP who never detailed what exactly failed, or what form of "automation" failed. But they were quick to quote what support stated. That just prompts more emotion. Not resolve.

FWIW,  I ran five very dense high track count songs with a huge amount of automation, each song mixed down in both both real time, and  multiple (4.6:1). I then compared the two of each song by inverting phase. Both listening inside and outside of Studio One. File type was non compressed. All songs revealed NO hint of out of phase relationship (leakage). Thus proving accuracy of real time vs accelerated  rendering. That same test also up roots any automation error quite instantly.

That is not to minimize or disprove anything, but to show through the course of our workflow, we as fellow users help check for use guyz. Hey, perhaps we might find an issue ourselves and it didn't take long as I was in the process of mixing down and stemming multiple songs anyway. This done on two different computers.

Hopefully someone can state in some detail, (i.e. if you were the using Pipeline  (which would require 1:1 mixdown conditions) and some actual information to bite into. Particularly, what automation??? How the automation was set, to what? Mains? Etc.
Best of luck. I'm sure that won't stop the flow of emotion, best left for the music, but I think there needs to be more detail throughout this thread, besides coming from those that tried to help. Good luck.

I almost fell off the chair when I read to automate enough parameters, as possible to see the cause. Many of us are automating into the stratosphere without issue.

Please try and present detail. Not how long its been or this ??? should have been fixed, maybe, etc. , and if the situation is truly the same as others. Takes describing it, to best resolve it.

Peace though.

S1-6.2.1, HP Omen 17" i7 10th Gen, 32 GB,512 GB TLC M.2 (SSD),1 TB SSD. Win10 Pro, Audient iD14 MkII, Roland JV90, NI S49 MkII, Atom SQ, FP 8, Roland GR-50 & Octapad. MOTU MIDI Express XT. HR824, Yamaha HS-7, NS-1000M, Yamaha Promix 01, Rane HC-6, etc.

New song "Our Time"
https://youtu.be/BqOZ4-0iY1w?si=_uwmgRBv3N4VwJlq

Visit my You Tube Channel
https://youtube.com/@jamesconraadtucker ... PA5dM01GF7

Latest song releases on Bandcamp -
 
Latest albums on iTunes

All works registered copyright ©️
User avatar
by stefanrauch1 on Sat Jun 05, 2021 12:46 pm
For everyone who has not yet come across this issue, this is how it looks like:
phpBB [video]


I'm working on making it reproducible. A very time consuming task... every try takes at least 30mins!
With this example, I don't need the audio files for the error to occur, which is a good thing because the original project is >30GB large. I put a small LTC Loop on one of the tracks, and created a Volume Automation on the Print Bus to make the moment at which Automation stops being rendered very easily visible in the resulting file.
I also don't need a maxed out cpu, just a healthy length of render range.
As soon as I try to reduce the plugins down to a commonly used bunch though, the issue goes away. And that makes it impossible to be reliably reproduced on other systems for now.

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
User avatar
by saekone on Tue Oct 12, 2021 5:40 am
JimmiG 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.

The bizarre workaround is to "shake the box" - if you keep moving the progress window around continually during export, it won't freeze, and automation most likely will render correctly.

There are also certain plugins where automation simply doesn't work with offline rendering, in any DAW. One example is Izotope Vinyl, which has problems with automation in other DAWs too, like Ableton and Cubase, requiring you to use realtime recording.


Fuuuu…. This actually worked. Now I won’t trust the export unless I move the dialog box around :(. Anyone else experience this ?
User avatar
by stefanrauch1 on Tue Oct 12, 2021 6:07 am
Yes, I do occasionally on larger projects.
The error (and even a way to reproduce it) is known and it is recognized as a bug.
But unfortunately this does not mean that there is something being done about it.

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
User avatar
by bailatosco on Tue Oct 12, 2021 7:16 am
stefanrauch1 wroteFor everyone who has not yet come across this issue, this is how it looks like:
phpBB [video]


I'm working on making it reproducible. A very time consuming task... every try takes at least 30mins!
With this example, I don't need the audio files for the error to occur, which is a good thing because the original project is >30GB large. I put a small LTC Loop on one of the tracks, and created a Volume Automation on the Print Bus to make the moment at which Automation stops being rendered very easily visible in the resulting file.
I also don't need a maxed out cpu, just a healthy length of render range.
As soon as I try to reduce the plugins down to a commonly used bunch though, the issue goes away. And that makes it impossible to be reliably reproduced on other systems for now.


THANK YOU SO MUCH for taking the time to do this man.

(EDIT) by the way: this CAN happen in a 3 and a half minute song too.

Intel i7 - 11700k 5.0Ghz / 32Gb RAM
WIN 10 Pro 64bit
Studio One v5.4.0 Professional
Presonus Studio 192 USB 3.0
User avatar
by leosutherland on Thu Oct 28, 2021 10:26 am
This be a reply regarding the OP - not any other errors reported in this topic :P

I have a 22.5 or so minute long piece I'm trying to do a mixdown of. So doing this NOT in real-time, and for MP3 and WAV, I found that a lot (if not all) of the fades were not present ie. at least volume automation had not been rendered - I assume that this would apply to any other automation, though volume is the easiest to have a look/listen at, so I didn't check things like pan, for example.

I did the same only this time in real-time - this produced the same result.

Then I did the same real-time as before, this time shaking the dialogue all around, doing the hokey-cokey - to say doing this for 22.5 minutes proved to be tedious is an understatement :D Also, more importantly, I found the resultant WAV (in this case) was only 8.5 minutes long, and sounding like it had chunks missing out of it :shock:

In the end, it occurred to me that I should transform all tracks to audio - I could see that the fades were all working, and could hear them when I played through the transformed song - all good. Then I did a mixdown, not in real-time because I was getting bored, and this time it produced the WAV that I was expecting.

One thing was that, though I had mixed the song and I know there was no clipping going on anywhere (I was running the channels at around -15db or so, having set stage gain to -18db), around half of the events that were transformed reported clipping during the transformation - but there was no evidence of that that I could hear - when I played back the mixdown WAV, everything sound all tickety-boo.

So now I'm reporting back on my adventures, just in case this is of help to anyone :thumbup:

...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
User avatar
by JimmiG on Mon Nov 01, 2021 4:29 pm
bailatosco wrote
stefanrauch1 wroteFor everyone who has not yet come across this issue, this is how it looks like:
phpBB [video]


I'm working on making it reproducible. A very time consuming task... every try takes at least 30mins!
With this example, I don't need the audio files for the error to occur, which is a good thing because the original project is >30GB large. I put a small LTC Loop on one of the tracks, and created a Volume Automation on the Print Bus to make the moment at which Automation stops being rendered very easily visible in the resulting file.
I also don't need a maxed out cpu, just a healthy length of render range.
As soon as I try to reduce the plugins down to a commonly used bunch though, the issue goes away. And that makes it impossible to be reliably reproduced on other systems for now.


THANK YOU SO MUCH for taking the time to do this man.

(EDIT) by the way: this CAN happen in a 3 and a half minute song too.


Agreed, it would be fantastic to have a way to consistently recreate this problem so the SO developers can finally fix this embarrassing bug once and for all. For me it has been way too sporadic, and always happened with big projects with lots of plugins, so it was never possible for me to report it properly to support since they wouldn't have had the same plugins available. What we need is a small project with the minimum amount of plugins and automation to consistently trigger the bug, without needing hundreds of third party plugins active, so it can be sent directly to support. There must be some "magic" combination of conditions that triggers it even in relatively simple projects.

78 postsPage 2 of 4
1, 2, 3, 4

Who is online

Users browsing this forum: No registered users and 63 guests