I've gotta defend the op a little here as I've hit AS long render times myself recently (10 tracks of a 5 min song took over 24 hours and I finally gave up). So bad that I had to revert to previously saved copies of the songs, render the tracks to be edited/stretched, and load them into other DAWs (which took about 3 min total). Once edited, reimport back into Sonar. This is the only issue I've had with Sonar in all of the versions that have been a real time killer and aggravation. I do hope in the next update that AS is brought up to par with other programs that are currently on the market.

If you did not make any changes to the audio then of course it is going to take less time to "render" it because there is nothing for the computer to do. Also the fact changing Preferences causes such delays makes this MORE likely to be a system/config issue. Audiosnap has its problems and yes they could be construed as "buggy" but the things you are describing are not "bugs". You are describing what happens when your computer is processing info. From your description here everything did work... it just took a while. When a software program performs the function it is intended to you cannot in any way call it a bug.
 
As far as this forum is concerned it is one of the friendliest, most helpful and forgiving places on the internet. If you are experiencing consistent problems with forum members it is quite possible the problem may lay with you.
 
BTW... I may like Sonar and you might call me a "fan" of the program but I am by no means a "fanbois" as the kiddies like to say nor would I dismiss a new user's problems or questions. In this very thread I have acknowledged potential limitations of the feature you are using as well as offered possible culprits and suggestions in regards to the original question. You have dismissed all of that instead opting to blame Cakewalk and insinuating that I, and anyone else on the forum who has tried to help you, are simply ignorant toadies.
 
You can continue down this path if you so choose but you are only damaging your own chances at a positive experience with the program and this forum.
 
I anxiously await your next thread.

May I just add, Ask yourself how we managed to work out that you are really Teal....  As Beep says none of these are bugs.
If you've got a bug give us exact steps to repro, BTW if something is taking a long time to do, it isn't a bug.
And if you refuse to supply information when asked, we probably will end up taking a leaf from your example.

AS corrupting projects is definitely a bug, give the guy some slack

CakeAlexS

Beepster
The not being able to save projects with open AS clips COULD be considered a bug. I have encountered it and it is annoying. When that happens however the project becomes unuseable.

 
Hmm not heard of this one... Possible to have steps to repro?
I couldn't find Open as clips here. Then again I rarely use AudioSnap.
 
I tried: 
New Project.
Drag a Wav into Sonar to create a new track.
View -> Audiosnap palette.
File -> Save As
 
Cheers Beep.
 
 

To be fair I have not tried this in X3 yet and I've heard reports AS is working better. When I encountered it it was in X2 and I was manipulating about a dozen tracks at once and quite drastically at that (it was the raw waves of a live off the floor recording I did years ago). I was basically trying to stretch all the tracks to somewhat follow a more even tempo.
 
So to reproduce it you would have to...
 
1) Load a multi track project
2) Set all tracks to Transients
3) Make multiple group time stretches across all the tracks
4) With the tracks/clips still set to Transients save the project and close it
 
When I did that (after a looooong session) and tried to reopen the project thinking I could continue doing my adjustments. What happened was the transient markers were either missing or in the wrong places (like the half end of the project had no markers at all and the ones that were there were WAY off). The markers would appear and disappear when I'd move the cursor around the screen (more than the usual graphical glitches transient markers sometimes exhibit). Markers could no longer be moved reliably (they would behave erratically, disappear or not move at all). After playing around with the project for a while trying to force it to continue working large and small square patches of the screen would turn black or graphics would bleed over boundaries (like clips would show up in the track control pane and vice versa). Eventually the project started freezing up more and more and eventually it all culminated into a total crash of the project.
 
Now I pretty much realized the project was gacked after the first five minutes of screwing around with it but wanted to see how far I could push it to see what would happen so I could report it here. I started a thread about it. Basically the workaround/solution is to simply NOT save and close a project you are doing such changes to until you have rendered the AS changes. This in my case means either chopping the project up into clip segments and doing it one section at a time or leaving the computer on with the project open until it is completed or simply spending the time to finish the entire thing before shutting down for the night.
 
As I said though I was really kind of pushing the software and it was in X2 which was giving me all sorts of other problems I do not experience in X3. Still I don't think saving and closing with an open AS session going is a good idea especially if the Bakers said it is known to cause issues.
 
Cheers.

lawp
AS corrupting projects is definitely a bug, give the guy some slack

Check #28, I began to write out steps. If there is an actual bug here I'm all ears... Ta
 
(Ah #28 has just been quoted by Beep, if anybody can repro it in X3E please let me know.. I'm going down the pub).

lawp
AS corrupting projects is definitely a bug, give the guy some slack

That part is a bug. He was talking about long render times and calling it a bug. Bandso says he has encountered this as well though so it could turn out to be that there is a problem that affects certain users when using AS. I have not experienced that one though and I don't see many complaints about it so it's not one of those bugs that can be consistently reproduced. Not sure if there is a different term for that. "Bug Lite"? "Ghost Bug"? "Borg"?
 
I usually just call those intermittent ones gremlins.

200bpm
 
Having read some older posts, there appears to have been a problem with bugs for X3a-d, so I attribute the resistance I'm getting to the loyalists being gun shy; they would rather dismiss a new user's problem than entertain that there is a bug that will impact his use of the product.

 
I believe the resistance you're getting is due to not following community protocols that were established long before you or I joined. There have been posts where what you identified as a potential bug was not a bug, like when you tried to create an instrument by dragging it into a track that had already been created. It's like the story about crying wolf. Do it enough times, and people will stop taking you seriously.
 
The protocol is this: If you find a "bug," give steps to reproduce it so others can help determine whether it is a bug, your lack of understanding of the program, or something that might be system-specific. If a bug is confirmed and can be reproduced, submit a bug report to Cakewalk so it can be added to the list of remaining bugs and prioritized.
 
Note that saying "I loaded a file and it took a long time to render at 24/96" is not sufficient to qualify as steps required to reproduce. In the past, when people have wanted others to check results regarding a particularly problematic file, they post it in dropbox or use a service like hightail.com to provide a link. It may just be that AudioSnap is doing lots of calculations. Or maybe "multiprocessing engine" was turned off somehow under preferences.
 
Some people have reported huge render times where the problem ended up being the floppy disk port enabled on the motherboard in a system with no floppy drive. Someone had huge render times for Kontakt instruments that no one else experienced, and IIRC it turned out to be due to having a blank disk in the computer's optical drive. These issues were found only because no one else experienced them, so instead of being distracted trying to find "bugs" in Sonar that didn't exist, the community (which with all due respect, has a lot of people who are much more savvy about these things than you or I) was able to localize and fix the problem. I doubt anyone will be able to provide a definitive answer to solving your issue based on the information you've provided. If you want a problem solved and cannot figure out how to solve it yourself, you will need to provide sufficient data so that others can solve it.
 
That said, AudioSnap is complex and not trouble-free. I find it far more predictable if I work on individual sections of a file instead of really long files. 
 
People who have been using Sonar for a long time generally agree that X3 is stable by any reasonable standards. This is due in large part to this forum, which is not based on adversary relationships. It is a partnership between the user base and Cakewalk, who both seek to have Sonar be the finest software possible. By the community providing important data, and sometimes even sending projects, Cakewalk's engineers can not only find and track down bugs within Sonar, but compatibility issues with third party software and system-specific issues that would be very hard to find without Sonar getting into the world onto a huge variety of systems running a huge variety of software.
 
Finally, it's amazing how many intractable problems are solved by a clean Windows install. The more programs you install, particularly if they're of the same type (e.g., a bunch of different DAWs), the more likely there will be conflicts with unpredictable results.
 
P.S. It would be helpful if you could give some clues as to what's not in the documentation so others could benefit from your experience with tech support.
 

I'm actually being a jerk. I am trying to be a supportive and constructive jerk though.
 
;-)

Beepster
 I have not experienced that one though and I don't see many complaints about it so it's not one of those bugs that can be consistently reproduced. Not sure if there is a different term for that. "Bug Lite"? "Ghost Bug"? "Borg"?
 
I usually just call those intermittent ones gremlins.

 
My favorite "bug" of all time happened with a Mac. Strange, rare, and unexplained crashes would happen. They were totally unpredictable and so infrequent I couldn't find a common thread. I figured they related to the operating system since the problems occurred with more than one program.
 
I re-installed the OS (very easy on a Mac) and thought the problem was solved, but it came back. Someone suggested I check my RAM, so I did that but the test program gave my RAM a clean bill of health. I swapped out some other hardware components and still, the occasional crash would come back eventually.
 
The person who suggested the RAM test asked if that had solved the problem. I said no. But he said I was using the wrong kind of RAM test, because it needed to occupy some of the RAM and that couldn't be tested. He turned me on to a program you had to load on a USB stick and run from the Mac's Command Line Interface. Sure enough, there was a RAM stick with a defect. I replaced it and the crashes never came back.
 
The other hardware problem I really hate is when a hard drive starts losing sectors...