Gosh Marah,
I sincerely thought you were speaking of a new paradigm... something like the way the guy in the matrix surfed the net...

I really didn't mean to upset you.

I totally agree with everything you've explained further.

And, I think track icons are living proof that SONAR is catering to people from the home studio world (maybe next year we'll get animated track icons... wouldn't that be cool)... while ignoring fairly obvious problems.

best,
mike

ORIGINAL: mike_mccue

Gosh Marah,
I sincerely thought you were speaking of a new paradigm... something like the way the guy in the matrix surfed the net...

I really didn't mean to upset you.

I totally agree with everything you've explained further.

And, I think track icons are living proof that SONAR is catering to people from the home studio world (maybe next year we'll get animated track icons... wouldn't that be cool)... while ignoring fairly obvious problems.

best,
mike

he-he mike ...you know how this sounds?

like saying that sonar should have no color schemes because its childish to wanna customize colours....
if some people like the icons: ok, if not: ok, personally i never use them and thats why i dont worry about...
actually its also obvious that a firm has to present some sort of added goodies here and then - but i really doubt that track icons brought new customers - and in the end there are tons of other things implemneted in sonar that i never use...so how should cake now what fits best for ALL....still these days i was considering to buy a hardware multitracker cos i am getting so unispired by software..as i keep posting in the last times back to basics..

ORIGINAL: info@tomflair.com

ORIGINAL: mike_mccue

And, I think track icons are living proof that SONAR is catering to people from the home studio world (maybe next year we'll get animated track icons... wouldn't that be cool)... while ignoring fairly obvious problems.

best,
mike

he-he mike ...you know how this sounds?

like saying that sonar should have no color schemes because its childish to wanna customize colours....
if some people like the icons: ok, if not: ok, personally i never use them and thats why i dont worry about...
actually its also obvious that a firm has to present some sort of added goodies here and then - but i really doubt that track icons brought new customers - and in the end there are tons of other things implemneted in sonar that i never use...so how should cake now what fits best for ALL....still these days i was considering to buy a hardware multitracker cos i am getting so unispired by software..as i keep posting in the last times back to basics..

Thanks for the reality check Tom,

I think if the bugs were fixed in a timely manner I'd have a completely different attitude about the smoke and mirror symptoms.

And BTW I can justify (in my opinion) color schemes because I have many color blind friends who can benefit from that feature... I only have a few friends who can not read.

best regards,
mike

ORIGINAL: UnderTow

ORIGINAL: info@tomflair.com

there is no need to have this "new shee"t aproach cos an app like sonar i guess has a very modular structure and therfore the code could be made slimmer and more efficient step by step...
this "new broom cleans house" is a everyday comparison that doesbt necesarilly fit into the programming world...
no need to recode all from scratch to get some features implemented.. a software is not a cake (ha-ha...) you have to bake again and again - you can ad AND delete - parts of the recipe...
i think that "new from scratch" is a sort of bloated argumnet that might result from boredom...what do you expect from a sequencer - a fuzzy logic - mental reading interface that represents notes with colours and smell?? where i can track past and future tracks with my quantum interface?
sometimes there is so little benefit from code optimization (if the code isnt total crap from the beginning) that it would improve performance only so little that its just not within economic reason.
so i guess no salvation comes from new from scratch - if you want something NEW just switch to another app that fits your needs better...
actually i wouldn mind a totally NEW sonar - but - lets be realistic - how much would it affect my music? 20-40% ?? nayyy...probably 2-4% so WHATS THE USE???
the main issue is probably that people expect their daws to to ALL...hey for me daw is only a very little piece within my workflow...

PS: still i would love a more stable audioengine - but thats not calling for the french revolution

cheers

Tom, it doesn't really matter how Cakewalk achieve it, as long as they achieve it. Unfortunately the responses from Cakewalk employees today in another thread kind of tell me that they just don't have the vision: http://forum.cakewalk.com/tm.asp?m=1485542

UnderTow

yeah a great rant thread - that ones amuse me most - hahahaha

Mike, I think Tom was referring to the other thread.

UnderTow

Ok :-)

But, I think I gave that fellow the best advice he's gonna get... even if he doesn't want to hear it.

The 6 is an abusive business... you either know how to thrive in that land of shrinking budgets or you get spit out with a reputation for melt downs and missed hits.

My guess is that he's the one bringing SONAR into the mix... SONAR is unheard of in the live news world. There's still a lot of A/B linear editing going on every day in live news.

And thank you, as well, for the reality check.

best,
mike

ORIGINAL: UnderTow
What I really want is that Cakewalk really think through new features and get them right from the start. As an example, this is how Digidesign implemented Elastic Time when it was first added to Pro Tools 7.4: http://www.sonicstate.com/news/shownews.cfm?newsid=5402 The technology is not too different from AudioSnap (It also use iZotope Radius algorithms) but the IMPLEMENTATION kicks the beejesus out out of AudioSnap.

Audio Snap has been available since SONAR 6 released Sept 2006... the date on that article is October 2007. The only thing we've proven here is that it pays to come to the party late and to bring your own beer. Digi was afforded the luxury of being able to survey all of the competitors' implementations of Audio Snap/Elastic Audio/whatever and design something that they feel kicks the competition's butts. Of course, in the meantime I'm sure all their customers were jumping up and down saying "why can't we have Stretchy Timeline like SONAR/Samplitude/Cubase/etc.?!?!?!" So, you can't win either way. From my perspective it's analogous to what Cake did with the MIDI tools in v7 -- survey the competition, then leapfrog 'em.

RE: x64 -- I think saying that starting down the 64-bit path was a "waste of time" is unfair. They recognized that at some point the codebase needs to run as a native 64-bit app, and there's quite a bit of work required to port a 32-bit app to 64-bit (Hello, Steinberg!!! ). I'm sure the port to x64 shortened the time/effort required to deliver on Vista 64 by a couple of factors -- probably some system API tweaks and a recompile. Then of course you also need the Bit Bridge to span the 32-bit world. So the argument really is: should they have spent any time at all porting to 64-bit? And to that I'd say: if we were all flying along on fully 64-bit systems, then it wouldn't even be worth debating. They took the initiative to provide the 64-bit platform, and it's not they're fault that everyone from plugin developers to hardware manufacturers can't be bothered to bring their products into the new millenium.

RE: innovation -- what about totally unlimited bussing? What about the totally configurable and flexible new MIDI tools? What about ACT? What about the first 64-bit (float) mix engine? WHAT ABOUT TRACK ICONS, MAN?!?! Come on... track icons... The hard part about innovation in Cake's market is that you have a limited amount time and resources just to keep up with the Joneses, not to mention invent totally new and unique features.


Undertow, I'm sure you and many other users hereabouts are much more power users than I, and you, in particular, have your own legitimate perspective on the whole thing... And I'm not arguing that there can't be improvements, or perhaps even some refocusing of energies here and there. But from my perspective, SONAR has come a very long way since SONAR 3 when I jumped on board.

Oops. I hit post too fast. Edited.

ORIGINAL: keith

Audio Snap has been available since SONAR 6 released Sept 2006... the date on that article is October 2007. The only thing we've proven here is that it pays to come to the party late and to bring your own beer.

That's a fair point but why is it that more often than not when I use a new feature in Sonar I can usually think of a few GUI and implementation improvements within SECONDS? (That's right, seconds, not minutes). I am so often totally amazed at how some things have been implemented. (Not in a good way).

To me this is all about being thorough and taking a couple of seconds (or minutes) longer to think things through. For instance when Ron Kuper added the smaller time subdivisions to many of the menus, he missed the "Quantize Duration" menus. It is also a pity that smaller subdivisions were not added to, off the top of my head, "Split repeatedly", "slide", "Length", "Insert Time" etc.

Doing things right the first time saves a lot of time and energy.

Wisdom from our ancestors:

"Experience shows that, if one foresees from far away the designs to be undertaken, one can act with speed when the moment comes to execute them" Cardinal Richelieu, 1585 - 1642

"Look to the end, no matter what it is you are considering. Often enough, God gives a man a glimpse of happiness, and then utterly ruins him." The Histories, Herodotus 5th Century B.C.

"Do nothing without a regard to the consequences" Fables, Alesop, 6th Century B.C.

RE: x64 -- I think saying that starting down the 64-bit path was a "waste of time" is unfair. They recognized that at some point the codebase needs to run as a native 64-bit app, and there's quite a bit of work required to port a 32-bit app to 64-bit (Hello, Steinberg!!! ). I'm sure the port to x64 shortened the time/effort required to deliver on Vista 64 by a couple of factors -- probably some system API tweaks and a recompile. Then of course you also need the Bit Bridge to span the 32-bit world. So the argument really is: should they have spent any time at all porting to 64-bit? And to that I'd say: if we were all flying along on fully 64-bit systems, then it wouldn't even be worth debating. They took the initiative to provide the 64-bit platform, and it's not they're fault that everyone from plugin developers to hardware manufacturers can't be bothered to bring their products into the new millenium.

I specifically wrote "at the time". IMO it was the wrong time to bother with x64 which has now been abandoned by Microsoft which pretty much proves my point! Frankly, very few applications are truly ready for Vista but that doesn't hamper them because the core functionality is well done. That IMO is MUCH more important than x64/Vista 64 bit support. It is all about priorities.

Also, I think that going for x64 support was a bit of an intellectual cop-out. It is easier from a visionary point of view to implement 64 bit OS support (it is just technical stuff, it doesn't demand great imagination) compared to improving the functionality and workflow of an application. Improving the core functionality requires vision, stepping out of the box and taking the time to really think things through.

I'm sorry to say but x64 support sounds like the kind of thing a computer geek would come up with rather than a musician.

But much more importantly, what Cakewalk basically did is port an inefficient and not entirely stable audio engine to 64 bit. That IMO is a great waste of time and resources and energy. They should have first made sure the audio engine was extremely efficient and rock solid before even thinking of porting it.

As Noel Borthwick writes in a parallel thread "Cakewalk is a small company and we have had to focus our development efforts on the areas where we excel". It is essential for Cakewalk to concentrate their efforts on things that really matter. Not trying to be the first shop on a block with no inhabitants.

RE: innovation -- what about totally unlimited bussing?

Good but that's just programming. Linked array or dynamic array. 256 buses would have been fine. If you mean the routing, I would very much like to be able to select a bus as an input to a track. When the Universal Bus Architecture first came out, you could create routing loops. Cakewalk actually added a check to prevent that in the first point release. I find that extremely patronising.

Btw, look at the routing matrix in the Pyramix picture I posted. You can click on any of those grid points creating instant routing. Adding tracks or buses increases the routing matrix's size. All very easy and simple.

What about the totally configurable and flexible new MIDI tools?

Also good. Unfortunately the Sonar 7 audio engine is not stable enough for my use so I'm stuck on Sonar 6 for daily use. Again, that prioritisation issue...

What about ACT?

That is a very good example. Well done Cakewalk. The GUI could be much better though...

What about the first 64-bit (float) mix engine?

Very nice but IMO, not essential. Again I have to point to porting a less than efficient and solid engine rather than fixing or possibly redesigning things first. Also, with good use of assembler code, one can use the 80-bit accumulators in all modern CPUs.

Btw, I believe Mackie Tracktion 3 was the first to introduce a 64 bit mix engine! Check this 2005 article: http://remixmag.com/mag/remix_mackie_tracktion_3/ A year before Cakewalk.

WHAT ABOUT TRACK ICONS, MAN?!?! Come on... track icons... The hard part about innovation in Cake's market is that you have a limited amount time and resources just to keep up with the Joneses, not to mention invent totally new and unique features.

Not a Cakewalk innovation either. Logic has had them since... the stone age maybe? Anyway, I've already stated my opinion on track icons.

Undertow, I'm sure you and many other users hereabouts are much more power users than I, and you, in particular, have your own legitimate perspective on the whole thing... And I'm not arguing that there can't be improvements, or perhaps even some refocusing of energies here and there. But from my perspective, SONAR has come a very long way since SONAR 3 when I jumped on board.

Fully agreed. I just believe it could have come much further.

UnderTow

ORIGINAL: info@tomflair.com

cool vid - i loove the super streched bassdrum - coool ....bouuuuuuuuuuuuuuuuuuuuuuuuumm ... hahahaha the time stretching in audiosnap sucks bigtime - as i posted before comparing it to the quality of melodyne

I believe it is the same! iZotope Radius. Unfortunately Cakewalk do not allow us to use iZotope Radius for the online rendering. Why oh why?

UnderTow

ORIGINAL: mike_mccue

"Cakewalk do not allow us to use iZotope Radius for the online rendering. Why oh why"

Could it be because we don't have to have hardware acceleration to use SONAR?

I don't mind waiting a few seconds (or longer) for the render. That is much more efficient workflow wise compared to having to bounce/freeze/bounce to track. Having to wait doesn't break the creative workflow. Having to do extra steps and think of those extra steps to check the results really does break the mental flow. Just give online rendering as an option in the menu and let the user decide. Don't try and limit our workflow when there is no real inherent limitation.

Btw, I don't believe that Radius is running on the TDM Motorola DSP chips in ProTools. Everything I know of how ProTools uses the DSP chips (which are assigned to specific tasks and can't be switched out to other tasks on the fly) tells me Radius just runs natively like in Sonar.

UnderTow

I guess one way to answer that question might be to ask if the feature is available on PT LE... any idea?

ORIGINAL: AT

Cakewalk did start with a clean slate a few years ago. P5 had a separate engine, was loop centric, etc etc. It hasn't done as well as it should. Partially it is the programs fault, partically it is because Cake has concentrated on SONAR. But still, that fact would give me pause before killing the golden goose, if I was putting up my money.

Isn't the real problem with P5s marginal or questionable success the fact that many users of traditional multi track workflow don't even care if it exists?

In my self admitted myopic opinion it seems to have been a flirtation with a very limited user base... albeit one that was getting a lot of attention at the time.

There will continue to be an ever increasing number of audio editors doing traditional editing work for the continual expansion of media outlet opportunities but the 20 to 30 year old disco crowd is going to stay about the same size as it always has been.

best,
mike

ORIGINAL: tcaylor

ORIGINAL: Marah Mag

I don't see that it has anything in the world to do with file systems and operating systems or anything all that esoteric or new fangled or revolutionary. Those are just excuses and distractions.

I realize that I am singling out one statement of a very well thought-out and articulate post, but it has everything to do with file systems and operating systems and drivers and every other type of low-level interface between equipment and application and user. When all is said and done, the project has to be saved which is a file/operating system function.

Sure, top level design strategies can ignore these in the short term for new features but most of the bug fixes and stability issues more frequently are related to these lower level considerations. Some issues are actually caused by a designer not following the requisite protocol for interfacing their product or have not accomplished enough empirical testing to ensure stable operation.

It is still irrelevant to this discussion as any changes Microsoft might make to the File System would need to be taken care of by Cakewalk regardless of anything else.

UnderTow

ORIGINAL: mike_mccue

ORIGINAL: AT

Cakewalk did start with a clean slate a few years ago. P5 had a separate engine, was loop centric, etc etc. It hasn't done as well as it should. Partially it is the programs fault, partically it is because Cake has concentrated on SONAR. But still, that fact would give me pause before killing the golden goose, if I was putting up my money.

Isn't the real problem with P5s marginal or questionable success the fact that many users of traditional multi track workflow don't even care if it exists?

I suspect that the real reason is because Ableton came out with a much better and much more evolved product more or less at the same time. Ableton Live! was and is by far superior to Project 5. Ableton showed a vision and imagination that Cakewalk lack(ed) for this type of application.

In my self admitted myopic opinion it seems to have been a flirtation with a very limited user base... albeit one that was getting a lot of attention at the time.

There will continue to be an ever increasing number of audio editors doing traditional editing work for the continual expansion of media outlet opportunities but the 20 to 30 year old disco crowd is going to stay about the same size as it always has been.

I think you are very very wrong there. I believe that the dance music/loop based music market dwarves the entire Sonar market by several orders of magnitude.

UnderTow

ORIGINAL: mike_mccue
I was speaking specifically about the online rendering possibilities... I'm not trying to be a wise guy... do you think LE has the features you want?
I have zero experience with LE.

Yes it does but much more importantly, so does Sonar! Well nearly. All Cakewalk have to do is make it available to the user. All the hard work has already been done. Sonar just needs to use the Radius algorithms for the online processing.

UnderTow