Focusing just on one point in the above:   so many people say, don't draw CC values in PRV, use envelopes.  
 
Ok, maybe.   But hello, nearly every other DAW can draw CC values in their equivalent of the PRV with far fewer really bad design choices.   I've tried to explain several times before why envelopes are not as good, but keep it simple:   other DAWs can draw CC values beautifully, why can't Sonar?    The whole "grab-it-if-close" is a major design flaw, fix it.   Having to set a snap value to prevent too many CC values is a design flaw.  Fix it.   Fixed height segments, same for every controller whether it has 128 values or 8196 values is a design flaw, fix it.
 

bapu

luna004
I draw exquisite CC data 

In cursive?

Is there a problem in Google Translator? =O
 

Anderton

Brian Walton

luna004
Thank you very much guys, I found my cause of the crash. TTS-1 is always my problem. I don't use TTS anymore, and I have no more crash!

That thing came out 11 years ago (2005 or so).  I figure few people use it other than General MIDI.  
 
Not sure why it would cause periodic crashes though.  

Interestingly, I went through a period of a few weeks where having the TTS-1 in a project would cause problems (crashes, freezes). This went away as suddenly as it appeared, and these days I use the TTS-1 without incident.

Well, I'm not sure but I still have not suffered a crash. I will try TTS-1 again.
 
 

williamcopper
Focusing just on one point in the above:   so many people say, don't draw CC values in PRV, use envelopes.  
 
Ok, maybe.   But hello, nearly every other DAW can draw CC values in their equivalent of the PRV with far fewer really bad design choices.   I've tried to explain several times before why envelopes are not as good, but keep it simple:   other DAWs can draw CC values beautifully, why can't Sonar?    The whole "grab-it-if-close" is a major design flaw, fix it.   Having to set a snap value to prevent too many CC values is a design flaw.  Fix it.   Fixed height segments, same for every controller whether it has 128 values or 8196 values is a design flaw, fix it.
 

Thank you my friend. Please strongly request to the main office. I do not know how.

Bristol_Jonesey

luna004

JohanSebatianGremlin
When I want to add a bunch of CC information to a track manually (i.e. without recording a controller move in real time), I drop in an envelope and nodes as needed. Maybe its just me, but I find it quicker, simpler and much more precise than trying to do anything freehand with CC data.
 
I think I'd rather stick pins in my eyeballs than do anything freehand when it comes to CC data.

 
I know a lot of people put a CC using the envelope on the track . But for those who like me, it seems that the best way to enable the envelope in the PRV (like StudioOne). If you draw a diagonal CC line in PRV, unnecessarily large amount of data is consumed.
 

Try messing around with your Snap Settings. I'm pretty sure that with Snap OFF you will get one "node" written for however many  PPQN's  (Pulses Per Quarter Note) set up.
 
Turn Snap on and set it to something like 1/16 or 1/32 and draw your line again.

 
I already do that. Because forced to do so. The real problem is that CC drawing is too uncomfortable.

Post #21 by William Copper is the "best" answer if the definition of "best" is displaying ignorance of the program. See the video below.
 

williamcopper
I've tried to explain several times before why envelopes are not as good, but keep it simple: other DAWs can draw CC values beautifully, why can't Sonar?

 
There's a basic fact about product development that you still don't seem to understand, so I'll keep it simple: Different programs and designers have different priorities, and therefore choose to allocate their resources in accordance with those priorities. 
 
Regardless, Cakewalk did make the improvements you've mentioned ad nauseum regarding variable controller height, not having multiple strips condense height, and not being able to click on an existing value and continue it, when they introduced the inline PRV (please refer to the video below). If you choose not to avail yourself of the solutions Cakewalk offers, then your solution is to use a DAW that is congruent with your unique set of requirements. If you can't find one, use the one that comes closest, then learn how it works rather than demand that it work the way you think it should.
 

Having to set a snap value to prevent too many CC values is a design flaw.

 
I don't understand how that is a design flaw. People often want to snap controllers. Some people want to snap to different rhythmic values than others. I don't know how it's possible to specify a snap value without specifying a snap value. 
 

Fixed height segments, same for every controller whether it has 128 values or 8196 values is a design flaw.

 
The only MIDI controller with 8196 values is pitch bend. I certainly wouldn't want the height of the pitch bend strip to be 64 times higher than the other controllers in the standard PRV.
 
But that's irrelevant, because you can vary the height to whatever you want (well, within the limits of your monitor size) in the inline PRV. Are you not aware that you're not limited to using envelopes in Track View, and that you can draw with a pencil? And that in Track View, "grab it if close" is not an issue, and you can simply draw starting with an existing value and continue it? You're essentially asking Cakewalk for a solution where one already exists. Why you choose not to avail yourself of it remains a mystery to me.
 
I've pointed out the value of using the Track View PRV to you plenty of times. Hopefully seeing what I'm talking about will help you understand. I recommend watching it on YouTube in full-screen mode so you see for yourself that the drawing picks up EXACTLY from the controller's existing value.
 

 

Fix it...fix it...fix it

 
Cakewalk does major updates to sections to address multiple issues at the same time. They will do specific bug fixes for isolated elements, but the kind of things you mentioned (which in light of the video above, are likely a low priority because you're basically asking for another way to do something that already exists) reach into the core of the program. It would be stupid not to deal simultaneously with all the MIDI improvements Cakewalk wants to do (if for no other reason than for the QC process). Even though you repeatedly and gratuitously insult Cakewalk's developers by calling them dumb dumbs and bad designers, I can assure you they are very smart in how they allocate the resources they have...the monthly updates are proof positive of that.
 
For example, people have complained about how splitting stretched clips can produce an extraneous snap point. Now it's fixed. Presumably this is because Cakewalk is working on ripple editing, which involves splitting. So this is a good time to look at all the anomalies that relate to splitting.
 
Your requests may be valid (although in quite a few cases they simply represent ignorance of how the program works) but your attitude is infantile. You do not represent all users, your needs to not represent the needs of all users, and constant complaining in a peer-to-peer forum whose stated purpose is to help people get the most out of SONAR (a purpose you consistently ignore) will not cause Cakewalk to deviate from strategic roadmaps that are plotted out years in advance.
 
Overhauling one aspect of a program often requires making changes in other areas of the program first. Cakewalk will work on MIDI when it's time to work on MIDI. Using the forum as a personal soapbox to lobby for what you want and saying "fix it," as if repeating that mantra will actually accomplish anything, is a waste of your time and more importantly, the forum's time. With all due respect I suggest your time would be better spent reading the documentation.
 
SONAR is not holding you hostage. Stop playing the victim, and use the right tool for the right job. The video above shows what I think is the right tool for what you want to do, and accomplishes the forum's mission of helping people get the most out of SONAR. If SONAR doesn't do what you want, there are plenty of other DAWs out there. The only potential roadblock is that they require some effort spent learning them as well.
 

luna004
Thank you very much guys, I found my cause of the crash. TTS-1 is always my problem. I don't use TTS anymore, and I have no more crash!

 I don't know if this is the problem but this was a DX plugin at one time.  It was great you posted a video of your problem.  Some are here to help while others will not but make a response about your anger.

Most people do not require highly accurate and systematic cc editing. If I had not raised this issue, this issue would not be resolved forever. More than one year has passed raises this issue. Complaints of people who have experienced discomfort similar from becoming increasingly large is a matter of course. They are not bad. Some of the workarounds do not allow the function wrong also that there is attitude, it is just get in the way of development. I think the current PRV is obviously wrong. Alternative way is just alternative way, It can't to be main way because of many disadvantages you don't know. We have the right to continue to transfer the opinion there. I can not be determined that the sentence of William is rude because the performance of the translator is bad. However, he has the necessary claims to us. Apart from this problem, SONAR is the best DAW. That's why I don't leave SONAR.

The reason I originally posted this post, because the issues I wanted to go up even in developed subordinated list. But I do not know whether CW is to care even a little about this issue.

luna004
 We have the right to continue to transfer the opinion there. I can not be determined that the sentence of William is rude because the performance of the translator is bad. However, he has the necessary claims to us.

No one is upset with WC for having opinions, or for refusing to learn techniques that would solve his problems. No one is upset with people who want to see improvements in the program - consider how many changes Cakewalk has made in direct response to user requests.
 
What is upsetting to me and many others is when someone becomes irrational in making the same demands repeatedly, insults the company that provides this forum for the benefit of its users, calls Cakewalk's engineers "dumb dumbs" and castigates them for what in his opinion are "bad designs," exaggerates to the point of people not knowing whether he actually believes what he says, and hijacks threads to insert personal agendas that have nothing to do with the thread topic. (At least WC was on-topic this time.)
 
I think if he stopped using the standard PRV for two weeks and forced himself to learn about the inline PRV in the track view and became skilled at using it, many of his problems would be solved. But I don't know, because he doesn't describe his workflow. He says one problem is that he can't continue writing a controller from an existing value; the video shows he's wrong. He says he doesn't like having controllers appear as thin little strips when there are lots of controllers; the video shows they don't have to be. He wants to be able to adjust the height of controllers as needed; the video shows he can make controllers take up the entire screen if he wants. Yet based on past experience, I'm pretty sure he'll reject those solutions, even though they accomplish what he says he wants. I don't just post these solutions for him, but for others who may not be aware of these techniques, and mistakenly believe WC is correct.
 
 
All programs will have compromises. The job of the user is not to find the perfect program, because such a program does not exist. The job is to find the program that comes closest, and then maintain a constructive, helpful dialog with the developers about how it can be improved. Calling the developers "stupid" and "idiots" in a public forum is not only extremely rude, it will not improve the program. All it does is reveal the mentality of the person making those kinds of posts.
 
I think WC should either find a program that does things the way he wants to the greatest degree possible, or do what the creators of Ableton Live did, and write a program (since he claims to be a software guru, and considers himself an excellent judge of software design) because nothing else served their exact needs. They didn't spend their time in the Cubase forums complaining that it couldn't do (and still can't do) what Ableton Live ended up doing. If they'd chosen that route, they'd still be waiting and complaining...16 years later.