cheez
Sorry for being a wet blanket here. There number of bug fixes in X3b and X3c are so numerous and extensive that it made me wonder why these weren't discovered during the beta stage. Or perhaps the product was released as a beta product and the early adopters became the beta testers. Don't get me wrong - I'm glad that Cakewalk is releasing patches quickly and faster than compared to previous versions. But there shouldn't be so many fixes needed on a finished product. I hope their beta testing/QA team get their act together.

The software wasn't unusable on release. I think the only way to really sort these things out is to get the software into use as a production tool. There's no way beta testing teams can simulate hundreds of people putting the software to use as a tool in real world situations. That's hundreds of systems, hundreds or methods, hundreds of situations where different combinations of clicks, drags, drops, undo, copy, import, export, paste, you name it - get jammed together all at one time. This is where the discoveries are made.
 
I find it hard to believe people who are involved in music production have a hard time with the idea that things aren't perfect the first time or that after a few listens you think you can do better. If software was all on the surface like a recording then it would be easy but what you see is only the beginning. I would say finding a mistake in code is probably about as easy as spotting a wrong note by looking at a wave file.

I'm very glad for the fixes in X3c. X3 has already been working great. This just makes me feel like I'm going to have an even smoother experience.

The fixes that I was especially keen on, getting PodFarm and Guitar Rig 5 to work more seamlessly in X3, were addressed and I'm raring to go on those.

Beepster
Another thing that would be cool now that I understand Craig Anderton's Advanced Workshop entry about frequency filtering with the VS 64 Multiband Compressor (or whatever it's called) is if the PC EQ had a setting to filter out bands in a similar way. The VS Multiband is pretty resource intensive so to have multiple instances of it just to portion out parts of the frequency spectrum might bog a project down. The current band filters on the PC are curved in such a way it wouldn't be the same thing. So if there was a filter setting that didn't actually process anything but just created 4 or 5 blocks that could be individually bypassed/silenced all that would have to be done is clone the tracks. This way if I'm working on a guitar part I can set up my sims and other effects based on a specific range without using a plugin to filter the frequencies and/or screw around too much trying to isolate the bands.

Basically what you want is a crossover, not a parametric EQ, which would require a completely different architecture compared to that of the PC EQ. However, the Sonitus multiband compressor works just fine and doesn't use as many resources; in fact it's almost always what I use. Where the LP really shines is in the very high frequencies, but as soon as you throw a cab on an amp sim, the frequencies aren't there anyway. I think that if you inserted an LP64 Multiband and a Sonitus with identical settings and A/Bed them, you would hear no significant difference.

Can anybody confirm this :
 
create several buses ...display just like 4 cm alocated in the track view ....double click on each of them after scrolling to maximise each of them to fit those 4 cm ...then scroll : size not consistant for each "mouse click scroll" ....instead of having each bus(feeding all the 4cm)  displayed for each scroll , it is inconsistant ....
 
This was the case in X1 ....is it a bug or a new impentation ?
 
By the way in views Bakers acn add a bug fixed : moving the reading cursor doesn't make it disaparear time to time according to the time posistion ....bug fixed ....
 
Still i have this multimbrales super slow insertion ....
 
Screensets switching seems ways smoother ;)

If you really need it to start in the middle, converting it to an audio track is a workable option.
 

cheez
Sorry for being a wet blanket here. There number of bug fixes in X3b and X3c are so numerous and extensive that it made me wonder why these weren't discovered during the beta stage. Or perhaps the product was released as a beta product and the early adopters became the beta testers. Don't get me wrong - I'm glad that Cakewalk is releasing patches quickly and faster than compared to previous versions. But there shouldn't be so many fixes needed on a finished product. I hope their beta testing/QA team get their act together.

If you think the number of bug fixes is "numerous and extensive," that list is nothing compared to the list of bugs that get tracked and fixed during the development process. It would be like a batter who hit .987, and all people could focus on was that he didn't hit the ball the other .013 at-bats.
 
Perfection is rare. For example, there was a typo in your post ("There number" instead of "The number") and a grammatical error: When used as a noun referring to an arithmetical value, the word number is singular so you should have said "The number of bug fixes in X3b and X3c is..." Now, that's only two errors out of an entire paragraph, but if you knew they were there, why didn't you fix them? And if you didn't know they were there...well, that's exactly how bugs happen!
 
It's also important to realize that the number of permutations and combinations of how people use software is in the millions. There is no way to test all of those possibilities prior to release if you expect to release something before the sun collapses into a dwarf star. When you have bugs like "Double-click maximize and 'Fit Project' would not work correctly in projects with hidden tracks" you had to have someone test a project with hidden tracks and then wanted to double-click maximize and 'fit project' and found out that it crashed...then be able to reproduce how it happened, and make it happen repeatedly. Or a bug like "Resolved a crash when selecting 'Selected Track inputs...' menu item in a project with no tracks." I would NEVER find a bug like that because if a project had no tracks, I would not select Selected Track Inputs.
 
Then are the bugs like "Resolved a hang that could occur when dragging tracks and folders." The "could" occur bugs relate to various different conditions, so kudos to whoever tracks down the "could" bugs.
 
X3 was very stable for an initial release, the forumites have confirmed that. Some of the bug fixes in X3c are pretty esoteric. Even a crack beta team with dozens of people are going to have a hard time finding those.
 
This isn't being an apologist for Sonar, I would say the same for any software manufacturer. Frankly, I'm really proud of the Bakers for being so relentless about tracking down bugs. They could have said "well people seem pretty happy, I guess we can take off for a month." But they didn't.
 
Besides, you had better hope the day never comes when a software company does an initial release of a piece of software and it contains no bugs, because that will be a sign the world is coming to an end.
 
 

I love X3.  And I stayed on 8.5.3 for years.  I thought there would be a steep learning curve and there is not.  I thought there would be a lot of bugs.  And yes there are some, but they are easy for me to work around.  The main thing is that it is smooth and sounds great.  It seems to sound better than 8.5.3.  That is worth something.  I do wish I could make the record button on the tracks be a little more predominant, but in time, I will get use to that.  I remember the days when I was using tape and we thought this type of recording would never be this accessible or this inexpensive.  Let's see - what type of bugs did tape have -- biasing the machine, heads wearing down, wow and flutter, having to rewind and fast forward all the time, different tape runs from the manufacturer, splicing tape issues, storing issues, magnetic issues, the cost of the tape, try the undo on a tape, tape noise, making a perfect copy of a tape like digital, etc. etc.   It did not take long for a lot of people to start taking these drastic improvements in digital recording for granted. I am very grateful.   

cheez
Sorry for being a wet blanket here. There number of bug fixes in X3b and X3c are so numerous and extensive that it made me wonder why these weren't discovered during the beta stage. Or perhaps the product was released as a beta product and the early adopters became the beta testers. Don't get me wrong - I'm glad that Cakewalk is releasing patches quickly and faster than compared to previous versions. But there shouldn't be so many fixes needed on a finished product. I hope their beta testing/QA team get their act together.

This is one of the misconceptions about the software development process lifecycle. All software has bugs - period. What companies strive for to optimize quality is is a *low* observable / actual bugs ratio. During a given development process cycle we fix several hundreds of issues old as well as new. Many of these occur under exception conditions and some are not even easily observable by QA engineers since the symptoms are more visible in the code not that easily in the user interface. The net result of these multitudes of fixes can be a net user perception of the app being more stable or responsive feel. This is likely why many have observed that X3 feels more "solid". 
In general, bug fixes are a good thing and not an indication of a lack of quality or missed testing.
[edit: fixed typo]
 

I Rather doubt that anyone who has ever worked in software development will share your opinion. I have, and I don't.
 
Take a look at the data. If you review the extensive list of bugs discovered and fixed, to a large part they are corner cases of using specific plugs, or compound faults requiring specific modes of operation and use.. Such things are extremely difficult to detect during beta testing.
 
The bottom line is that there are as many system setups and test environments as there are users of Sonar, and it is simply not possible to cover every single possible combination of track, project, mode, function, plug combination, routing, synth and use in a lab or open beta test program. So to me, the most solid approach is for a solid first release and rapid attention to bug fixes.. exactly as CW has done it with X3
 

cheez
Sorry for being a wet blanket here. There number of bug fixes in X3b and X3c are so numerous and extensive that it made me wonder why these weren't discovered during the beta stage. Or perhaps the product was released as a beta product and the early adopters became the beta testers. Don't get me wrong - I'm glad that Cakewalk is releasing patches quickly and faster than compared to previous versions. But there shouldn't be so many fixes needed on a finished product. I hope their beta testing/QA team get their act together.

Anderton

cheezSorry for being a wet blanket here. There number of bug fixes in X3b and X3c are so numerous and extensive that it made me wonder why these weren't discovered during the beta stage. Or perhaps the product was released as a beta product and the early adopters became the beta testers. Don't get me wrong - I'm glad that Cakewalk is releasing patches quickly and faster than compared to previous versions. But there shouldn't be so many fixes needed on a finished product. I hope their beta testing/QA team get their act together.

If you think the number of bug fixes is "numerous and extensive," that list is nothing compared to the list of bugs that get tracked and fixed during the development process. It would be like a batter who hit .987, and all people could focus on was that he didn't hit the ball the other .013 at-bats. Perfection is rare. For example, there was a typo in your post ("There number" instead of "The number") and a grammatical error: When used as a noun referring to an arithmetical value, the word number is singular so you should have said "The number of bug fixes in X3b and X3c is..." Now, that's only two errors out of an entire paragraph, but if you knew they were there, why didn't you fix them? And if you didn't know they were there...well, that's exactly how bugs happen!  It's also important to realize that the number of permutations and combinations of how people use software is in the millions. There is no way to test all of those possibilities prior to release if you expect to release something before the sun collapses into a dwarf star. When you have bugs like "Double-click maximize and 'Fit Project' would not work correctly in projects with hidden tracks" you had to have someone test a project with hidden tracks and then wanted to double-click maximize and 'fit project' and found out that it crashed...then be able to reproduce how it happened, and make it happen repeatedly. Or a bug like "Resolved a crash when selecting 'Selected Track inputs...' menu item in a project with no tracks." I would NEVER find a bug like that because if a project had no tracks, I would not select Selected Track Inputs. Then are the bugs like "Resolved a hang that could occur when dragging tracks and folders." The "could" occur bugs relate to various different conditions, so kudos to whoever tracks down the "could" bugs. X3 was very stable for an initial release, the forumites have confirmed that. Some of the bug fixes in X3c are pretty esoteric. Even a crack beta team with dozens of people are going to have a hard time finding those. This isn't being an apologist for Sonar, I would say the same for any software manufacturer. Frankly, I'm really proud of the Bakers for being so relentless about tracking down bugs. They could have said "well people seem pretty happy, I guess we can take off for a month." But they didn't. Besides, you had better hope the day never comes when a software company does an initial release of a piece of software and it contains no bugs, because that will be a sign the world is coming to an end.  

Brilliant..... This should be s sticky!