10Ten

Brandon Ryan [Cakewalk
]
Because it takes design, development and testing time.

It doesn't take dev time to get what you already had. You had already gone 2 years without serious work on Sonar, why not do another paid fix, call it 9 and do a proper X1 in 2011? A 11/11/11 launch? That would have solved 99% of this.

I don't understand what some of this means.

1) "Doesn't take dev time to get what you already had". What does this mean?

2) "...2 years w/o serious development of SONAR". This would certainly be news to the developers who work on SONAR every day.

I couldn't disagree more. 8.5 was massively cluttered with buttons and widgets everywhere. 

 




 I can not for the life of me figure out why you would say something like that knowing it was customizable. 

 Is that the point you guys are at now?  Really?  Is this what is has come down to?

Brandon Ryan [Cakewalk
]

10Ten

Brandon Ryan [Cakewalk
]
Because it takes design, development and testing time.

It doesn't take dev time to get what you already had. You had already gone 2 years without serious work on Sonar, why not do another paid fix, call it 9 and do a proper X1 in 2011? A 11/11/11 launch? That would have solved 99% of this.

I don't understand what some of this means.

1) "Doesn't take dev time to get what you already had". What does this mean?

2) "...2 years w/o serious development of SONAR". This would certainly be news to the developers who work on SONAR every day.

It means that Sonar already had those things and didn't need to be changed. The audio engine needed change, but I guess that's hard to sell. 2 years and we got a couple of plugs and a GUI. I know it takes time to do those things, but they shouldn't have come at the expense of putting Sonar further behind. In the end the only thing I risk is a few hundred dollars and having to learn another DAW you have a lot more to lose if you can't get this ship righted.

UnderTow


Oh come on Brandon. Making all the buttons and track heights etc smaller to start with does NOT use any more development resources. They are just pictures in the end. Nothing more.

I don't know I think this is an oversimplification. I'd be willing to bet a developer would say otherwise. I mean perhaps you are more versed in software development code slanging than I am but every time i say something like this to a programmer they look at me and shake their head at my child-like ignorance.

Because it takes design, development and testing time.

No it doesn't. There is no way you are going to make me believe that shaving of a few pixels off everything has any bearing on how long it takes to design a GUI. On the other hand, getting things right from the start does save design, development and testing time along the line.

Shaving off pixels after the fact does indeed take time to do as it affects the entire UI. But the more important fact is that you said "give the option" to make them smaller. That does take more deign and dev time. It's a fact. There is a difference between baking it one way and giving options. The more options, the more design, dev and testing time. I don't make the rules. If it was so easy then why don't we just take the afternoon and do it? Stubborness? Ineptitude?

Thi is something I've had to come to terms iwth while working for music technology companies over the years. We've been through this before. It's easy to throw an idea on the table and ask why it wasn't implemented. And you know we appreciate thoughtful good ideas. But as soon as you say "why not give the option" you are adding design, develpment and testing time to the product.

Not in this case. The option is already there. Tracks can be resized. I just think they should start smaller.

I agree it would be nice to start smaller. I have good eyesight so I tend to like elements a bit smaller than many. But you have to factor in what information shows in the smallest state and have that state be usable and scalable to the larger state. And there are always other factors I can never dream of once you start digging into the actual code involved. It's almost never as simple as it seems. Granted, once in a while it is, but more often than not there are mitigating factors that limit what we'd all like to see.

Now on the other hand if I suggested there was the ability to resize tracks to much smaller heights but to do this the track view would have to switch below a certain size to a view that removes all the widgets and track names... then you would have a point.

(Pro Tools does that).

I never meant to give the impression that I'm arguing against having the ability to have smaller tracks - that would be absurd.  What I was saying is that the current lack of ability doesn't inherently make it a bad UI or outweigh the positive aspects of X1's interface. I was cautioning against putting too much emphasis on his particular aspect.

It is important you know.

UnderTow

10Ten


2 years and we got a couple of plugs and a GUI.

There are some very nice things in X1 but yes I agree that some very nice stuff was also lost...

UnderTpw

10Ten

Brandon Ryan [Cakewalk
]

10Ten

Brandon Ryan [Cakewalk
]
Because it takes design, development and testing time.

It doesn't take dev time to get what you already had. You had already gone 2 years without serious work on Sonar, why not do another paid fix, call it 9 and do a proper X1 in 2011? A 11/11/11 launch? That would have solved 99% of this.

I don't understand what some of this means.

1) "Doesn't take dev time to get what you already had". What does this mean?

2) "...2 years w/o serious development of SONAR". This would certainly be news to the developers who work on SONAR every day.

It means that Sonar already had those things and didn't need to be changed. The audio engine needed change, but I guess that's hard to sell. 2 years and we got a couple of plugs and a GUI. I know it takes time to do those things, but they shouldn't have come at the expense of putting Sonar further behind. In the end the only thing I risk is a few hundred dollars and having to learn another DAW you have a lot more to lose if you can't get this ship righted.

Dare I ask what "things" do you speak of?

Also, fine if you denigrate the user interface and the work done on X1 to "a GUI", but I and many others feel there's a lot wrapped up in those precious 3 letters. Not for you but for a lot of us there is a lot of work and improvement there.

Regarding the ship being righted: SONAR X1 has been very successful for Cakewalk thus far. This doesn't mean we don't want to make it better and satisfy the users as much as possible (we do!), but repeatedly saying what a disaster it is doesn't actually make it a disaster. It's not Beetlejuice.

Brandon Ryan [Cakewalk
]

10Ten

Brandon Ryan [Cakewalk
]

10Ten

Brandon Ryan [Cakewalk
]
Because it takes design, development and testing time.

It doesn't take dev time to get what you already had. You had already gone 2 years without serious work on Sonar, why not do another paid fix, call it 9 and do a proper X1 in 2011? A 11/11/11 launch? That would have solved 99% of this.

I don't understand what some of this means.

1) "Doesn't take dev time to get what you already had". What does this mean?

2) "...2 years w/o serious development of SONAR". This would certainly be news to the developers who work on SONAR every day.

It means that Sonar already had those things and didn't need to be changed. The audio engine needed change, but I guess that's hard to sell. 2 years and we got a couple of plugs and a GUI. I know it takes time to do those things, but they shouldn't have come at the expense of putting Sonar further behind. In the end the only thing I risk is a few hundred dollars and having to learn another DAW you have a lot more to lose if you can't get this ship righted.

Dare I ask what "things" do you speak of?

Also, fine if you denigrate the user interface and the work done on X1 to "a GUI", but I and many others feel there's a lot wrapped up in those precious 3 letters. Not for you but for a lot of us there is a lot of work and improvement there.

Regarding the ship being righted: SONAR X1 has been very successful for Cakewalk thus far. This doesn't mean we don't want to make it better and satisfy the users as much as possible (we do!), but repeatedly saying what a disaster it is doesn't actually make it a disaster. It's not Beetlejuice.

All of the easy to access buttons we used to have. Correct me if I am wrong, but in the many years I have used Sonar I don't recall this much dissent with a version. Most of the problems here are due to making a change to what a lot of us considered to be non-essential before the essential things were done. If Sonar had a solid audio engine and very few generational bugs a new GUI would be little complain about. It's all those things together that cause a lot of us grief.

If you want to make X1 better, make all of the GUI elements smaller and add the ability to see all the ones that 8.5 had. We need choices.

10Ten


All of the easy to access buttons we used to have. Correct me if I am wrong, but in the many years I have used Sonar I don't recall this much dissent with a version. Most of the problems here are due to making a change to what a lot of us considered to be non-essential before the essential things were done. If Sonar had a solid audio engine and very few generational bugs a new GUI would be little complain about. It's all those things together that cause a lot of us grief.

If you want to make X1 better, make all of the GUI elements smaller and add the ability to see all the ones that 8.5 had. We need choices.

I guess you could argue that we should allow the user to add more buttons if they wanted to. And I can understand that once you got used to a button for everything that it might have become comfortable.

But for years, we've heard how SONAR has too many buttons, and really...it did. Menu items were all over the place and the UI needed streamlining. From our perspective far more agree iwth this than don't . Unfortunately you fall into the latter camp.

That's not to say that we won't continue to build back in more choices over time. I think choice is good and we hear you when you say this, but we really needed to start from ground zero. Personally there are some things I thought should have been left in or some choice that should have stayed in tact. For varying reasons, it wasn't possible, but that doesn't mean things won't get better in that regard over time. There are plenty of examples of this with other applications throughout software history.

mike_mccue
Can you access snap settings with your hardware controller? I really don't know so I am asking.

If I wanted to. I could program them to the MCU F keys. I personally don't I prefer to access them via the CB which pops up or down with a single keypress. Did I mention screensets?  

mike_mccue
Can you see when the snap settings change on you without warning?

I know when they are going to change. It's switching to the PRV that brings out that bug. I work round it by opening the PRV and then setting the snap-to. If you set the snap-to and then open the PRV it (the snap-to) will change to the PRV's snap-to setting. Of course if it's the same you won't notice anything.

I do take your point though and would rather the bug was fixed. X1b? Have I mentioned Screensets? 

mike_mccue
How would you set a loop? With the hotkey? How would you confirm what the loop start and end start times became?

Loop times are easily set with an MCU. Press the loop mode key, M1 + RW key sets start, M1 + FF key sets end. Turn loop on. Very quick. I can't remember the last time I set a loop using the mouse/comp keyboard.

A good control surface is worth it's weight in gold once it's been learnt. The BCF 2000 in Mackie mode is a great, cheap way of getting your feet wet......

Did I mention Screensets............. okay I've got my coat............

Brandon Ryan [Cakewalk
]

10Ten


All of the easy to access buttons we used to have. Correct me if I am wrong, but in the many years I have used Sonar I don't recall this much dissent with a version. Most of the problems here are due to making a change to what a lot of us considered to be non-essential before the essential things were done. If Sonar had a solid audio engine and very few generational bugs a new GUI would be little complain about. It's all those things together that cause a lot of us grief.

If you want to make X1 better, make all of the GUI elements smaller and add the ability to see all the ones that 8.5 had. We need choices.

I guess you could argue that we should allow the user to add more buttons if they wanted to. And I can understand that once you got used to a button for everything that it might have become comfortable.

But for years, we've heard how SONAR has too many buttons, and really...it did. Menu items were all over the place and the UI needed streamlining. From our perspective far more agree iwth this than don't . Unfortunately you fall into the latter camp.

That's not to say that we won't continue to build back in more choices over time. I think choice is good and we hear you when you say this, but we really needed to start from ground zero. Personally there are some things I thought should have been left in or some choice that should have stayed in tact. For varying reasons, it wasn't possible, but that doesn't mean things won't get better in that regard over time. There are plenty of examples of this with other applications throughout software history.

I agree that 8.5 had too many buttons, but I could get rid of most of them if I wanted. In X1 the control bar is huge and buttons are too big. If I want to see it, it takes up more room than all of the buttons 8.5 had. Less choice, more room. It just doesn't make sense.