ampfixer
You've identified bugs that plague you. You've been waiting years for them to be addressed. Sonar won't be improved past this point. You see where I'm heading James? Sonar is now my legacy DAW and I suggest you make it yours as well.

Yes I see exactly where you're headed. "Stop bringing bugs up on the forum because there's no point." However, I still have a stack of projects that I have to complete in Sonar, these problems are making it a frustrating task, and any insight anyone can give me as to what may be causing them is clearly relevant. 

ampfixer
You've identified bugs that plague you. You've been waiting years for them to be addressed. Sonar won't be improved past this point. You see where I'm heading James? Sonar is now my legacy DAW and I suggest you make it yours as well.

Seems a little condescending to me.  Why not bring up bugs on the forum, as others may have discovered work-arounds that you might not know about. 
 
Sharke is a straight-shooter who is having legitimate issues with SONAR.  If he's like me he has a ton of (now for me) legacy stuff in SONAR, and may be trying to finish current projects before figuring out where he wants to go next.  
 
What's the issue with reporting issues here?  If it's not for that, why does this forum still exist?
 

sharke
If however I toggle looping on or off during playback, Geist's sequencer goes out of sync with Sonar's, sometimes to the tune of 16 measures. I bet all these issues have a common root.

Back in the day, all MIDI sequencers had to stop before you could do anything. It was a huge deal when Cubase announced they were introducing a version where you could do many operations while the sequencer was running. It still wasn't perfect but it wasn't necessary to stop for everything.
 
Of course, adding audio complicated things even further. Bear in mind though that this was when 2" tape was common and ADATs ruled the world. People were totally used to stopping and starting tape.
 
Ableton Live and Acid were the first programs to prioritize real-time operation. Both initially had major limitations, like no MIDI. Also note that Ableton Live was built specifically to do real-time sequencing because nothing else was designed for live performance, so the designers built their own program. By prioritizing real-time operation, they allowed creating music in way that really hadn't been done to that extent before.
 
Probably the reason I don't have these kind of sync problems with Sonar is that I minimize the number of operations that I do in real time (for example, I don't insert plug-ins with the transport running). 
 
I'm just speculating here, but the PDC in Sonar is very robust. I've compared it to other programs over the years and it was always way ahead of the rest. Some of the techniques I've written about that involved copying tracks to do parallel processing simply weren't possible with other programs because the tracks didn't line up, or jittered.
 
I think the price of that robustness is Sonar has to re-calculate delays and do compensation whenever a new element (e.g., plug-in) is introduced into the system. When you stop and re-start, everything can line up and start fresh. Looping makes matters worse because now Sonar not only has to recalculate the delays, but match them up to a timebase that's constantly resetting itself.

sharke
My workflow is that I bounce the audio, disconnect the track from the synth and then turn the synth off.

 
I don't think that would be a recommended workflow; you're basically creating orphans out of the synth tracks and the synth itself. Either keep everything connected and just mute the instrument, or archive the track.
 

Synths which are turned off are effectively "archived" though right, or is that something different? 

Very different. Archiving disconnects tracks from the CPU. Otherwise, even if muted or turned off, the tracks remain connected to the CPU because presumably, you want them to return instantly if re-enabled.

Anderton

sharke
My workflow is that I bounce the audio, disconnect the track from the synth and then turn the synth off.

 
I don't think that would be a recommended workflow; you're basically creating orphans out of the synth tracks and the synth itself. Either keep everything connected and just mute the instrument, or archive the track.
 

Synths which are turned off are effectively "archived" though right, or is that something different? 

Very different. Archiving disconnects tracks from the CPU. Otherwise, even if muted or turned off, the tracks remain connected to the CPU because presumably, you want them to return instantly if re-enabled.

 


How do you create an "orphan" out of a synth track? Once I disconnect it from the synth, it simply becomes a plain audio track. Either I can set its input to "none" or my interface - neither should present a problem. It's no different to any other audio track. And what you have left is a synth in the rack that nothing's connected to. Again, that shouldn't cause any problems - I mean isn't the whole point of the synth rack that synths don't have to be paired with one particular track - they can sit there without anything connected, or they can have one or more tracks connected to them. 
 
So I'm still not seeing why that workflow wouldn't be recommended.  Why should turning a synth off cause any kind of issue? It's essential to save CPU in large projects with lots of synths. I have projects with upwards of 30+ synths in them and if I turned them all on, the project would choke immediately regardless of whether anything is connected to them. I've seen CPU usage drop dramatically by turning off synths. 
 
The whole point of me bouncing the audio is because I need that synth audio as a wav clip. I'm then committed to it, and I can edit and manipulate it just like any other audio clip. There is nothing in this workflow that could be replaced by archiving. The only circumstances in which I archive tracks is when I don't need them but I want to give myself the option of getting them back at a later date. I do, however, need the synth audio. 
 
 

The main point I was making was about PDC. I don't have your setup or your problems, so I can only speculate based on what's different. If anything related to instruments is archived, then that takes them out of the picture. I'm also not sure whether you're using simple instrument tracks or not. I never use them so that could be another point of differentiation.
 
It's hard to troubleshoot when I haven't experienced the problem and therefore never found a need to fix it, so all I can do is try to figure out what the differences might be between a setup that doesn't work and one that does. 

Anderton
The main point I was making was about PDC. I don't have your setup or your problems, so I can only speculate based on what's different. If anything related to instruments is archived, then that takes them out of the picture. I'm also not sure whether you're using simple instrument tracks or not. I never use them so that could be another point of differentiation.
 
It's hard to troubleshoot when I haven't experienced the problem and therefore never found a need to fix it, so all I can do is try to figure out what the differences might be between a setup that doesn't work and one that does. 

I think I'm having trouble understanding where archiving comes into it, since archiving is a way of "stashing away" tracks that you don't need but wish to keep in storage without them using CPU. When I turn synths off, it's not that I don't need the audio that those synths create - I do. I just need it as audio clips. I'm happy with the synth part, don't need to tweak it any further and so the audio can be printed and the synth deactivated. 
 
This is true whether you're using SIT's or audio/MIDI pairs, except that when you're using a SIT, there's an extra step involved in reaching your desired goal of an audio track with a printed synth part. You have to split the track to separate the audio from the MIDI. What you do with the MIDI track is irrelevant, but personally I will archive and mute it (just to be sure it's not doing anything) and then hide it. 
 
All this talk, of course, is related to your assertion that this workflow is "not recommended." In fact I think printing synth parts and then turning the synth off is a very common workflow, and one for which I do not see an alternative (if you want to save CPU that is). 
 
As for PDC affecting things, well I guess there was never any real reason for Sonar not having gapless audio other than the fact that it was never implemented. It's certainly possible. Studio One has it. I bought a Bitwig license and put it through its paces with a crazy number of synth tracks and devices running at once, and even with quite a small buffer size, I can pretty much do anything without the audio glitching. Looping is seamless, even with dozens of synths playing, and I can turn things on and off during playback without so much as a hiccup. With Sonar I get audio dropouts while turning effects on or off, and like you I get the sense that you need to reset Sonar by stopping playback before making any changes. This isn't conducive to a good workflow though - sometimes when mixing you need to keep a loop playing over and over without any hitches or interruptions. In Sonar I have to stop playback to so much as turn on a send, because if you turn on a send during playback there's a good chance that the audio in the aux will be slightly out of phase until you stop and start again. I think a Baker confirmed that this was a thing some time ago but that they couldn't do anything about it. 
 
Anyway Sonar has a lot of pretty deep options and preferences, and I have always wondered if there's some magical combination of settings which minimize these glitches. I've certainly never found them. 

Someone who knows the engine better could speak to the on/off in the synth rack, but my assumption has always been that SONAR tracks everything "connected" (even off) since it assumes the user is going to turn it on with the transport running. All of that overhead seems to be included with the transport "now time" processing, especially jumping around the timeline. You can see the same effect jumping between markers with the transport running, but looping can have its own underlying issues apart from jumping markers (or randomly clicking in the timeline during playback). Archiving forces SONAR to release processing, but also guarantees a user cannot "spontaneously un-archive" with the transport in motion.
 
Noel would be the best to speak to that one, but based on behavior I am hard-pressed to believe that SONAR is not trying to "track" a synth that has been shut off in the rack. Put another way... what would be the "expected behavior" if you turned a synth on with the transport running?

I think that I have similar problems when connecting ableton to sonar via rewire. I create a simple loop in ableton drum rack such as 4x4 kick. And sonar chokes every time when I press play button at the loops start. When I try record it to audio in sonar (create audio track and route sound from instrument track with ableton to this audio track) I have similar thing: first kick of recorded loop is corrupt as if 2 DAW do not work synchronously and ableton starting first and sonar recording audio not from beginning.
 
I'm sorry if I made some mistakes. English is not my native language.

mettelus
Someone who knows the engine better could speak to the on/off in the synth rack, but my assumption has always been that SONAR tracks everything "connected" (even off) since it assumes the user is going to turn it on with the transport running. All of that overhead seems to be included with the transport "now time" processing, especially jumping around the timeline. You can see the same effect jumping between markers with the transport running, but looping can have its own underlying issues apart from jumping markers (or randomly clicking in the timeline during playback). Archiving forces SONAR to release processing, but also guarantees a user cannot "spontaneously un-archive" with the transport in motion.
 
Noel would be the best to speak to that one, but based on behavior I am hard-pressed to believe that SONAR is not trying to "track" a synth that has been shut off in the rack. Put another way... what would be the "expected behavior" if you turned a synth on with the transport running?

The problem isn't about turning synths on/off with the transport running, the problem is Sonar not handling synth audio well when a loop is enabled.