The strangest prank SONAR has ever played on me

Author
bitflipper
01100010 01101001 01110100 01100110 01101100 01101
  • Total Posts : 26036
  • Joined: 2006/09/17 11:23:23
  • Location: Everett, WA USA
  • Status: offline
2012/06/06 13:04:31 (permalink)

The strangest prank SONAR has ever played on me

I was listening to an old song the other day and decided that it could benefit from the addition of some percussion, so I pulled up the project, added a half-dozen hits and then saved and exported it. Nothing else was modified, just the addition of a few percussion hits.

So I was surprised when I later played back the file and halfway through the song everything suddenly went to sh*t. Some clips were no longer starting playback at the correct time. Thinking I'd accidentally nudged a clip, I went in to find which track was wacky, but the problem was in half of the 55 tracks. At about the halfway mark, some tracks just went wildly out of sync with the rest of the project.

Then I examined the tempo map. This is a dynamic orchestral piece, so there are several tempo changes. The original tempo map looked like this:




But in the corrupt project, the tempo map looked like this:





Here's what I believe happened. The percussion library I'd added was a home-made Kontakt library, to which I decided to add three new samples while the project was open. When I dragged the samples into Kontakt's mapping editor, the Kontakt UI went all goofy and left a large gray blank spot in the middle of the mapping editor. I closed and re-opened the Kontakt UI and all was well again, so I gave it no more thought.


That's when I saved the project and when it (silently) became corrupted. Fortunately, I had a backup so I renamed the corrupt project, restored the backup and was able to compare the two. I believe the problem occurred because I had exhausted memory while editing the Kontakt library, which somehow corrupted the in-memory image of the tempo map.


Three conclusions: 
1. SONAR doesn't handle low-level error conditions gracefully (no news there)
2. Don't edit Kontakt libraries within a SONAR project
3. Freddie's been right all along: 64-bit does matter!


All else is in doubt, so this is the truth I cling to. 

My Stuff
#1

3 Replies Related Threads

    DPStewart
    Max Output Level: -90 dBFS
    • Total Posts : 15
    • Joined: 2007/11/02 16:31:44
    • Status: offline
    Re:The strangest prank SONAR has ever played on me 2012/06/06 16:11:07 (permalink)
    I get memory-based issues with Kontakt too. And yes it was my primary reason for switching to 64-bit....maybe my only reason.....more so than other sample-intensive players, Kontakt seems to have the ability to inject non-Koktakt errors into other parts of a Sonar project.
    #2
    Bub
    Max Output Level: -3.5 dBFS
    • Total Posts : 7196
    • Joined: 2010/10/25 10:22:13
    • Location: Sneaking up behind you!
    • Status: offline
    Re:The strangest prank SONAR has ever played on me 2012/06/07 12:14:01 (permalink)
    This happens to me from time to time in X1 as well.

    The song called 'Strange Instrumental' that I posted a week or so ago in the songs forum, it is all clips that I had to move around and line up. I closed the project, took a break, came back a couple hours later, fired it up, and everything was in the wrong place. I had to start all over.

    It happens from time to time and I don't see any rhyme or reason to it. All I have on my system are the synth's and VST's that come with X1 Producer. I don't have Kontakt.

    "I pulled the head off Elvis, filled Fred up to his pelvis, yaba daba do, the King is gone, and so are you."
    #3
    bitflipper
    01100010 01101001 01110100 01100110 01101100 01101
    • Total Posts : 26036
    • Joined: 2006/09/17 11:23:23
    • Location: Everett, WA USA
    • Status: offline
    Re:The strangest prank SONAR has ever played on me 2012/06/07 14:55:37 (permalink)
    If it's in fact memory corruption, then it wouldn't have to be Kontakt specifically. Any sample player (e.g. Dim Pro, Session Drummer) could potentially push the memory requirements over the edge as large additional memory requests are introduced mid-project. 

    To tell the truth, I don't know how memory is managed inside a DAW. Because plugins run in the same address space as the host, there is the potential for accidentally overwriting buffers. Pointers can be corrupted, and there is no mechanism for preventing plugins from trashing the host's (or other plugins') memory, like the mechanism that prevents SONAR from trashing Windows (or the game of Solitaire you're playing while waiting for an export to complete).

    These problems, btw, are not necessarily going to be eliminated by going 64-bit and adding gobs of RAM. It'll make it less likely that an internal memory allocation request will fail, but it won't prevent a sloppily-coded VST from trashing SONAR's buffers. 

    What bothers me the most is that when SONAR does write a corrupt .cwp file, there is never any indication that's somethings awry. You might even make a backup of it, unaware that it's trashed, and find yourself really füched. And there are no options or features for salvaging a broken project file aside from Safe Mode. Once it's broke, it's broke for good.
    post edited by bitflipper - 2012/06/07 14:56:48


    All else is in doubt, so this is the truth I cling to. 

    My Stuff
    #4
    Jump to:
    © 2025 APG vNext Commercial Version 5.1