I had a Splat crash last night

When you replace a synth it's better to disconnect the old one before the replacement with the option disconnect synth,with some VSTi's or mixed combinatios of them i got the same crash if i don't disconnect the synth to replace.

I too have had a Rapture Pro involved in a Sonar Platinum crash - couple of weeks ago, did not have time to pursue replicating or diving into it.
 
I ALWAYS insert the new synth, then alter midi and audio routing assignments to point audio/midi tracks to the new synth, prior to deleting the old one, and that just seems a bit cleaner to me than doing an actual replace. 
 
The ONLY time I have locked up Sonar was when doing so with Rapture Pro, so given these other crashes, it would appear that something is up that needs some replicating steps and a bug report filed.  If nobody else does it prior to my getting some free time tomorrow, I will put some time and effort into seeing if I can break it and capture some sort of crash recipe that can be passed on to the Bakers.
 
Bob Bone

I do it pretty frequently when auditioning sounds over a drum loop. Never thought of stopping the transport actually...

bitman quote: Splat Crash = Splash.
 
Good one, bitman!

rlared
I just had a crash with Lexington.  Had the transport playing, went to replace Rapture Pro with Hybrid 3 synth and the whole program crashed :(

 
 

robert_e_bone
I guess I too am like Craig - I never do things like that while the transport is playing either.
 
 

Ditto that Bob.
 
rlared, until the engine is re-written to be gapless it's risky business to do heavy duty stuff like replace synths while the transport is running.

However, this begs the question that if this is clearly something that can affect system stability, then shouldn't Sonar block the action while the transport is running?  The responses above, while helpful, seem to suggest that it's OK for Sonar to crash in this instance and I should know better. . . am I misreading this?

rlared
However, this begs the question that if this is clearly something that can affect system stability, then shouldn't Sonar block the action while the transport is running?  The responses above, while helpful, seem to suggest that it's OK for Sonar to crash in this instance and I should know better. . . am I misreading this?

Sonar can actually take quite some abuse and still works fine i.e. you can insert/delete/change FX while transport running (does make sense and I wouldn't want to miss that!!) and actually inserting/deleting/changing a VSTi is not so much different apart from it being harder on your resources (e.g. loading samples,...) although VSTi change I rarely do ...
 
Occasionally I push it too far and get a crash - and most of the time it's actually caused by the audio driver giving up (which I can see from the crash message). So with some drivers more stable and mine not being the best (Roland), it's still working and I would not want to be restricted upfront ...
 
 

Fair enough. I suppose I do need to consider that the system is performing real time calculations when I make changes, so a mindset change will help. No more changing synths while running the transport!