Regards SL generally, pretty positive all around. Some really tangible speed & operational improvements .
Regards QC SL - very interesting, I no longer consider the difference in the interface between the two much at all. The OpenCL & Mesh facilities have been a delight although you, I and others have found a need to fix some things for ourselves.
I'm not too favourite with QuickTimeX. It's good for what it looks intended for by and large. Just glad I can still keep QTPro for manipulation, encoding, decoding and other media engineering operations.
I'm going to add a couple of things that bring me joy, that come to mind off the top of my head:
I enjoy the fact that I can publish out of an iterator.
I like that smooth works in an iterator now.
I like not having to think too much about the texturing of large 3D objects/scenes where many images/source textures would need to be manually handled otherwise.
I like some of the visual qualities and effect of mesh filters.
I enjoy the effect of the hidden option for multisampling.
I like that qtz's load plugins when iTunes runs them now.
As far as the OS goes, I don't find it to be "snappier", but it may be because of what I'm using as a barometer. Everything I'm describing is when using the same machine, and considering SL in aggregate vs. 10.5.8:
It takes more time for the my Desktop and Finder to load in SL and it does in Leopard.
When opening Safari, when I go to fill in text fields, it hesitates the first time, in SL. There are many other instances where SL feels "sluggish" in responding to user events.
Spaces seems to work less smoothly, and lags more on when you first log into a user account.
Finder results seem to generate more slowly for external HD's.
With QC Mesh, I like the things that it has brought to the table, but I don't think that rendering static DAE's is extremely useful by itself. I don't think that the mesh creator being broken is particularly great either, since it is somewhat fundamental. I don't enjoy that Preview has more control of dae's than QC. I also don't enjoy that there are no facilities for loading skinned mesh. I wish that certain things that seem fundamental were better documented, or worked (eg., construction of normals from arbitrary vertices), since not being able to generate normals means that things can't be lit. I do really like the idea of having an integrated geometry engine, and there are many benefits of the mesh system.
I don't particularly think about the SL interface too much, because I'm using Kinemecore, that cleans up some of the speed problems, but every so often I talk to someone who loads a really large composition with tons of noodles, and I get to hear about how QC can barely render the editor. I have a fun photo album of really wretched QC editor problems, from noodles with no patches, to noodles that chop in half, to giant areas of garbled glitchiness in inspectors, and feedback ghost noodle trails on the editor. Good stuff! However, I'm truly not complaining too much, because even with these issues, I think that QC is miles ahead of other node based environments, in the usability and look of the Editor. I do still use Leopard, and it seems easier to see non-active noodles for some reason (maybe this is placebo), and it's less straining on my eyes in general.
I like the way that the menu bar and controls fade away from Quicktime X. Whoever thought of that should get a big pat on the back. I'm not so sure about the way that the video transport can get moved around anywhere though. It is also a pain that there is no way to use something like "Grab" to take an image of just the Quicktime X screen without the video transport popping back up. The way that the Quicktime Pro options don't load into Quicktime X means that I use my old Quicktime in SL all of the time instead of Quicktime X.
In looking at other node based environments, I'm only reminded of QC's strengths, but I think that they are taken for granted, and that there has been an amazing lack of innovation. It's also really surprising that some stuff was released with the glaring bugs that they have. It's a gigantic time waster in that regard.
I always had crashes, and expect them if I'm putting something together and do something stupid, or even that a system will have some bugs.... for instance, it's pretty darn trivial to pull some choice moves with FreeFrame and explode QC, or put a string that's too big somewhere, and crash stuff, or use external plugins that cause crashes, all in Leopard.
None of those ever did stuff like freeze my system, give me kernel panics (except ONE time), cause weird display flickers (by that, I mean "blackness" in a strobing fashion from the bottom to the top of the display) with system locked, give me spontaneous logouts, etc.
There is some stuff that is really cool though:
QC's explode macro feature is AWESOME. I love being able to pop stuff out of a macro like that. It's almost easy to overlook with all of the kinemecore transmutate macro, and publish/unpublish all features, but the explode macro is something I use all the time.
Interaction on the Viewer has, on a couple of occasions, saved me a ridiculous amount of time when getting stuff aligned in a pixel accurate way, in getting stuff in the general areas they should be in quickly, then tweaking the rest of the way manually. I do find much promise in the premise and would like to see new methods of controlling stuff while manipulating the Viewer area.
I really like the concept of an integrated geometry pipeline. It's cool that openCL filter kernels amount to how I think GLSL ought to work in QC (but doesn't), in many ways. Trying to keep it positive in tone, but it's irritating that the mesh creator is problematic, and also not a great that there are weird evaluation bugs with new patches that have been introduced. I'm at a loss to think of one new feature that hasn't introduced bugs in some ways, though they make work and have legitimate use within narrow parameters.
I have run into occasions where stuff runs faster in SL, and that is VERY cool.
Feedback being supported in CI, and extrusion in GLSL are really cool. I don't know how much that has to do with QC, but either way, it is major benefit, to me.
I like that the mesh renderer gives a way to render a structure of points without iteration, and texture them decently as well. I REALLY like that vertex info is exposed on 3D models, and also that I can make a model, get all of it's vertex info, and then place an object at every vertex. Having that raw vertex data is maybe my favorite aspect of QC4, aside from publishing out of iterators. However, I want the results of publishing out of an iterator to be 4x or more snappier! I want it to handle calculations on all of the vertices (and more) of a 3D object, without hesitation.
Biggest disappointment overall (if you ask me this minute) has been no skeletal animation. The idea that we have a collada engine and don't have that boggles my mind. I seriously expected there to be lurking functionality in that regard, and have been seriously saddened that there wasn't.
Actually, biggest disappointment is that there is no QC"mini" or QC full environment for iOS. It would be great to be able to make apps that play/generate media and provide some cool QC-esque interactive control methods. I can think of tons of stuff I could do without CI support and with only a limited subset of GLSL. I think the fact that this doesn't exist is hamstringing QC.
IOSurface is looking to be interesting indeed. I wish there was a way of leveraging more control between apps with an over-riding framework, so that it would be easy to have apps control the menus of other apps ( a big "whatever" to people that think that idea is ludicrous ).
To Apple's credit, continuing to maintain an architecture they 1) no longer sold and 2) were running out of working on-hand machines for testing on would produce the following fun side effects:
1) lower build quality (half the bug hunting time would be spent on the dead architecture)
2) larger binaries (more dead code for more customers)
3) fewer features (half the feature development time would be spent making sure stuff works on ppc, or skipping it because it had no equivalent on ppc)
might as well complain that m68k was ditched too. and 65C816. and 6502. man, those cheapskates...
You know, it occurs to me sometimes when I talk to very savvy people that some of QC's best new features in SL still aren't really known/thought about. I know that the stuff is "sort of" in the Read Me/Release Notes, but I know certain handy features have been overlooked by people that don't have the time to go finding them.
I've discussed "issues" I have with texture handling and QCMesh (ironically, thinking that it's too abstracted), but in talking to people:
I realize that many people don't know that the Collada/DAE loader loads in fully textured scenes in one shot! This means you can have a model that loads hundreds of textures, some that tile over parts of the model, other textures that cover a "sub-object", and it loads totally automatically. Not a challenge at all. This is really handy, and makes doing all kinds of previewing, and basic viewing and rendering of Collada instantaneous. Really awesome power.
The other thing - the shadow engine does_have_bugs. It_can_look_ugly. However, it can also really be usable. ( http://www.vimeo.com/6317773 ). I'm not sure that any shadow method could be accurate "work" in every given scenario. It doesn't inherently break anything when it's not on, so it's not as if it's a constant thorn in the side. It's really beneficial for some things, to me.
The ability to import image structures by extracting all images and embed them in the composition in SL is SUPERB. It's essentially a movie embedder + tons of other useful functionality by adding that one feature.
...and while I prefer the Leopard QC interface, I think that the glossy/dark look is very modern, and that it isn't too bad. I think overall, it's a better choice to move forward than it would have been to stick with the 10.5 design. Using other node editors shows that QC is at the head of the pack as far as having a great GUI (for me).
gtoledo3 wrote:
The ability to import image structures by extracting all images and embed them in the composition in SL is SUPERB. It's essentially a movie embedder + tons of other useful functionality by adding that one feature.
Leopard has this feature on the Image importer patch settings if that's the patch you're referring to. I think it was you who brought that to my attention with your SL embed a movie post ;)
Mind you, I've spent hours and hours trying to isolate a Rendering bug that only happens with multipage PDFs made in AI. It occurs randomly (as in might not happen for >100 stop starts but then can stay for another 100 stop starts of comp). When the Image Importer patch set to 'extract all' or Kineme's PDF patch (which I prefer b/c of flexible 'raster' dimensions) with a multipage PDF are connected to a sprite or billboard is when I see it.
The bug usually manifests as 'white out' of the sprite/bb but also can give a b&w RAM noise image. It can also bug out across compositions… quite an eye opener. I'l document it one of these days, I've been collecting screen saves etc and have tried every version of PDF known to the print world… (nearly) and they all get it. Need to try a multipage made in another App like Preview maybe.
While I do agree about supporting two architectures it is the one they've chosen that IMO is the problem. Something was lost while porting from Intel to PPC and then back again and the 32 bit MacIntel never should have been introduced. I have been doing graphics on a Mac since the 80's and have never experienced such a long list of issues save OS 7.
Once upon a time things really did "just work" and now I get excited when I can read a disc on the same machine that it was created on or create a video whose audio track doesn't wander all over the place. Even browsing through the finder seems too intense for the processors causing the beach-ball to spin.
My "complaint" is that, other than the price, there is nothing about the Mac that sets it apart from the Dells or HPs anymore.
That feature is in Leopard too? No kidding. That's great.
I understand the "premise" of using the Kineme PDF, but if you're ultimately importing a structure of image, and not vector graphics. I don't find that aspect of that patch to be useful, I would rather it come out at the default resolution. Also, you can't load the whole structure at a time, and...it's a plugin. The one thing that it has an advantage on is that you can load file name at any time... I think the stock image importer handles pdf's this way though. The patch is somewhat of a headscratcher for me.
They never went from Intel to PPC. The only effective change is endianess, which can be brutal for programmers who aren't careful. Oh, and altivec optimizations were rendered useless, though industrious programmers can use SSE to replace most of that (though not all: fmac is still troublesome).
Disc formats have been "solved" for essentially forever - HFS+ has provisions for both endianesses, and has always had drivers for both. If there's been a problem with that, it's due to 3rd party tools. (I'm no HFS+ apologist, but messing something like that up simply wouldn't fly). FAT is always little endian, and ISO9660 is always what the red book says. Any other FS is 3rd party, or NTFS (which means OS X didn't write it in the first place, so still 3rd party).
Audio wandering has to do with clocking and synchronization -- crappy encoders, crappy decoders, and crappy players can contribute to those problems. Thankfully, neither PPC nor X86 care, and both will happily run crappy software. The transition had nothing to do with that. (I'm going to have to plead the fifth on whether not not QT qualifies as crappy)
Are you seriously suggesting that PPC set Mac OS X apart? If so, how? Because it was so fast/powerful? (hint: it's not - x86 runs circles around ppc in terms of 1) core count 2) memory bandwidth 3) and vendor support). X86 provides some convenient benefits: ability to run optimized x86 code (ports from other platforms), ability to tap into the massive commodity developer base that has worked on x86 (like myself), no supply shortages (back in 2004, G5 shortages were problematic for actual shipping products -- IBM has enough other stuff going on that missing a shipment is a don't-care. For companies that depend on said shipment, it can be fatal.) Perhaps you mean PPC was RISC, while x86 is icky CISC? That battle was fought decades ago, and the winner was "both" -- CISC slaughters RISC when it comes to code density, but RISC has huge wins in decoder logic and compiler writing. Intel retrofitted in RISC core+pipelining into x86 with the 80486 (single-stream pipeline - 1989), pentium (dual pipeline - 1993), and pentium pro (risc core + fuser - 1995). Compiler complexity ended up being a don't-care in this situation (it essentially hobbled Itanium though).
I'm not a Mac apologist -- I fully advocate using the right tool for the job, and OS X isn't always that tool. But I'm really curious to know why you think the CPU had anything to do with the value of purchasing a mac then or now (other than marketing). The market says otherwise.
The NeXT operating system worked on intel since '93. When it was bought by Apple, Apple bought an Intel and a PPC architecture (+) that both worked. It wasn't "oh crap, we have to write an Intel version from scratch in one release cycle".
I know that the "value" of Macintosh is the pairing of software with hardware, and that it's supposed to be vetted so that the combinations "just work", but I really don't think that the grass was greener when stuff was PPC.
Yep -- and next stuff worked on both simultaneously, so it wasn't like there was a migration from intel-only features to ppc, and then back. :)
One other cool quirk people don't talk about: intel is in the business of making CPUs. if they don't work, intel takes a ton of heat since it's all they do (cf. FDiv bug, F00F coma bug, others). As such, they're quite rigorous when it comes to testing. PPC (and to a much larger extent, Motorola) cpus had way more bugs that needed software workarounds (for stuff like integer division by 256, 32 bit wraparounds on 64bit additions/subtractions, and other quirks). good times.
Then Apple is selling crappy software and crappy hardware.
I use 3 3rd party programs 2 of which were under $20.00 ( one being QuartzCrystal) and one was over $3400. All of them work better than Apple's own apps. QT, FCE,FCP/S, iTunes and Safari are all crappy according to you.
You hit the nail on the head and it's called ISO 8601. A multi billion dollar fraud is what you are saying it was. I agree. Maybe Apple should have put more of an emphasize on it and instead of considering wether or not I (HI) could understand it worried more about wether or not their own software can understand it. They did address it in a QT update but didn't quite get it. The Mac OS broke after OSX.3.7 and QT6. If I weren't retired and relied on a computer on a daily basis I would be using OSX3.7 and QT6 or would have "switched", like so many others, to Windows.
Seems others on this thread have the same issues and all have to do with the ability, or more appropriately the inability, of the processor to keep up with simple mundane tasks (maybe Apple should have gone with AMD as Intel..., correct me If I'm mistaken but both Intel and NVIDIA use AMD's SW or a derivative thereof). Even Apple's switch to NVIDIA's GCs proved to be a failure. Apple's unreliability was evident in OSX.4 even in the PPC (with how many architectures supported with 10.4.4?). A monumental attempt but certainly not an achievement. Safari Beta was mind blowing Safari 5 just blows. Apple updates used to be full of new features now they are full of "fixes". JB Weld. It appears to be fixed at first glance but it really isn't.
I am looking to replace my recently deceased 667 so I can do some simple things without the need for all the hokey pokey. I love workarounds it's the stonewalls that get to me. Maybe Apple should have used the version of ISO 9660 that they've used in the past and at least maybe their machines could read the discs it creates with their own software. I used to partition my HDDs for third party software compatibility now I do it for Apple's own software and hardware. Pretty pathetic. Nothing on the machine I am typing on is original although all replaced and OEM by Apple. 3rd party discs work Apple's doesn't. Not even the original discs that came with. the computer. Beyond pathetic. They replaced the whole machine twice and every part on it till the warranty expired. GIGO
I won't pretend to have even one percent of the knowledge of computer programming that you have as if I did I would/could have created my own programs like Crystal. Kudos to you. The PPC architecture was much more forgiving to people like myself. I can't divide by zero either. If you could include .pln and .gsm (not the audio file) in kineme 3D I'd buy it in a nanosecond but I'm bot so sure Apple understands that anymore either.
All the excuses for no G5 Powerbook and bla, bla, bla, were just the proverbial SUTA because I and many others have experienced every reason Apple gave for their non existence except for the real one. All three players in the game (AIM) were bagged for copyright infringement and chose not to make a deal. The PPC still rules in the graphics department without a dedicated graphics card because It can chew gum and walk at the same time. Intel can't. Never could and never will. The only reason I ever used an Apple to begin with is that in an office full of IBM's/PCs they couldn't do what the Apple could. I should be able to replicate some of those things but Apple is no longer capable without 3rd party software.
Something set Apple apart from the rest and it is becoming more and more obvious that it wasn't it's OS.
reinformit wrote: QT, FCE,FCP/S, iTunes and Safari are all crappy according to you.
I'd rather words weren't put in my mouth. My only usage of crappy was for video encoders/decoders that don't properly synchronize audio with video -- no other subjective measures are used for that qualification in this context. If the encoder is bad, then there's simply nothing the decoder can do to keep it synced. That's not a failing of the player/decoder. Is a CD player crappy because it can't play a microwaved disc? Whether iTunes and Safari are crappy depends heavily on details outside of their control.
reinformit wrote: You hit the nail on the head and it's called ISO 8601. A multi billion dollar fraud is what you are saying it was. I agree.
Nope, I said ISO9660 and I meant it -- in context we were discussing file systems, of which ISO9660 is used to describe how files are laid out on CDs and DVDs. This hasn't changed in an enormously long time, with several conforming implementations for all platforms. I also never called anything a fraud. ISO 8601 deals with date encodings, which doesn't matter for filesystems (they all use binary encodings because they're more compact). Coincidentally, standards aren't perfect (cf. http://unicode.org/cldr/trac/ticket/2845 -- I filed that bug against the LDML spec, which deals with date and time encodings having an ambiguous/erroneous representation), so implementations will sometimes be subtly different. The oft-cited OBJ file format for 3D is one such example: there's no set standard, and so many permutations of what actually entails a valid OBJ that writing a fully functional OBJ parser requires heroic amounts of effort.
reinformit wrote: Seems others on this thread have the same issues and all have to do with the ability, or more appropriately the inability, of the processor to keep up with simple mundane tasks (maybe Apple should have gone with AMD as Intel..., correct me If I'm mistaken but both Intel and NVIDIA use AMD's SW or a derivative thereof). Even Apple's switch to NVIDIA's GCs proved to be a failure. Apple's unreliability was evident in OSX.4 even in the PPC (with how many architectures supported with 10.4.4?).
Again, this isn't a shortcoming of the CPU, but the software. You wouldn't believe the number of stupid mistakes I've committed, and the same goes for other engineers. All the performance complaints on kineme.net typically revolve around QC being slow (which is a function of hideously over-object-oriented design, and disappointingly out of date OpenGL design), and OpenCL being slow (which is a technology that is largely irrelevant in the commercial sector -- QC puts a lousy face on it, but it's a technology that isn't well-suited for the processing QC provides anyway).
The current GPUs, even with bugs, are wildly more powerful than previous generations. Whether or not software adequately reflects that isn't a shortcoming of AMD, Intel, nor NVidia.
Can you cite the failure statement? Sounds more like frustration talking (which I share when dealing with GPU/driver bugs), rather than a real event.
Regarding everyone using AMD software, that doesn't mean anything. Intel and AMD both publish reams of source code. So does Apple, Nvidia, Microsoft, and countless other technology companies. AMD has been more affordable, CPU-wise, but with lower performance (since Intel's Core architecture at least -- prior to that, benchmarks tilted towards AMD for several years) and "weirder" standards (SSE is a mess on AMD, 3DNow! is irrelevant). Intel used AMD's 64 bit extensions (and pays a license for that I believe?), but that only covers how instructions are encoded -- how they're decoded, scheduled, pipelined, cached, and executed are proprietary from both vendors. In that sense, AMD's using Intel's code, because they implemented their own x86-compatible CPU (and have done so since the 1980s).
reinformit wrote: 3rd party discs work Apple's doesn't. Not even the original discs that came with. the computer. Beyond pathetic.
Sounds like a failing optical drive, rather than a software problem. When one of my opticals started failing, it would read some discs without any issues, others wouldn't work ever, and a few would work if the phase of the moon was right. There's nothing an ISO9660 implementation can do if the underlying drive cannot supply bytes.
Does the disc work in other machines? If so, stop blaming software for failing hardware. Yes, failures suck, but unfortunately that's the reality of value engineering, and it affects all vendors in all fields. (there are cars from the 1970s that still function with stock parts. Will there be any 2010 model cars 40 years that function with stock parts? I doubt it.)
reinformit wrote: The PPC architecture was much more forgiving to people like myself. I can't divide by zero either.
There's no effective difference between the two -- they're both turing machines executing pre-defined instructions in the form of programs. There's no "be nice to the user" instruction on PPC that x86 lacks, nor a "fail gracefully" operation. Is there something more objective than "forgiving to people like myself" to measure this against? I'm going to guess it's a software failing more than anything to do with hardware. (On properly designed software, you cannot tell if you're on PPC or x86, because the experience is identical -- performance intensive things will have a difference, but most of the time people aren't doing intensive tasks).
reinformit wrote: The PPC still rules in the graphics department without a dedicated graphics card because It can chew gum and walk at the same time. Intel can't. Never could and never will.
The PC game market begs to differ. Even without hardware accelerators, DOOM, Descent, and Quake pioneered 2.5-3D environments on x86. 17 years ago. The current PC gaming industry runs on x86 + hardware acceleration, and it's apparently lucrative enough to keep going. Console platforms have favored ppc recently, but that's probably more to keep piracy, emulation, and homebrew at bay (xbox1 featured an x86 cpu, and was exploited extensively because of that) than for any actual performance benefit.
Photoshop benchmarks for PPC vs. x86 are interesting for a few reasons: first, Adobe didn't have an x86 version, so the 73% citation in that article is actually measuring x86 emulating a PPC, and still almost matching performance parity. That's impressive (emulation/cross-compiling on the fly is non-trivial), and with less ram to boot. Once photoshop (or the graphics package of your choice) was made native x86, ppc instantly became irrelevant in terms of cost and performance.
Regards SL generally, pretty positive all around. Some really tangible speed & operational improvements .
Regards QC SL - very interesting, I no longer consider the difference in the interface between the two much at all. The OpenCL & Mesh facilities have been a delight although you, I and others have found a need to fix some things for ourselves.
I'm not too favourite with QuickTimeX. It's good for what it looks intended for by and large. Just glad I can still keep QTPro for manipulation, encoding, decoding and other media engineering operations.
Disappointed.
Example:
-- CL is buggy and tends to over-crash
-- Lighting patch + Shadows is jerky and slow
-- QuickTime X is a joke
-- QC Mesh port not in public API
-- No Geometry shaders in the stock GLSL patch
-- No global variables
-- IB freaks out when binding a QCpatch that contains a GLSL shader
-- Interaction patch is messy when recalling settings
and so on.
The only good point is IOSurfaces.
I'm going to add a couple of things that bring me joy, that come to mind off the top of my head:
I enjoy the fact that I can publish out of an iterator.
I like that smooth works in an iterator now.
I like not having to think too much about the texturing of large 3D objects/scenes where many images/source textures would need to be manually handled otherwise.
I like some of the visual qualities and effect of mesh filters.
I enjoy the effect of the hidden option for multisampling.
I like that qtz's load plugins when iTunes runs them now.
As far as the OS goes, I don't find it to be "snappier", but it may be because of what I'm using as a barometer. Everything I'm describing is when using the same machine, and considering SL in aggregate vs. 10.5.8:
It takes more time for the my Desktop and Finder to load in SL and it does in Leopard.
When opening Safari, when I go to fill in text fields, it hesitates the first time, in SL. There are many other instances where SL feels "sluggish" in responding to user events.
Spaces seems to work less smoothly, and lags more on when you first log into a user account.
Finder results seem to generate more slowly for external HD's.
With QC Mesh, I like the things that it has brought to the table, but I don't think that rendering static DAE's is extremely useful by itself. I don't think that the mesh creator being broken is particularly great either, since it is somewhat fundamental. I don't enjoy that Preview has more control of dae's than QC. I also don't enjoy that there are no facilities for loading skinned mesh. I wish that certain things that seem fundamental were better documented, or worked (eg., construction of normals from arbitrary vertices), since not being able to generate normals means that things can't be lit. I do really like the idea of having an integrated geometry engine, and there are many benefits of the mesh system.
I don't particularly think about the SL interface too much, because I'm using Kinemecore, that cleans up some of the speed problems, but every so often I talk to someone who loads a really large composition with tons of noodles, and I get to hear about how QC can barely render the editor. I have a fun photo album of really wretched QC editor problems, from noodles with no patches, to noodles that chop in half, to giant areas of garbled glitchiness in inspectors, and feedback ghost noodle trails on the editor. Good stuff! However, I'm truly not complaining too much, because even with these issues, I think that QC is miles ahead of other node based environments, in the usability and look of the Editor. I do still use Leopard, and it seems easier to see non-active noodles for some reason (maybe this is placebo), and it's less straining on my eyes in general.
I like the way that the menu bar and controls fade away from Quicktime X. Whoever thought of that should get a big pat on the back. I'm not so sure about the way that the video transport can get moved around anywhere though. It is also a pain that there is no way to use something like "Grab" to take an image of just the Quicktime X screen without the video transport popping back up. The way that the Quicktime Pro options don't load into Quicktime X means that I use my old Quicktime in SL all of the time instead of Quicktime X.
In looking at other node based environments, I'm only reminded of QC's strengths, but I think that they are taken for granted, and that there has been an amazing lack of innovation. It's also really surprising that some stuff was released with the glaring bugs that they have. It's a gigantic time waster in that regard.
Forgot to mention crashes and graphical degradation.
I always had crashes, and expect them if I'm putting something together and do something stupid, or even that a system will have some bugs.... for instance, it's pretty darn trivial to pull some choice moves with FreeFrame and explode QC, or put a string that's too big somewhere, and crash stuff, or use external plugins that cause crashes, all in Leopard.
None of those ever did stuff like freeze my system, give me kernel panics (except ONE time), cause weird display flickers (by that, I mean "blackness" in a strobing fashion from the bottom to the top of the display) with system locked, give me spontaneous logouts, etc.
There is some stuff that is really cool though:
QC's explode macro feature is AWESOME. I love being able to pop stuff out of a macro like that. It's almost easy to overlook with all of the kinemecore transmutate macro, and publish/unpublish all features, but the explode macro is something I use all the time.
Interaction on the Viewer has, on a couple of occasions, saved me a ridiculous amount of time when getting stuff aligned in a pixel accurate way, in getting stuff in the general areas they should be in quickly, then tweaking the rest of the way manually. I do find much promise in the premise and would like to see new methods of controlling stuff while manipulating the Viewer area.
I really like the concept of an integrated geometry pipeline. It's cool that openCL filter kernels amount to how I think GLSL ought to work in QC (but doesn't), in many ways. Trying to keep it positive in tone, but it's irritating that the mesh creator is problematic, and also not a great that there are weird evaluation bugs with new patches that have been introduced. I'm at a loss to think of one new feature that hasn't introduced bugs in some ways, though they make work and have legitimate use within narrow parameters.
I have run into occasions where stuff runs faster in SL, and that is VERY cool.
Feedback being supported in CI, and extrusion in GLSL are really cool. I don't know how much that has to do with QC, but either way, it is major benefit, to me.
I like that the mesh renderer gives a way to render a structure of points without iteration, and texture them decently as well. I REALLY like that vertex info is exposed on 3D models, and also that I can make a model, get all of it's vertex info, and then place an object at every vertex. Having that raw vertex data is maybe my favorite aspect of QC4, aside from publishing out of iterators. However, I want the results of publishing out of an iterator to be 4x or more snappier! I want it to handle calculations on all of the vertices (and more) of a 3D object, without hesitation.
Biggest disappointment overall (if you ask me this minute) has been no skeletal animation. The idea that we have a collada engine and don't have that boggles my mind. I seriously expected there to be lurking functionality in that regard, and have been seriously saddened that there wasn't.
Actually, biggest disappointment is that there is no QC"mini" or QC full environment for iOS. It would be great to be able to make apps that play/generate media and provide some cool QC-esque interactive control methods. I can think of tons of stuff I could do without CI support and with only a limited subset of GLSL. I think the fact that this doesn't exist is hamstringing QC.
IOSurface is looking to be interesting indeed. I wish there was a way of leveraging more control between apps with an over-riding framework, so that it would be easy to have apps control the menus of other apps ( a big "whatever" to people that think that idea is ludicrous ).
If only it were on a PPC. Mac should change it's slogan to "it jest works"
This reminds me of people calling ProTools "alsihad".
To Apple's credit, continuing to maintain an architecture they 1) no longer sold and 2) were running out of working on-hand machines for testing on would produce the following fun side effects: 1) lower build quality (half the bug hunting time would be spent on the dead architecture) 2) larger binaries (more dead code for more customers) 3) fewer features (half the feature development time would be spent making sure stuff works on ppc, or skipping it because it had no equivalent on ppc)
might as well complain that m68k was ditched too. and 65C816. and 6502. man, those cheapskates...
You know, it occurs to me sometimes when I talk to very savvy people that some of QC's best new features in SL still aren't really known/thought about. I know that the stuff is "sort of" in the Read Me/Release Notes, but I know certain handy features have been overlooked by people that don't have the time to go finding them.
I've discussed "issues" I have with texture handling and QCMesh (ironically, thinking that it's too abstracted), but in talking to people:
I realize that many people don't know that the Collada/DAE loader loads in fully textured scenes in one shot! This means you can have a model that loads hundreds of textures, some that tile over parts of the model, other textures that cover a "sub-object", and it loads totally automatically. Not a challenge at all. This is really handy, and makes doing all kinds of previewing, and basic viewing and rendering of Collada instantaneous. Really awesome power.
The other thing - the shadow engine does_have_bugs. It_can_look_ugly. However, it can also really be usable. ( http://www.vimeo.com/6317773 ). I'm not sure that any shadow method could be accurate "work" in every given scenario. It doesn't inherently break anything when it's not on, so it's not as if it's a constant thorn in the side. It's really beneficial for some things, to me.
The ability to import image structures by extracting all images and embed them in the composition in SL is SUPERB. It's essentially a movie embedder + tons of other useful functionality by adding that one feature.
...and while I prefer the Leopard QC interface, I think that the glossy/dark look is very modern, and that it isn't too bad. I think overall, it's a better choice to move forward than it would have been to stick with the 10.5 design. Using other node editors shows that QC is at the head of the pack as far as having a great GUI (for me).
Leopard has this feature on the Image importer patch settings if that's the patch you're referring to. I think it was you who brought that to my attention with your SL embed a movie post ;)
Mind you, I've spent hours and hours trying to isolate a Rendering bug that only happens with multipage PDFs made in AI. It occurs randomly (as in might not happen for >100 stop starts but then can stay for another 100 stop starts of comp). When the Image Importer patch set to 'extract all' or Kineme's PDF patch (which I prefer b/c of flexible 'raster' dimensions) with a multipage PDF are connected to a sprite or billboard is when I see it.
The bug usually manifests as 'white out' of the sprite/bb but also can give a b&w RAM noise image. It can also bug out across compositions… quite an eye opener. I'l document it one of these days, I've been collecting screen saves etc and have tried every version of PDF known to the print world… (nearly) and they all get it. Need to try a multipage made in another App like Preview maybe.
While I do agree about supporting two architectures it is the one they've chosen that IMO is the problem. Something was lost while porting from Intel to PPC and then back again and the 32 bit MacIntel never should have been introduced. I have been doing graphics on a Mac since the 80's and have never experienced such a long list of issues save OS 7.
Once upon a time things really did "just work" and now I get excited when I can read a disc on the same machine that it was created on or create a video whose audio track doesn't wander all over the place. Even browsing through the finder seems too intense for the processors causing the beach-ball to spin.
My "complaint" is that, other than the price, there is nothing about the Mac that sets it apart from the Dells or HPs anymore.
Make sure you are totally flattening your pdf's.
That feature is in Leopard too? No kidding. That's great.
I understand the "premise" of using the Kineme PDF, but if you're ultimately importing a structure of image, and not vector graphics. I don't find that aspect of that patch to be useful, I would rather it come out at the default resolution. Also, you can't load the whole structure at a time, and...it's a plugin. The one thing that it has an advantage on is that you can load file name at any time... I think the stock image importer handles pdf's this way though. The patch is somewhat of a headscratcher for me.
They never went from Intel to PPC. The only effective change is endianess, which can be brutal for programmers who aren't careful. Oh, and altivec optimizations were rendered useless, though industrious programmers can use SSE to replace most of that (though not all: fmac is still troublesome).
Disc formats have been "solved" for essentially forever - HFS+ has provisions for both endianesses, and has always had drivers for both. If there's been a problem with that, it's due to 3rd party tools. (I'm no HFS+ apologist, but messing something like that up simply wouldn't fly). FAT is always little endian, and ISO9660 is always what the red book says. Any other FS is 3rd party, or NTFS (which means OS X didn't write it in the first place, so still 3rd party).
Audio wandering has to do with clocking and synchronization -- crappy encoders, crappy decoders, and crappy players can contribute to those problems. Thankfully, neither PPC nor X86 care, and both will happily run crappy software. The transition had nothing to do with that. (I'm going to have to plead the fifth on whether not not QT qualifies as crappy)
Are you seriously suggesting that PPC set Mac OS X apart? If so, how? Because it was so fast/powerful? (hint: it's not - x86 runs circles around ppc in terms of 1) core count 2) memory bandwidth 3) and vendor support). X86 provides some convenient benefits: ability to run optimized x86 code (ports from other platforms), ability to tap into the massive commodity developer base that has worked on x86 (like myself), no supply shortages (back in 2004, G5 shortages were problematic for actual shipping products -- IBM has enough other stuff going on that missing a shipment is a don't-care. For companies that depend on said shipment, it can be fatal.) Perhaps you mean PPC was RISC, while x86 is icky CISC? That battle was fought decades ago, and the winner was "both" -- CISC slaughters RISC when it comes to code density, but RISC has huge wins in decoder logic and compiler writing. Intel retrofitted in RISC core+pipelining into x86 with the 80486 (single-stream pipeline - 1989), pentium (dual pipeline - 1993), and pentium pro (risc core + fuser - 1995). Compiler complexity ended up being a don't-care in this situation (it essentially hobbled Itanium though).
I'm not a Mac apologist -- I fully advocate using the right tool for the job, and OS X isn't always that tool. But I'm really curious to know why you think the CPU had anything to do with the value of purchasing a mac then or now (other than marketing). The market says otherwise.
Chiming in...
The NeXT operating system worked on intel since '93. When it was bought by Apple, Apple bought an Intel and a PPC architecture (+) that both worked. It wasn't "oh crap, we have to write an Intel version from scratch in one release cycle".
I know that the "value" of Macintosh is the pairing of software with hardware, and that it's supposed to be vetted so that the combinations "just work", but I really don't think that the grass was greener when stuff was PPC.
Yep -- and next stuff worked on both simultaneously, so it wasn't like there was a migration from intel-only features to ppc, and then back. :)
One other cool quirk people don't talk about: intel is in the business of making CPUs. if they don't work, intel takes a ton of heat since it's all they do (cf. FDiv bug, F00F coma bug, others). As such, they're quite rigorous when it comes to testing. PPC (and to a much larger extent, Motorola) cpus had way more bugs that needed software workarounds (for stuff like integer division by 256, 32 bit wraparounds on 64bit additions/subtractions, and other quirks). good times.
Then Apple is selling crappy software and crappy hardware.
I use 3 3rd party programs 2 of which were under $20.00 ( one being QuartzCrystal) and one was over $3400. All of them work better than Apple's own apps. QT, FCE,FCP/S, iTunes and Safari are all crappy according to you.
You hit the nail on the head and it's called ISO 8601. A multi billion dollar fraud is what you are saying it was. I agree. Maybe Apple should have put more of an emphasize on it and instead of considering wether or not I (HI) could understand it worried more about wether or not their own software can understand it. They did address it in a QT update but didn't quite get it. The Mac OS broke after OSX.3.7 and QT6. If I weren't retired and relied on a computer on a daily basis I would be using OSX3.7 and QT6 or would have "switched", like so many others, to Windows.
Seems others on this thread have the same issues and all have to do with the ability, or more appropriately the inability, of the processor to keep up with simple mundane tasks (maybe Apple should have gone with AMD as Intel..., correct me If I'm mistaken but both Intel and NVIDIA use AMD's SW or a derivative thereof). Even Apple's switch to NVIDIA's GCs proved to be a failure. Apple's unreliability was evident in OSX.4 even in the PPC (with how many architectures supported with 10.4.4?). A monumental attempt but certainly not an achievement. Safari Beta was mind blowing Safari 5 just blows. Apple updates used to be full of new features now they are full of "fixes". JB Weld. It appears to be fixed at first glance but it really isn't.
I am looking to replace my recently deceased 667 so I can do some simple things without the need for all the hokey pokey. I love workarounds it's the stonewalls that get to me. Maybe Apple should have used the version of ISO 9660 that they've used in the past and at least maybe their machines could read the discs it creates with their own software. I used to partition my HDDs for third party software compatibility now I do it for Apple's own software and hardware. Pretty pathetic. Nothing on the machine I am typing on is original although all replaced and OEM by Apple. 3rd party discs work Apple's doesn't. Not even the original discs that came with. the computer. Beyond pathetic. They replaced the whole machine twice and every part on it till the warranty expired. GIGO
I won't pretend to have even one percent of the knowledge of computer programming that you have as if I did I would/could have created my own programs like Crystal. Kudos to you. The PPC architecture was much more forgiving to people like myself. I can't divide by zero either. If you could include .pln and .gsm (not the audio file) in kineme 3D I'd buy it in a nanosecond but I'm bot so sure Apple understands that anymore either.
All the excuses for no G5 Powerbook and bla, bla, bla, were just the proverbial SUTA because I and many others have experienced every reason Apple gave for their non existence except for the real one. All three players in the game (AIM) were bagged for copyright infringement and chose not to make a deal. The PPC still rules in the graphics department without a dedicated graphics card because It can chew gum and walk at the same time. Intel can't. Never could and never will. The only reason I ever used an Apple to begin with is that in an office full of IBM's/PCs they couldn't do what the Apple could. I should be able to replicate some of those things but Apple is no longer capable without 3rd party software.
Something set Apple apart from the rest and it is becoming more and more obvious that it wasn't it's OS.
I'd rather words weren't put in my mouth. My only usage of crappy was for video encoders/decoders that don't properly synchronize audio with video -- no other subjective measures are used for that qualification in this context. If the encoder is bad, then there's simply nothing the decoder can do to keep it synced. That's not a failing of the player/decoder. Is a CD player crappy because it can't play a microwaved disc? Whether iTunes and Safari are crappy depends heavily on details outside of their control.
Nope, I said ISO9660 and I meant it -- in context we were discussing file systems, of which ISO9660 is used to describe how files are laid out on CDs and DVDs. This hasn't changed in an enormously long time, with several conforming implementations for all platforms. I also never called anything a fraud. ISO 8601 deals with date encodings, which doesn't matter for filesystems (they all use binary encodings because they're more compact). Coincidentally, standards aren't perfect (cf. http://unicode.org/cldr/trac/ticket/2845 -- I filed that bug against the LDML spec, which deals with date and time encodings having an ambiguous/erroneous representation), so implementations will sometimes be subtly different. The oft-cited OBJ file format for 3D is one such example: there's no set standard, and so many permutations of what actually entails a valid OBJ that writing a fully functional OBJ parser requires heroic amounts of effort.
Again, this isn't a shortcoming of the CPU, but the software. You wouldn't believe the number of stupid mistakes I've committed, and the same goes for other engineers. All the performance complaints on kineme.net typically revolve around QC being slow (which is a function of hideously over-object-oriented design, and disappointingly out of date OpenGL design), and OpenCL being slow (which is a technology that is largely irrelevant in the commercial sector -- QC puts a lousy face on it, but it's a technology that isn't well-suited for the processing QC provides anyway).
The current GPUs, even with bugs, are wildly more powerful than previous generations. Whether or not software adequately reflects that isn't a shortcoming of AMD, Intel, nor NVidia.
Can you cite the failure statement? Sounds more like frustration talking (which I share when dealing with GPU/driver bugs), rather than a real event.
Regarding everyone using AMD software, that doesn't mean anything. Intel and AMD both publish reams of source code. So does Apple, Nvidia, Microsoft, and countless other technology companies. AMD has been more affordable, CPU-wise, but with lower performance (since Intel's Core architecture at least -- prior to that, benchmarks tilted towards AMD for several years) and "weirder" standards (SSE is a mess on AMD, 3DNow! is irrelevant). Intel used AMD's 64 bit extensions (and pays a license for that I believe?), but that only covers how instructions are encoded -- how they're decoded, scheduled, pipelined, cached, and executed are proprietary from both vendors. In that sense, AMD's using Intel's code, because they implemented their own x86-compatible CPU (and have done so since the 1980s).
Sounds like a failing optical drive, rather than a software problem. When one of my opticals started failing, it would read some discs without any issues, others wouldn't work ever, and a few would work if the phase of the moon was right. There's nothing an ISO9660 implementation can do if the underlying drive cannot supply bytes.
Does the disc work in other machines? If so, stop blaming software for failing hardware. Yes, failures suck, but unfortunately that's the reality of value engineering, and it affects all vendors in all fields. (there are cars from the 1970s that still function with stock parts. Will there be any 2010 model cars 40 years that function with stock parts? I doubt it.)
There's no effective difference between the two -- they're both turing machines executing pre-defined instructions in the form of programs. There's no "be nice to the user" instruction on PPC that x86 lacks, nor a "fail gracefully" operation. Is there something more objective than "forgiving to people like myself" to measure this against? I'm going to guess it's a software failing more than anything to do with hardware. (On properly designed software, you cannot tell if you're on PPC or x86, because the experience is identical -- performance intensive things will have a difference, but most of the time people aren't doing intensive tasks).
The PC game market begs to differ. Even without hardware accelerators, DOOM, Descent, and Quake pioneered 2.5-3D environments on x86. 17 years ago. The current PC gaming industry runs on x86 + hardware acceleration, and it's apparently lucrative enough to keep going. Console platforms have favored ppc recently, but that's probably more to keep piracy, emulation, and homebrew at bay (xbox1 featured an x86 cpu, and was exploited extensively because of that) than for any actual performance benefit.
Photoshop benchmarks for PPC vs. x86 are interesting for a few reasons: first, Adobe didn't have an x86 version, so the 73% citation in that article is actually measuring x86 emulating a PPC, and still almost matching performance parity. That's impressive (emulation/cross-compiling on the fly is non-trivial), and with less ram to boot. Once photoshop (or the graphics package of your choice) was made native x86, ppc instantly became irrelevant in terms of cost and performance.
One cool feature in SL that isn't mentioned much: Smart Groups/Groups. Control+Left Click in the Patch Library, and see the options.