• SONAR
  • Noel's Blog Post on Enhancements and Bug Fixes Is Now Online! (p.8)
2015/02/10 10:25:51
ampfixer
Maybe.
2015/02/10 10:59:01
Drone7
ampfixer
Maybe.


Thanks for the extremely definitive answer LOL
2015/02/10 11:25:08
Noel Borthwick [Cakewalk]
Drone7
I watched your video. This is one if the weirdest things I've seen in a DAW. Despite the so-called improvements, the whole Sonar graphical methodology looks extremely disconcerting to me. Is this normal Sonar behaviour? I've never seen such a thing. Does Sonar always take time to update the Waveform like this even though the previous interference has been resolved?? I say again, I've never ever seen such a thing in a DAW before. Someone pease tell me if this is normal for Sonar?
 
In my books, I would deem lots of data as a session running 21 realtime softsynths, 10 stereo tracks of audio at 24bit 96khz plus 90 realtime effects plugins, 7 tracks playing-back samples. Would such a session cause this behavior in Sonar with the following PC specs... Haswell Quad Core i7, 16 gig Ram, 2 gig dedicated graphics card, SSD.



 
Weird in what way? Maybe you didn't understand what his video was demonstrating. He is loading a huge high sample rate audio project where the wave pictures have not been yet cached. In *any* DAW when you load such a project it needs to literally read every sample of audio to determine how waveforms have to be displayed. You can try it for yourself - import a large number of big wave files (a few hours in duration preferably) into any daw and you will see it trying to render the waveforms.
 
Also your scenario listed does not constitute any significant disk load. We are talking about a disk streaming optimization here so we need a ton of wave files not synths. So your scenario wouldn't be relevant.
 
I assume Bill's test is similar but what I did was load an audio project at 96K with about 15 GB of audio. When that is done SONAR literally has to process 15 GB of audio data before all pictures are rendered. This process is done in parallel as a background task. In fact many DAW's don't even parallelize this so it would be much slower than SONAR.
In earlier versions this parallel task could interfere with playback causing dropouts. The new design removes this limitation. 
 
When I tested this even a blazing fast Haswell E with 16 cores would drop out. With the new system fix even a slow system is able to handle the workload and wont drop out. Even though most users aren't loading 15 GB audio projects the fix will make their system more resilient to dropouts under disk load. I see this as a huge improvement...
2015/02/10 11:35:44
John T
Noel Borthwick [Cakewalk]
Even though most users aren't loading 15 GB audio projects the fix will make their system more resilient to dropouts under disk load. I see this as a huge improvement...



I'm currently working on a 40gb project, and this has been a godsend.
2015/02/10 11:40:46
Noel Borthwick [Cakewalk]
Whoa
John T
Noel Borthwick [Cakewalk]
Even though most users aren't loading 15 GB audio projects the fix will make their system more resilient to dropouts under disk load. I see this as a huge improvement...



I'm currently working on a 40gb project, and this has been a godsend.




Whoa thats big! Are you noticing an improvement? I bet X3 would be more dropout prone esp pics were generating.
An easy way to test if you don't mind the wait for pictures to regen is to press CTRL-A then right click and open "associated audio files". Then click recompute pictures. Then while its doing that press play - in prior versions you would most likely drop out pretty quickly.
Of course this is a worst case scenario since normally you would have all the pictures precomputed - but you get the picture :) Although even when the pix are available there were still potential disk contentions when seeking the timeline or zooming in a lot, that would be resolved by this fix. It just makes the system more solid.
2015/02/10 11:41:40
John T
I'll give that a try later and report back for the curiosity value.
2015/02/10 12:13:25
Beepster
Does anyone know about that screen jumping thing I was talking about? I dug up the original thread where it was confirmed.
 
Recipe 1)
 
http://forum.cakewalk.com/FindPost/3048475
 
Recipe 2)
 
http://forum.cakewalk.com/FindPost/3048496
 
Confirmation by Dan Cate...
 
http://forum.cakewalk.com/FindPost/3048505
 
Confirmation by CakeAlex...
 
http://forum.cakewalk.com/FindPost/3048604
 
Sorry to belabor this but it's one of the very few things that consistently irks me in X3. Very distracting. If it's been fixed, awesome. If not I'll submit an official report so hopefully it will be fixed before I get a chance to upgrade (probably this summer).
 
Just if anyone (Baker's or users) has a chance to check it out.
 
Thanks.
2015/02/10 12:16:29
Splat
Just to add to Noels workload I've PM'd him a project to test if possible... Things must be busy...!
2015/02/10 12:29:06
Beepster
CakeAlexS
Just to add to Noels workload I've PM'd him a project to test if possible... Things must be busy...!



For the screen jumping? Nah, you must mean for something I missed upthread. It's pretty easy to reproduce and I'm not sure why I haven't seen more reports about it. I guess maybe I work in a weird way or something.
2015/02/10 17:51:35
Splat
Nope unrelated...
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account