luna004
Sorry to say, but till proved otherwise (and that happens periodically, but under rather special conditions), the reason in UNKNOWN. Many people I using Sonar without (or close to without) freezes. If Sonar would be the reason for everyone random stops, do you think people will keep silence?
Actually, people don't keep silence. So many people complain of freezes, but they do not get a satisfactory answer. In my experience, Sonar is too short a period to occur freezes compared to other DAW. Most people suffering from this problem is to consider only issues to bear in order to use Sonar..
I do not know either you are writing DX/VST plug-ins, I do. And I know how fast I can freeze/crash Sonar from any of them, just small typo... just forgot to update one single character in the source. Sometimes the freeze happens months after I use the plug-in (every day), just because I was not using that (rare) combination which trigger it.
Basic Sonar code is the only common part which is executed by >>10k of users every day. If there is a bug here, 100s of users will hit it every hour! And there is not "so many complains" now (compare with first days after initial Rapture Pro release).
But count the number of different plug-ins you are using inside your project. How many people are using exactly these plug-ins, exactly on the same Windows + libraries version, exactly with the same settings inside the plug-in, with the same audio interface, with the same buffer settings (yes, that also influence each plug-in stability)?
Most probably you are completely alone! So, in case there is a bug in that, you will be the only one who observe it.
That is why the first reaction on such report is an advice to check your system for the reason. And not because an army of "CW fan boys" are babysitting this forum. I have looked you video to check either I can reproduce your bugs and so confirm them to escalate and may be get them fixed, and not to complain to you.
RexRed
I would like to chime in on this, I am not sure what causes this really but my Cakewalk only has constant crashing problem on Sundays.
When I have something wrong with Sonar and check system logs afterwards, normally I see some system activity at that time. I can not say that happens Sundays only
"Problem 1" is in fact periodically annoying, but
"Problem 2" is rather hard to reproduce and
"Problem 3" you generate yourself by drawing CC changes without quantization (intention?)
Free hand draw tool is used to very often through to shortcut. If you felt that "Problem 2" is hard to reproduce, you probably not use free hand draw tool in CC window.
I in fact prefer track automations with CC over CC editing in PRV. But I have specially tried to reproduce Free hand problem in my Platinum yesterday, and I could not. The cursor stay as a pencil even when over old values (and function as such). Can it be some setting? I do not know.
Note that I can reproduce that in X2 and that is bugging me when I use it. But that is a "discontinued" version.
And "Problem 3" tells the more CC data that the PRV is more slow. This is not normal. I draw exquisite CC data every orchestra instruments, In the most common tasks, the PRV is slowed irritate me. My computer is the latest specification including VGA.
Especially in case of complex material, with many CCs, I recommend "snap" (quantize) CC changes to reasonable (maximal) value to avoid extra MIDI data. Sonar allows you to draw ridiculous amount of CC data, which is:
a) more then old conventional MIDI hardware equipment can transfer (no more then ~1000 MIDI events per second)
b) much more then any real controller can produce (if you use it life)
That in fact has several consequences:
1) which you already observe, slow editing
2) which you MAY BE also observe, (some of ) your plug-ins can be not prepared to process that information correctly, causing unusual behavior or even Sonar crashes/freezes!
3) Sonar's MIDI engine can trigger some unusual combination of something, especially when combined with timed information like tempo changes.
I will go a bit technical here, skip if not interested. VSTi process information in buffer size chunks. Let say you have it set to 256 samples, by 44.1 kHz. That means VSTi is asked to generate ~6ms audio into one buffer. Before that, Sonar send it ALL MIDI information for that 6ms period, including CCs. What then happened is the plug-in author dependent. I think in most cases, the plug-in will just use the last value for particular CC, so effectively ignoring all your "smooth" drawings under 6ms. Other can try to process each change separately, means custom updating VSTi parameter for each event, potentially triggering quite big CPU/RAM activity if implemented incorrectly. Note that plug-ins authors are normal people, they have some expectations what you send to plug-in. And in case you send something they have not foreseen, that can easily trigger a bug. In numbers, 120bmp means one beat is 500ms. Without snap, you can draw with resolution 960 per beat, ~0.5ms = ~ 12 CC events per one audio buffer!If you really need such precise and frequent changes, it is better to use envelopes/oscillators inside VSTi, which was though to be used for such purpose.
More then 10 years have passed since you have created your account
I mean Sonar "Platinum". Or maybe I can't understand your means.
I was just joking, please do not take is personal or serious
Many people come to this forum to complain and posts are started with similar patterns:
1 day old forum account - "I am using Cakewalk since 30 years..."
1 month old forum account - "I am using Cakewalk since 20 years..."
1 year forum account - "I am using Cakewalk since 10 years..."
Sonar Platinum was released 13 January 2015, so it is 1.5 years old. "Nearly two years have passed..." is what has triggered me to start joking. I am a programmer, when something is so un-precise, that make me smile