CWBRN-42566

 

williamcopper
Once again, I have to call your response obfuscation, Craig.  I'm hoping it's not intentional, but that's the result.

 
You don't have to call my response obfuscation; you chose to do so, just as you chose to believe that reviews in the eZine were product placement (they're not), and you chose to believe that a moderator marking a thread as "solved" was "doctoring" posts (and you chose to state there were countless instances of moderators doctoring posts, yet when called on it, you could not produce one example). In this case, you should instead choose to call my response what it is - a direct response to specific issues you brought up.
 

Breaking it down a little:  you say, "so I can make the window narrower"   no, the fields are fixed; unless you intend to manipulate a window frame so it shows only part of a fixed field, and then you'll lose the two right-most columns.

 
You were talking about pitch bend. There is no pitch-bend data in the two right-most columns. Next.
 

You say ".. the last thing I want is a dialog box with 127 check boxes".   Did anyone propose such a thing?

 
I did!!! You said: "And the first part brings up another feature (?) of sonar ... you can't choose which controllers to see and which not to see -- there are 127 of them."
 
From this any reasonable person would think you want to be able to "choose which controllers to see and which not to see." I can't figure out a way other than 127 check boxes so you can enable/disable different controllers; I think it would be overly tedious, but it is a solution. If you don't want me to propose solutions, then present one of your own. 
 

You go off on automation and illustrate how selection works in the EL -- ok, but is that relevant?

 
Of course it is, you're the one who brought up controllers (see above). You mentioned wanting to be able to isolate seeing individual types of controller data. I said there isn't a way to do that, but assumed due to your general lack of knowledge of the program that you might not be aware that Cakewalk can "flag" individual controller types in event view so you can see them more easily. So I informed you about this. If you already knew about this, fine, but it sounded like you might not and besides, remember that others also benefit from techniques presented in threads.
 

You say, "there are many ways to view controller data" --- but the particular issue is pitch wheel data, and there is no other way to get the numeric value of the pitch wheel, without going to great lengths to mouse onto every single of thousands of points.

 
Make up your mind whether the issue is pitch bend data (in which case your comment about not being able to see the two right columns with a narrower window is irrelevant) or controller data (which is a topic you brought up). I addressed both as appropriate in the context in which you brought them up.
 

You make parallels between staff view and event list that aren't relevant: sure they should both represent the underlying midi data -- but again that's not the point -- the staff view representation should be appropriate for staff view and the event list representation should be appropriate for event list.

 
I never said they shouldn't. To refresh your memory, you said: "I would bet a great deal that this change to the Event List was a result of those changes, -- unintended, unimagined, and unnoticed --  and because of the long-standing design failure to treat Event List view and Staff view as dissimilar things."
 
They are already treated as dissimilar things - Event view represents MIDI data as numbers, Staff view represent MIDI data graphically. You can say each should be optimized further for their particular task, but to say they were not designed to be dissimilar is ridiculous. 
 

You seem now to be saying this is not a bug?    Unintentional changes = bugs.

 
You really need to learn what a bug is. According to Technopedia, "A bug is a problem causing a program to crash or produce invalid output. The problem is caused by insufficient or erroneous logic."
 
Having the pitch bend data on the left instead of the right does NOT produce a crash and the output is NOT invalid. Besides, we don't know whether it was an intentional change or not. If the display was as Kevin wanted, would you consider that a "bug" simply because he doesn't agree with you about the optimum way to display data?
 

Are there better ways, so I won't criticize and won't build it myself?   Yes, for one beautiful implementation (of how to select among controllers)  take a look at Vocaloid 4 editor. I'm sure there are many better ways in other programs, too. 

 
If you're sure, then describe them. No one is rejecting your solutions for how to display individual controllers...because you haven't presented any. I presented one - checkboxes for each controller - which I don't think is a good solution, but it's what I came up with off the top of my head.
 
Cakewalk is always interested in ways to improve the program, and I'll advocate for solutions if I think they have merit. But if you don't propose a solution for how to isolate individual types of controller data in the event list, I can't advocate for it. Simple as that. I don't have Vocaloid 4. If you are sincerely interested in improving SONAR, you would take a couple minutes to describe what you like about Vocaloid 4; I think it's unreasonable to expect me to to obtain Vocaloid 4, install it, learn how to use, and then try to guess what it is you like about it, based solely on a non-specific opinion. 
 
A solution for a reproducible bug is "fix this." A solution to a UI or functionality issue is NOT saying "I don't like this." A solution is saying "This would be a better way to do things." You would create a much higher level of discourse, and legitimate matters for discussion, if your posts were oriented consistently around solutions to UI or functionality issues rather than simply complaining about things you don't like. I promise that if you try to present solutions I will not accuse you of obfuscating the problem.