I Think Bitwig Developers Are Fans Of Project5

[chk071]

Cool. I didn't know he was still in the industry. Thought he did something completely different now.

[Tj Shredder]

Ha, lame. The truth is the codebases became impossible to maintain. At any rate, Vokator, Spektral Delay, Pro-53, FM7, are all in-house developed, not subcontracted products.

I know the developer of the Spectral Delay personally, I met him after the release of it, and he was certainly not an employee of NI at that time… At least he had left short after, which would create the same problem as a vanished subcontractor. An impossible to maintain code base…

[eluherlu]

I remember Project5.. The gui was so beautiful back then

[Trensharo]

Ha, lame. The truth is the codebases became impossible to maintain. At any rate, Vokator, Spektral Delay, Pro-53, FM7, are all in-house developed, not subcontracted products.

I know the developer of the Spectral Delay personally, I met him after the release of it, and he was certainly not an employee of NI at that time… At least he had left short after, which would create the same problem as a vanished subcontractor. An impossible to maintain code base…

Developers can actually read and understand code, and code is often documented. Companies have regulations and standards around how code should be documented, etc. This has been the case for decades. If they don't, this leads them vulnerable to extortion by employees that churn out code and then e.g. demand significantly higher wages to stay on and develop/maintain applications that are crucial to the company's business.

Companies stop maintaining code when they don't feel the benefits of doing such is worth the revenue generated by any improvements made there. A great example is Samplitude Pro X. Huge swaths of the application are practically unmaintained (Spectral Editing, Wave Editing Tools, Restoration Tools, Elastic Audio, etc.) and MAGIX simply compensates by providing value adding bundles to stand in for those functions (SpectraLayers, SOUND FORGE Pro, RX Elements, Melodyne Essential).

The idea that a developer leaving renders a code base impossible to maintain is a massive fallacy, perpetuated by people who have never worked in that industry either as an employee or a contractor.

No one ever hired me to write code with the expectation that I will be churning out unmaintainable, undocumented spaghetti code. Every class, function and procedure is documented. Even if I wrote the code solo, another developer could get in there and understand the code.

People hired to develop DAWs, plug-ins and other DSP-related modules are expected to be able to be able to grok a code base that is documented up to corporate standards.

That's the reality of the matter. The developer leaving is often not the issue. The issue is the company simply doesn't see a reason to invest further into development.

Cakewalk killed this off because it lacked long term viability and likely wasn't making them much in terms of revenue even when it was current. Development and support costs were likely too high to justify the revenue generated by the product - as it wasn't really catching fire in the market and I doubt sales were very high. Software can have very high profit margins (free to duplicate after development), but you actually have to be selling decent volume to make that worth it - that, or selling lower volumes at very high prices. Development does not stop after the product is released, and support costs actually ramp up after release, as well.

If Project5 remained on the market, it likely still would have been destroyed by Ableton Live, Bitwig and others as time moved on. Look at how Cakewalk developed over the years. It could not keep pace with Cubase or Digital Performer... or even Windows-only competitors like Samplitude Pro X.

There is nothing in history that indicates that this product would have been more successful had they not cancelled it. History actually points in the opposite direction.

Part of good business is knowing when to cut your losses and abandon projects that lack viability.

A few people loving a product doesn't equate to "enough people to guarantee commercial viability." SONAR is a fantastic example of that.

[melomood]

I had Project 5. Still have it in the box. I gravitated because of RC who was also behind the SFZ format and I believe Dimension,which was the real attraction. As soon as Dimension Pro was available as a separate vst I was on that and done with P5. It was ok,but kind of clunky,with all the extra steps left in that were a bit annoying after being spoiled by Live.

[poonna]

The idea that a developer leaving renders a code base impossible to maintain is a massive fallacy, perpetuated by people who have never worked in that industry either as an employee or a contractor.

No one ever hired me to write code with the expectation that I will be churning out unmaintainable, undocumented spaghetti code. Every class, function and procedure is documented. Even if I wrote the code solo, another developer could get in there and understand the code.

People hired to develop DAWs, plug-ins and other DSP-related modules are expected to be able to be able to grok a code base that is documented up to corporate standards.

I agree that the Cakewalk cases are probably mostly business-related, not so much the code maintainability. But I don't think that unmaintainable code base is a massive fallacy. Books after books on software engineering, even by veterans, emphasize this as one of the major lingering issues in software development. Technical debts are real. Rushing towards tight schedule and foregoing best practices is real. New companies might not have all the standards in place yet as they are gaining more experience. Working with new technologies, GUI frameworks, all the new stuff can often lead to suboptimal usage which calls for refactoring, which in turn calls for extensive test coverage in place. Not to mention that some DSP developers are not software engineers by trade, and their coding practice might still be developing. So, unmaintainable code is not a myth. I believe some said that AAS discontinued their Tassman development because of (at least partially) unmaintainable code.

Well, in theory, there's no code that cannot be understood and worked on, given enough time and resources (just like you can count rocks in a Japanese garden, given enough time and resources). But it's exactly that -- time and resources -- which business cannot afford. Unmaintainable code is exactly that, I think.

[Trensharo]

A codebase being hard to maintain does not make it unmaintainable. It just makes it harder to maintain. IDEs and other tools, these days, actually make evaluating a code base fairly easy. You are underestimating developer skill, as well. There are a LOT of good developers out there.

Yes, many books have been written. Yes, many redundant books have been written. There are tons of beginner Python books out there, but that doesn't make it a "difficult" programming language, much less impossible to learn. It just means that tons of people have sought to capitalize on a market segment - especially back in the Early-Mid 90s when the market was making a shift and there was less documentation and case studies on this matter. These days, this is all fairly fundamental.

The fact that a lot of code was shared between Sonar and Project 5 made this even less of an issue.

In any case, this is precisely why companies have adopted coding standards - right down to how the code is formatted, how variables are named, and how things are documented in code comments. This was actually pretty common all the way back to the 80s or so. Remember Hungarian Notation?

The fallacy I pointed out was people suggesting that the entire product was abandoned because 1 developer who worked on it left the company. Any business who allows themselves to be that exposed to such a trivial catastrophe is likely not going to survive in the market (this is unrelated to what happened with Cakewalk as a company, as Project 5 was not the cornerstone of their business... SONAR was).

-----

Even back in the mid-90s, it was pretty trivial to run C/C++ code through a formatter set up with a company's standard config and then load that stuff in Visual C++ and grok it, and even debug the application fairly easily and find problem code. I'm assuming the company in question is hiring competent developers, which the SONAR developers seem to be.

[Tj Shredder]

A codebase being hard to maintain does not make it unmaintainable. It just makes it harder to maintain.

Often enough in history it was easier to rewrite the complete application than maintaining the old code.
Famos examples are Final Cut and Logic… And these are huge projects. With smaller projects like plugins that point might come earlier…
In the end the maintenance has to be paid somehow, its just an accounting question if it is worth it or not…
And if a core programmer of hard to maintain code leaves, you are not lost at all, as the basic design is still there and you could recode it from scratch and make it better than it ever was…
But only if the competition didn’t do it already successfully years ago and all former users have switched…

[careyletendre]

Project 5 was awesome , at least the v2.0-2.5 update (shown in first post )
The original gui was a mess

I think it looks great.

P5v1.5.png

This is a mess.

Sonar 8.5.png

[Trensharo]

A codebase being hard to maintain does not make it unmaintainable. It just makes it harder to maintain.

Often enough in history it was easier to rewrite the complete application than maintaining the old code.
Famos examples are Final Cut and Logic… And these are huge projects. With smaller projects like plugins that point might come earlier…
In the end the maintenance has to be paid somehow, its just an accounting question if it is worth it or not…
And if a core programmer of hard to maintain code leaves, you are not lost at all, as the basic design is still there and you could recode it from scratch and make it better than it ever was…
But only if the competition didn’t do it already successfully years ago and all former users have switched…

Final Cut and Logic were not rewritten because the code bases were unmaintainable.

They were rewritten because Apple wanted to fundamentally redesign the software as well as move the code base to Apple-centric frameworks and toolkits. Those product lines were also retargeted. So, instead of going after the higher end market segments they were retargeted towards prosumers and enthusiasts. There was a time when FCP was Avid's biggest competition (to Media Composer), for example.

The motivations for those rewrites were not a lack of ability to maintain them.

We also have to evaluate how those products function in the overall ecosystem of Apple Software. Apple has been through 2-3 major evolutions of their Application Frameworks. The most notable being the move from Carbon to Cocoa, for example. When this happens, not only is the UI affected, but also many subsystems underlying many applications (Media, Data Access and Storage, etc.). Apple tends to use their own frameworks for their applications, and when they move forwards, their software is get dragged along. Eventually, things get rewritten.

FCP, Logic Pro, iWorks, iPhoto (Apple Photos), iTunes, etc.

All of that stuff was rewritten.

Logic and Final Cut were also instrumental in Apple creating a platform for enthusiasts and prosumers, where they can get cheaper software and offset the cost of the hardware. That also gave reason to completely redesign the software so that it better targets the "new target market."

Final Cut Pro 9 was actually the biggest competitor to Media Composer in Hollywood and Broadcast, but Apple decided to forsake that market segment to focus on a different market with more growth potential (in hindsight, a brilliant decision). Largely the same could be said for Logic Pro.

Apple has been writing entire operating systems since the 80s, and a host of other larger software applications. I doubt they were having issues maintaining that code. They simply wanted to move them forwards and retarget them.

This has happened with quit a few applications.

Lastly, we can only speculate as to how much code under the UI is new. Chances are, earlier versions of Final Cut Pro X and Logic Pro X has considerably more older code under the hood, which has become increasingly phased out over the years. You just can't visually pick this stuff out (compared to, say, Win32 stuff in Windows 10/11 that clashes visually with the "newer" bits).

[Trensharo]

Often, the motivation for a rewrite is that the effort in porting is less than the effort in writing from scratch.

And often, the motivation is simply that the new thing will simply be better than the old thing.

[careyletendre]

Way off topic.

[melomood]

That's how it is with P5 nostalgia threads. There's not much else to say after the handful of people who liked it come in to say why. It was once with us,now it's not. It didn't fill some void in the computer music world and it kind of reminds you of other programs.
Noticing Bitwig resembles the layout of P5 was a bit of a fresh take on a dead horse,but the horse is still dead.

[Tj Shredder]

But its foal is grown up in the mean time…