Leopard internals (or DP will have a major redesign)

[michkhol]

http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/6

Leopard 64bit API dropped Carbon, it is time for MOTU programmers to learn Objective-C to catch up.

[Shooshie]

Well, I look at this as good news ultimately. Instead of patching up DP, MOTU is going to have to rewrite it. In some cases, that's going to mean looking at the desired outcome and writing completely new algorithms to make it happen. This has to be good, if they have good programmers. Instead of putting off all those fixes that would "break the code" if they fixed them now, they'll be able to integrate those into completely new code design. And if they do it modularly, bug fixes should be updated with faster turn-around.

Unless... they hire amateur coders for this. Or... if they decide they just can't afford to do it, and they simply drop DP entirely. But they have already said they are working to make DP fully Leopard compatible. They're going to rewrite it, apparently, and I'll bet they've already been doing that for many years. We'll see. I can say this, however: if MOTU rewrites DP in Cocoa, we're going to be looking at the killer DAW of all time. It will be fast like Logic, it will have features that we know and love which set it apart from all the others, and adding new features will be quite simple. We're in for a wild ride, and the result is going to be astounding.

Shooshie

[Frodo]

I agree on all counts, and will remain hopeful and patient.

We're in for a wild ride, and the result is going to be astounding.

Shooshie

Yeah, the result *is* going to be outstanding, but the ride and the line to get on that ride will most likely be...

Well, let me put it another way: it's the people you meet along the way that make the journey worthwhile!!

[billf]

But they have already said they are working to make DP fully Leopard compatible. They're going to rewrite it, apparently, and I'll bet they've already been doing that for many years

This is going to be interesting. DP6 as the DAW killer app? That would be nice.

[monkey man]

This is going to be interesting. DP6 as the DAW killer app? That would be nice.

I'm counting on it, Billy.

[SixStringGeek]

Unless... they hire amateur coders for this. Or... if they decide they just can't afford to do it, and they simply drop DP entirely. But they have already said they are working to make DP fully Leopard compatible. They're going to rewrite it, apparently, and I'll bet they've already been doing that for many years. We'll see.

Actually, they'll only need to rewrite the user interface. I'd guess (total swag here) that this is about 25-30% of the whole thing. Not too bad really. Also, they have a little time here because Leopard brings the ability to mix Cocoa and Carbon more easily in 32 bit apps - which means they can ship 32 bit upgrades for a little while with each one containing some greater fraction of Cocoa and less Carbon.

So they have a little time to work - but no time to lose.

[Frodo]

- which means they can ship 32 bit upgrades for a little while with each one containing some greater fraction of Cocoa and less Carbon.

That's an interesting thought, SSG. I wonder what would be more trouble-- to do the incremental Carbon-to-Cocoa process and catch the potential glitches that may result, or just to knock the house down and start from scratch....

64-bit is indeed another ball of wax, but 32-bit functionality really does leave some doors open for a more gradual step up.

Good thinking, G!

[Shooshie]

Unless... they hire amateur coders for this. Or... if they decide they just can't afford to do it, and they simply drop DP entirely. But they have already said they are working to make DP fully Leopard compatible. They're going to rewrite it, apparently, and I'll bet they've already been doing that for many years. We'll see.

Actually, they'll only need to rewrite the user interface. I'd guess (total swag here) that this is about 25-30% of the whole thing. Not too bad really. Also, they have a little time here because Leopard brings the ability to mix Cocoa and Carbon more easily in 32 bit apps - which means they can ship 32 bit upgrades for a little while with each one containing some greater fraction of Cocoa and less Carbon.

So they have a little time to work - but no time to lose.

I'd heard this a long time ago, but I haven't seen anything recently to substantiate it, and in conversations with my son (who programs in Cocoa and many other environments) I'd kind of gotten confused as to whether that was still going to be possible. (He loves to confuse his old man) I'm REALLY pleased to hear that it works that way after all!

Shooshie

[Dave Bourke]

I somehow doubt that rewriting the user interface is gonna sort out many bugs. A bit like repainting a house with dry rot.

Kind regards.

[rainy-taxi]

rewriting the GUI doesnt do anything to the functionality of the program itself. It only changes the access to the functions. Its more about starting from scratch and program a new digital performer and use a new program structure to m ake updates more modular and thus faster updatable.
Only small "problem" is that it will take a lot of time to start from scratch again. I don't know how much programmers are working on DP but I can imagine that it will take a long time to start from scratch again.

[michkhol]

The biggest problem is that DP is written in C++ but there's no C++ support in Cocoa. Cocoa GUI has to be written in Objective-C, so start from scratch here.

It is possible to leave DSP engine in C++ provided it wouldn't use any of the Carbon APIs. But it means that at least two wrappers will be needed, one from Objective-C to DSP C++ and the other from DSP to the underlying Cocoa core, in short - total mess. And remember about MAS. MAS works only with carbonized plugins (grimepoch, correct me if I'm wrong), so for 64bit edition MOTU will have to break backward compatibility. All existing MAS plugins will have to be rewritten to use Cocoa API GUI and I think it is unrealistic. I think MOTU will drop MAS support in favor of AU for it's 64bit version.

All programmers in the DP project will have to know Objective-C and Cocoa which essentially means a new development team and a totally new DP.

[mhschmieder]

Maybe it's time to switch to QT.

I worked directly in the computer industry for decades, and have been in the audio business as a software engineer for over half a decade. I feel MOTU's pain, because we are dealing with platform issues here as well. And it's harder to have your concerns taken seriously by vendors when you're outside the core industry -- even Adobe has trouble with this!

My main app is written mostly in Java, partly because we thought it would insulate us from platform issues (at least to a degree), and I'm currently evaluating and working with Eclipse RCP in place of Swing (which I've used for years), for better native compliance and look-and-feel. I also have a long background in C and C++ based GUI tools, and a little bit of experince with QT (which is the main programming tool for most of our other apps).

Unfortunately, there is no panacea, and as these issues with C++ vs. Objective-C vs. MAS vs. AU vs. 32-bits vs. 64-bits vs. Carbon vs. Cocoa show, it is nigh impossible for a vendor to pick a set of tools, programming languages, etc., for scaling long-term product growth and a framework of reusable components for tiering multiple products, without eventually being bitten by a surprise of some sort that throws the whole strategy into a mess.

Having evaluated all of the available tools (including XML-based design and implementation tools), and having these past few weeks (since Leopard came out) brought my knowledge up-to-date on the internals, I am convinced that no decision could be made today that might not be regretted tomorrow. There just isn't enough of a mechanism in place in the industry to keep vendors on a standard even if they adopt it, and to convince them that everyone gains from having a common set of protocols that are abstracted beyond the choices that vendors make towards their own competitive advantage.

Contrast this with a mature industry like automobiles and it's startling how differently the two industries operate. By now computers are a mature industry, and if the main vendors continue to make life difficult for small third-party developers and end-user-application companies, I'm pretty convinced that more and more people will move away from computers and back to dedicated hardware (whether standalone hard disc recorders, or whatever else is appropriate to the field of endeavour).

Companies like MOTU are at least "in the business", whereas my own company is only "sort of" in the business (yet that is starting to change due to our growth in the area of DSP). In both cases, and in the case of most of the other vendors that many of us deal with for our main productivity tools, the resources just aren't there, nor are the "volume dollars" for these niche market tools, to support ripping out the core of a product or product suite every few years and doing it over. Nor is that productive towards the end goals of the business logic being implemented, or the needs of the consumer/customer.

It's easy to blame MOTU based on a simplistic view that Apple "warned" everybody that they should move to Cocoa. The real picture is a lot more complex. I wouldn't even know how to advise MOTU at this point, as I'm not 100% confident of my own decisions moving forward (until they have more time to play out), but I would still harbour a guess that a more platform-neutral toolkit or framework might be a good move, if things have to be done more or less from scratch anyway.

Although I'm none too eager to move to QT from Java myself (I switched to Java from C and C++ for a reason ), it now hosts Java including Swing and SWT/JFace. Amongst other languages, I think, but I didn't look in detail. A licensing fee is entailed, however. And also, QT, AWT/Swing, and SWT/JFace are all three currently based on Carbon when it comes to the Mac side of things (but at least the code will run fairly well on multiple platforms with only minor tweaking and slight configuration differences).

I didn't realise the DP code base was written in C++. Given the choice of C++ vs. Objective-C or C# (without Java, Ruby, or other languages entering the picture), I would be highly resistant to a vendor-specific programming language that ties in too big of an investment to assumptions about where one will be positioned in the industry in a few years time. Whether or not MOTU has plans to make DP dual-platform, I doubt they'd want to make this a more difficult proposition than it needs to be, by using Mac-specific Objective-C in Cocoa.

Objective-C is a well-designed language, and maybe it is more portable than I have come to believe, as Gnu's gcc can support it as long as it doesn't make use of some of the extra features (many of which were derived from Smalltalk's messaging facility). My experience with languages that are tied too closely to a hardware manufacturer (Java being an exception, outside of the poorly-designed event model of the Swing GUI toolkit), is that they tend to move forward in ways that often involve major rewrites -- unlike languages that are maintained by standards committee and which are used widely on all platforms (C, C99, C++, Java, Perl, Python, even FORTRAN, etc.).

We ran into some of the dreaded single-vendor programming language issues here when Delphi (which is based on ObjectPascal) kind of fizzled out and the tools stopped being supported (which meant that system/platform updates were at risk of eventually breaking the code). That was when we switched to QT for at least some of our applications. Delphi came from Borland, who sort of "went away" a few years back. Apple is not going away anytime soon, but still developers are at their whim if they decide to switch out technologies from ObjectiveC to something else and then force that on people.

FWIW, QT is vendor-specific (though widely used and partially open-source, as well as being the basis for one or more Linux GUI desktops such as KDE), and from version to version may make sweeping changes that require large code rewrites or modifications (though within the context of similar languages and tools). This is why I say there is no panacea (including Java, whose pitfalls and especially those of the Swing toolkit I am particularly familiar with).

I would not want to be in MOTU's shoes right now. They have a lot more at stake than we do and cannot shift gears as easily due to legacy, size of customer base, complexity and number of relationships with plug-ins, etc. I think it's fair to say that they have as difficult a task in adapting to Apple's evolving business model as companies like Adobe.

[MIDI Life Crisis]

I have to say reading this thread makes me feel like I really know nothing whatsoever about computers. C++, Cocoa, Pepsi?

Dang, this is complicated stuff. No wonder there are such long periods of time between non-functioning releases of software. That any of it works at all it simply amazing to me. All 1' and 0's you say?

Just makes me DIzzy!

[FMiguelez]

.

Mhschmieder:

Wow. Thank you so much for sharing all that info. I think you taught us (at least me) a great lesson. This helps understanding from the vendor's point of view some possible reasons as to why they take so long to fix things, etc., and it definitely shows that these issues are always SO MUCH more complex than they appear from our perspective. Without knowing these things, no wonder it's so easy for us to just say "what's takin' so long for these lazy bums to write some code"?

Looking at these things from thier perspective is very iluminating. Doesn't make them less annoying when they seem to be slow at fixing things, but at least it becomes a bit more understandable.

This is like AT LEAST knowing part of the reason as to why your girl is mad at you, instead of getting the "Nothing" when you ask her what's wrong

[mhschmieder]

Well, I almost removed that post for fear that it was too revealing about my own company's development plans and status, and still might do so if a re-evaluation triggers any such alarms.

Interestingly, I had a similar discussion with my boss the other night, and we both concurred that, whereas as recently as a few years ago, one could make technical choices that an experienced engineer could feel rightly confident would be "right" for at least five years (as a technical direction and as some level of future-proofing), that window has now narrowed to 18 months at best.

I can at least report that in the past week I have steamrolled ahead with IBM's Eclipse RCP framework (primarily Java-based but also heavily XML-based) and will hopefully have a chance very soon to verify whether it also works on Leopard . The hardest part is configuration and the like as it is poorly documented and changes a lot with each release (and most docs are one release behind by now). But this is true of most high-level technologies, unfortunately.

Really, the choice of language itself is not so severe in how it impacts development, as most modern programming languages are at least partially Algol-derived and have more similarities than differences in terms of core features, standard libraries, syntax, and semantics. It's at the higher level of GUI design, framework design, where things are most volatile and where rewrites are usually a better way to go than direct ports. And of course those are the very apps/projects that are the most complex and require the most manpower to rewrite/retrofit/recode.

A good analogy would be that if you have a small schoolhouse, you can just patch the roof. But if you have the Empire State Building, you have to tear it down and rebuild it from scratch in order to address problems with the roof. This is obviously insane and cannot continue if major software products are going to manage to keep up with hardware, OS, and platform toolkit/GUI changes.