Snow Leopard-- September: $29 upgrade

[Frodo]

http://www.macworld.com/article/141029/ ... html?t=101

I know-- this may not be the best news for PPC users or even for the current version of DP. But it is a significant landmark for those considering an Intel over the next year or two.

In about 12-16 weeks we'll probably start gathering lists of apps and plugins that are 10.6-compatible just as we did for those apps which were or were not Universal Binary or 10.5-compatible.

Having this info, imho, might help paint a better picture of where things are headed and when they might get there (wherever "there" is), whether or not one moves to Snow Leopard.

I think I'll stay put and just read "the bones" at least until NAMM, 2010.

[emulatorloo]

And I am so enjoying my G5!

It looks interesting -- Apple "Snow Leopard" page here:

http://www.apple.com/macosx/

[James Steele]

I know-- this may not be the best news for PPC users or even for the current version of DP.

I'm used to it. I bought a refurb G5 when it was already on its way out due to budget. I'm used to bad news by now. The first being the DP6/Leopard/Native Instruments issues and vague assurances that there would be fixes forthcoming. Fortunately, it only took me a few months to figure out that there was never any intention to expend effort on PPC issues any more, and I went back to Tiger. Yep... once again, I'm driving a disowned spawn of Apple.

[Frodo]

Indeed-- it may not even be the best news for many Intel users such as DAW types.

I almost hate to bring it up, but one other important barometer will be related to the 10.6-compatible version of Logic.

Apple necessarily cites Snow Leopard as being "so easy" or "more accessible". In the long run it just might be, but who knows how long it will take for everything we use now to work in 10.6. This time, the hardware itself is at issue for the first time in a long time. I'm still on the outdated Xeon and have a G5 for a sidecar, just getting this bucket of bolts running smoothly after two years of nightmares with NI and that hideous rapid series of Tiger mishaps. I was never able to get 10.5 up to production speed, so I hope this will be the first summer in a few years in which I can actually get some music done rather than to troubleshoot my brains out.

I'm certainly not looking forward to the aggregation of upgrade fees for all of my third-party software.

Just found this:

32-bit compatible.
To ensure simplicity and flexibility, Mac OS X still comes in one version that runs both 64-bit and 32-bit applications. So you don’t need to update everything on your system just to run a single 64-bit program. And new 64-bit applications work just fine with your existing printers, storage devices, and PCI cards.

I guess that's good news, but so many 32-bit apps (non-Apple) still use Carbon frameworks, so it's a little confusing to digest the concept of an all-Cocoa app not being 64-bit. Why rewrite something with all-Cocoa frameworks only to stop short?

[emulatorloo]

I used to be a mad crazy "early adopter." And no doubt I will have to have this to run on the little intel mac.

But . . .

As far as production stuff goes, I have always found life to be a lot saner if I stay behind the bleeding edge. It took several years of frustration to figure that out. Maybe that is why I am bald. I really am quite happy with the G5 for production stuff - which is solidly anchored in the Leopard world.

[mhschmieder]

Vienna Instruments has chosen to be bleeding edge, but at least they tend to get their stuff to work early. They have dropped PPC support for the new Convolution Reverb, in anticipation of going to the all-64-bit architecture of Snow Leopard.

[Frodo]

Vienna Instruments has chosen to be bleeding edge, but at least they tend to get their stuff to work early. They have dropped PPC support for the new Convolution Reverb, in anticipation of going to the all-64-bit architecture of Snow Leopard.

Wow! I've been so out of it (just got back from quite a trip). I hadn't even had a chance to get caught up on all the news. That's pretty amazing and very telling in a lot of ways.

And yet, while it sounds promising it also raises that question again about those not-so-cutting-edge developers who'll saunter over to full 64-bit compatibility in *their* own good time.

I want to believe that Snow Leopard is the beginning of something good, but it's not the end of the world for me if iCal is 64-bit or not. I don't even know how much I trust claims of "faster, easier, better" any more. We've heard it before. "Don't worry, it will work" and then it doesn't. Just can't take that risk this time around. I'm with e-loo on this one.

[Matcher]

Snow Leopard takes up less than half the disk space of the previous version, freeing about 6GB for you.

Wow.

It'll be very interesting to see what kind of updates are DAW makers coming up with in september, not the least with Apple.

[dosuna11]

I want to believe that Snow Leopard is the beginning of something good, but it's not the end of the world for me if iCal is 64-bit or not. I don't even know how much I trust claims of "faster, easier, better" any more. We've heard it before. "Don't worry, it will work" and then it doesn't. Just can't take that risk this time around. I'm with e-loo on this one.

Excuse my #$%@#$%^&* I agree with this quote we are always fed the SOS. Faster! Bigger! More fun! I am proud to say I just bought another G5 for my teaching studio. Total cost $675.00. I did not have to purchase any software or upgrades just get some new authorizations. So far only one only one problem with the speed trainer in Ampliltube. I also agree with James about driving another machine disowned by Apple. Why should we have to get better at troubleshooting a new system? I wonder if Snow will have a 64 bit beachball that spins even faster? Help! I'm thinking of my Fostex 4 track and SMPTE slave to an Atari 1040 ST!!!

[Frodo]

I also agree with James about driving another machine disowned by Apple. Why should we have to get better at troubleshooting a new system? I wonder if Snow will have a 64 bit beachball that spins even faster?

+1000

Indeed. It all looks good, and goodness knows we could do without the current kludges, crashes, and hangs. For the way some projects with certain VIs are currently set up to work, the save times have gone back to Atari ST speeds anyway, so that really is a valid consideration if there's no real net improvement.

I was just looking at my system which I'd completely reconfigured back in March. The thought of starting over with reformatting, reauthorizations, etc., only to find that the plugs and apps I need are either bug-ridden or just not available lacks certain appeal.

I will probably eventually sacrifice my Leopard drive should *enough* apps and plugs come around to 10.6 spec just to test things out. But I'm hanging onto Tiger for dear life.

[mhschmieder]

Hmm, this is a hard one for me, whether to wait for Snow Leopard (well, $29 is cheap so waiting isn't really financially necessary), since I can't use Leopard on my G4 iMac anyway so don't have first-hand familiarity with its issues. So Snow Leopard may solve old issues and introduce new ones -- waiting a couple of weeks after release may present a clearer picture as to compatibility etc.

I do have a few plug-ins that may not make the grade, such as my most important ones such as Waldorf Attack and Waldorf PPG Wave. But the G4 iMac no longer has resale value and would probably be kept around for legacy apps and plug-ins anyway -- at least initially.

I don't like being an early adopter, but sometimes you get caught between a rock and a hard place if an existing system isn't fully stable anyway. I just wish I had a better idea about Leopard/Intel stability vs. Tiger/PPC stability, to better predict the risk of Snow Leopard on a new machine.

[Frodo]

I don't like being an early adopter, but sometimes you get caught between a rock and a hard place if an existing system isn't fully stable anyway. I just wish I had a better idea about Leopard/Intel stability vs. Tiger/PPC stability, to better predict the risk of Snow Leopard on a new machine.

I think it's probably less a matter of chip/OS stability than it is a matter of how different developers have coded their apps and plugins. Your report on VSL holding out for Snow Leopard and dumping PPC support altogether for their new Convolution Reverb is rather telling. I can imagine lots of developers might be looking forward to saying good-bye to Carbon frameworks for as much work it must be to rewrite everything in Cocoa. Clearly, there are some limits with Carbon that have made it difficult for some plugin developers to even get to Intel handsomely. I felt badly for Spectrasonics, for example. They seemed to have just gotten stuck for a long minute (ie: a year or more), which resulted in the demise of Atmosphere as we knew it. Of course, they came along with other solutions like wrappers, Omnisphere, etc., but it must have been a nightmare for them and their users.

The only thing I can think to do is to start a database of all apps and plugs I use and to keep tabs of which companies make the move and when they make that move. I still get the feeling that we'll know a lot more by NAMM time. There may be a trickle of 10.6-compatible plugs and apps between Sept and January, but it could be spring before the bulk of what we use makes the transition.

On the other hand, it will be interesting to keep an eye out for those developers who will declare the end of UB support for those users still on PPCs or for those still using 10.4.x and 10.5.x.

Now-- there may be some hope of getting more info before NAMM in January, 2010---- Summer NAMM 2009 is just over a month away! For DAW users this *could be* an important "kiosk" just 6-8 weeks before Snow Leopard's release. If nothing else, we'll learn which developers are willing to talk about 10.6 compatibility.

No less important will be to see which developers are reluctant to say much at all about it.

To underscore the developer conundrum, here's an article:
http://www.macworld.com/article/141054/ ... opard.html?

Ultimately, cranking up clock speed led to excessive heat dissipation and power consumption, and chip makers like Intel reverted to adding cores to boost performance. That brought a set of new issues to software developers, who faced the challenge of writing applications to take advantage of multiple cores to scale application performance.

“As the processor vendors brought forth dual-core and multicore processors, the operating systems guys have had to play catch up in terms of bringing out software that works with the new chips,” Gwennap said. Apple has unlocked a piece of the software puzzle, as parallel processing is the only way ahead to get big gains in performance, he said.

Apple has also laid the groundwork for software providers to write multicore applications with Snow Leopard, Gwennap said. But users may not see performance benefits until programmers stop writing applications for single-core processors and retrain themselves to write in parallel.

Another analyst agreed with Gwennap, saying that programmers aren’t used to thinking in parallel, even though the problem dates back to the 1940s.

“Programmers have to be educated to think about how to break down their program into multiple tasks that can execute simultaneously,” said Tom Halfhill, senior analyst at In-Stat, and senior editor of Microprocessor Report. Native support for OpenCL in Snow Leopard could encourage more programmers to write in parallel.

So, the learning curve is less of a myth than it may appear.

[SixStringGeek]

I just spent a week in San Francisco at Apple's developer conference (and now I need to go work out and drop all the weight I put on - SF has too many good restaurants).

So, here's the scoop I can tell you without busting NDA.

First, 3GHz appears to be the practical limit for processor speed. That's it. No faster. They've hit the wall in that dimension. So now, new chips come with multiple processors on board - more processors, but not faster ones. This is the new direction of scaling.

Unfortunately, programmers have been thinking and writing linearly and this thinking is much ingrained in us. We need to relearn our craft to take advantage of this. Someone joked about a new 64 bit beach ball. Actually, the goal is to kill the beach ball and never ever see it again. The beach ball is automatically displayed by the system when an application takes a long time to poll for the next user event. See, the typical mac app runs in an infinite loop. Get an event (keyboard, mouse, network, disk....), then run some code to respond to the event - which may take some time depending on what the event indicates (did the user just ask for us to convert multiple gigs of data to a new format? - OK, here we go......beach balll.....done get a new event).

Which is stupid now. We have multiple computers in the box. What if one processor got events, then scheduled the resulting actions to occur on other processors? The system would appear to be responsive all the time. Of course, there are some facilities for doing this now (threaded programming) but the problem with threads is concurrent memory accessing, locking, and a general ignorance of the programmer what computing facilities are available. How many threads should I use? A dual core mac pro has two processors, an dual quad has 8. It can run more threads than the macbook. But it is asking a lot for a programmer to figure this out.

So Snow Leopard provides something called grand central dispatch that provides work queues for tasks. The main thread throws jobs at queues and then gets back to handling user input. Demos of various things like Mail.app showed overall speedups with factors of three or more. This is a big break from the traditional thread model and is MUCH easier for developers to work with.

Programs need to be restructured to take advantage of this but restructuring isn't that hard. If they don't, they'll continue to work the way they do now, but for developers who do the work, it will feel like getting a free hardware upgrade. I believe this is why Snow Leopard is practically free. Apple wants everybody to get it - no excuses. Its a new era and they want people to change the way they write programs. They actually said in one session that anytime your app comes up with a beach ball, you should probably move that task to a different work queue. They don't want to see that thing ever again.

64 bit is also a biggie - we're already hitting the 4G limit on plugs in DP. Its not hard to support 64 bit - mostly a recompile for stuff that doesn't use Carbon. Hopefully all the plug developers will rebuild their stuff and issue (nearly) free updates but until they do, we're going to be stuck with 32 bit DP or DP will need to adopt some kind of 'buddy host' strategy like people are employing with bidule.

Third thing that could hugely benefit us is OpenCL. The idea is that we have these graphic processors that are really good at vector operations (doing the same thing over and over to a big data stream) but you have to be extra clever to use them. OpenCL lets you write a processing procedure once, then throw it at the system and have the vector operations (audio is essentially a big vector) applied either by the highly efficient Graphics Processor, or on the regular processor - the code is dynamically compiled on the fly for the hardware on which it will run. This will allow some of our more expensive effects to be offloaded to the graphics cards and lighten the CPU load. We'll get more processor cycles out of our machines.

Snow Leopard is promised to run on all Intel macs. I think it will be one of the least disruptive updates ever except for the dropping of PPC support. To be honest, most industries consider the useful life of a computer to top at 3 years and even I (who has business oriented macs all over the house) don't own a working PPC machine anymore to test against (my last one died last Dec). Most probably, Snow Leopard will actually extend the useful life of Intel machines a year or two as developers begin to wring all those wasted cycles from our hardware.

[Frodo]

So, here's the scoop I can tell you without busting NDA.

First, 3GHz appears to be the practical limit for processor speed. That's it. No faster. They've hit the wall in that dimension. So now, new chips come with multiple processors on board - more processors, but not faster ones. This is the new direction of scaling.

I have a feeling that once 64-bit true multithreading is a fact of life that we'll see that 3G barrier broken eventually. I recall a 1GB hard drive Apple made years ago-- one of the largest made available to the public. Price was $5k-- and the quote still rings in my ears: "there's no way you'll fill that thing up in a million years". Truth was, there was no way I was going to spend $5k on anything at the time!!

And that alleged 16 exabytes of RAM? We'll grown into that as well. Seems so far-fetched now.

But until then--- we need to get past the current transition handsomely.

Unfortunately, programmers have been thinking and writing linearly and this thinking is much ingrained in us. We need to relearn our craft to take advantage of this. Someone joked about a new 64 bit beach ball. Actually, the goal is to kill the beach ball and never ever see it again. The beach ball is automatically displayed by the system when an application takes a long time to poll for the next user event. See, the typical mac app runs in an infinite loop. Get an event (keyboard, mouse, network, disk....), then run some code to respond to the event - which may take some time depending on what the event indicates (did the user just ask for us to convert multiple gigs of data to a new format? - OK, here we go......beach balll.....done get a new event).

Death to Beach Ball!!

.....But it is asking a lot for a programmer to figure this out.

....Programs need to be restructured to take advantage of this but restructuring isn't that hard.

I was a little confused by these two statements (and will go back to re-read the stuff I deleted just in case I missed something).

"asking a lot" and "not that hard"?

64 bit is also a biggie - we're already hitting the 4G limit on plugs in DP. Its not hard to support 64 bit - mostly a recompile for stuff that doesn't use Carbon. Hopefully all the plug developers will rebuild their stuff and issue (nearly) free updates but until they do, we're going to be stuck with 32 bit DP or DP will need to adopt some kind of 'buddy host' strategy like people are employing with bidule.

Quite true-- and we'll be playing more beach ball until all developers get up to date.

I really appreciate the info, Six. It's quite consistent with so much of what I've seen and heard.

[carrythebanner]

.....But it is asking a lot for a programmer to figure this out.

....Programs need to be restructured to take advantage of this but restructuring isn't that hard.

I was a little confused by these two statements (and will go back to re-read the stuff I deleted just in case I missed something).

"asking a lot" and "not that hard"?

I understood his post to mean that it was asking a lot for each programmer to manage this sort of thing on their own, but it isn't that hard if they rely on Snow Leopard's shiny, new features.