How does REAPER do it?

[eduardo_b]

Many, many good reasons why Reaper is both lean and successful. Like someone said, low overhead, good product sold at a great price is a win for them.

...But not necessarily a loss for anyone else. The 'big dogs' have their work cut out for them, but have name recognition and user loyalty and such in their favor. There will definitely be a thinning of the heard, but there will always be room for many audio apps and DAWs.

Suppose someone who owns one of the "big dogs" tries Reaper and finds the design philosophy and workflow a pleasant surprise. They can purchase the product for far less than upgrading the one they already have. That is where the established names in the business run a risk. But given the reality that many will not like Reaper, these other companies are unlikely to lose much revenue in the long run.

[skipkent]

The 'big dogs' also have higher expectations on them. If they make a fundamental change to their product, some will hail it as a great advance while others will bemoan their straying from the original vision. These perceptions will translate to very real $$$ wins and losses for them, so they *have* to move carefully, study their market and strategize. Every move they make is a gamble with lots and lots of REAL MONEY (usually other people's) involved.

The Reaper devs have no such restrictions. Any attention they get (even a flame war on KVR ; ), is a win for them. Even small successes will show them as 'beating Goliath', whereas any weaknesses in their product can be explained away with, "Well c'mon, they're just starting out, and they only cost 1/5 the price of the competition!"

It's like an unknown karate dude challenging Chuck Norris. I the unknown gets his ass kicked, it's cool. "I got my ass kicked by Chuck Norris!" If wins, or even lands a single punch, it's "DUDE! I hit Chuck Norris!"

All that said, I'm not dissing Reaper one bit. I own a license and am a fan. It's a great program and their development and distribution method is, I believe, very much the wave of the future. The big dogs have their work cut out for them and then some.

[LawrenceF]

Rabietic
Ecletic
Agnostic
Paternalistic
Engineer's
Program

[eduardo_b]

Except of course that the more code there is, the greater the need for optimization, all of which is time-consuming.

Are you under the impression that the total amount of code in an application is in use at all times or something? Because that's the only circumstances under which the direct causal relationship you're suggesting would be true.

Yeah, I think this is probably the most common misconception that appears to pervade the userbase. Just because new icons or new menu entries appear in an application, somehow it's believed that these are taking up CPU cycles by their very presence. Most features (or 'bloat', if people prefer) tend to be "on demand" things. One-off processes that are called when needed.

One man's bloat is another man's bread & butter. The wealth of manipulation options in larger apps like Sonar or Cubase tend to be the first things I miss in other apps.

Actually, although not a coder mysef, I understand the principles involved, and recognize that most of the feature code is only called when requested. But this feature code itself can be resource hungry, and should several features be running simultaneously, performance can suffer on computers that have less processor capability, insufficient memory, a lack of virtual memory space and so on. The indisputable reality is that bloat happens when resources are insufficient for the code to run optimally.

Which brings up the featuritis that is the root of this issue. The wealth of manipulation options may be desirable and even necessary for some types of projects, but otherwise they are simply baggage. This is where so-called lite versions of DAWs can be a better choice for those who want the workflow but recognize how many features of the "full" version are not needed or wanted in building a DAW from the ground up.

There clearly are differences in performance among DAWs. I assume it's both the code and how many services are loaded. I also know that it's not uncommon to go back to the base code and redo it for better performance and resource use...hence my question about the time involved.

[eduardo_b]

The 'big dogs' also have higher expectations on them. If they make a fundamental change to their product, some will hail it as a great advance while others will bemoan their straying from the original vision. These perceptions will translate to very real $$$ wins and losses for them, so they *have* to move carefully, study their market and strategize. Every move they make is a gamble with lots and lots of REAL MONEY (usually other people's) involved.

Yeah...the conundrum of success. The more successful a company is, the more there is at risk.

[memyselfandus]

http://forum.cockos.com/showthread.php? ... post400935

[LawrenceF]

That's pretty cool. ^^^^

[whyterabbyt]

Actually, although not a coder mysef, I understand the principles involved

Do you? I think you think you understand 'the principles', but really you perhaps only really understand some of the principles, and many of those not quite as well as you think you do. and there are probably many you're completely ignorant of.

, and recognize that most of the feature code is only called when requested. But this feature code itself can be resource hungry, and should several features be running simultaneously, performance can suffer on computers that have less processor capability, insufficient memory, a lack of virtual memory space and so on.

is that another hypothetical situation, like your 'it might reduce the incentive to optimise' ??

we could posit things that 'might' or 'can' happen in hypothetical situations all the time (and you do, i would suggest) but really, what's the point? is it just an interesting thing to meander over what could and might and may be just for its own (to my mind, utterly pointless) sake, or are you trying to imply that these things do happen because they might. as ever it just seems like pointless mental masturbation.

The indisputable reality is that bloat happens when resources are insufficient for the code to run optimally.

erm, no, i dont think that ive ever seens a consensus that a program is bloated on a system by system, instance by instance basis, which is what you're effectively saying.

Which brings up the featuritis that is the root of this issue.

Is it the root of the issue? That sounds like another one of those assumption thingies again.

The wealth of manipulation options may be desirable and even necessary for some types of projects, but otherwise they are simply baggage.

Are they? I really doubt you have grounds for a unilateral claim like that, to be honest.

There clearly are differences in performance among DAWs. I assume it's both the code and how many services are loaded.

Well its pretty obviously 'the code' when talking about why two bits of code would behave differently on the same system. The actual issue would be what aspects of the code make the difference. One could be better optimised, but the other is written to do less in the first place. Which is 'bloated'?
As for services, I dont understand what you specifically mean in this context.

[EvilDragon]

The wealth of manipulation options in larger apps like Sonar or Cubase tend to be the first things I miss in other apps.

Cool. I never missed Sonar's instability and plugin usage behavior.

I am missing the mouse zone editor, though. Still, it will come in Reaper, too.

[eduardo_b]

Well its pretty obviously 'the code' when talking about why two bits of code would behave differently on the same system. The actual issue would be what aspects of the code make the difference. One could be better optimised, but the other is written to do less in the first place. Which is 'bloated'?

I don't know. Does optimizing for best resource use while providing best performance represent a time consuming proposition or something that talented coders simply implement? That was the basis for my original question. Is it cost effective to optimize in the long run? I asked you about time needed for coding because you seem to be quite knowledgeable about software coding.

[memyselfandus]

That's pretty cool. ^^^^

I know!

[memyselfandus]

http://forum.cockos.com/showthread.php? ... post400935

[EvilDragon]

Does optimizing for best resource use while providing best performance represent a time consuming proposition or something that talented coders simply implement?

Both.

Is it cost effective to optimize in the long run?

Well, for the big dogs this means putting a lot of manhours into optimizing, so yes, it could be less cost-effective. But, users would've been happier with the product that runs faster and doesn't consume as much resources for the same job as the unoptimized version.

It's sad that big players don't really invest into optimizing their code. Then you get situations like on Cubase forums, where they really don't respect their customers input and bug reports. They should rot in hell for that, if you ask me.

[Ubiety]

Rabietic
Ecletic
Agnostic
Paternalistic
Engineer's
Program

Good thing you didn't enter a spelling bee or apply for a job at an intelligence agency.

[LawrenceF]

That's pretty cool. ^^^^

I know!

This will be another one of those times where Reaper gives me ideas. It's nowhere near as slick as that but I've written some macros in Cubase for toggling folders open and closed based on the folder name.

Again, not nearly as slick as the Reaper method with those icons and it's true track hiding with SWS but thanks for the idea!

Reaper Rawks.