Shake, etc. and the 970--something is wrong.

Posted:
in Future Apple Hardware edited January 2014
I'll make this brief...



We know that FCP, DVDSP, and Shake hve been updated. The update cycle for these products is a year or so. These are Pro apps. The 970 is a Pro chip. The 970 is supposed to be here in July, and the apps won't be updated for another year. Not good. \
«13

Comments

  • Reply 1 of 42
    hmurchisonhmurchison Posts: 12,425member
    Quote:

    Originally posted by Placebo

    I'll make this brief...



    We know that FCP, DVDSP, and Shake hve been updated. The update cycle for these products is a year or so. These are Pro apps. The 970 is a Pro chip. The 970 is supposed to be here in July, and the apps won't be updated for another year. Not good. \




    Congrats..this is by FAR the stupidest post of the day
  • Reply 2 of 42
    hmurchisonhmurchison Posts: 12,425member
    Ok man...that was a little harsh.



    There really is no problem at all here. While the upgrade cycle may be a Year for MAJOR updates the apps will continue to see minor updates. Any tweaking necessary to run on a 970 would be something akin to FCP 3 moving to 3.04.



    Apple does continually update their products to fix minor glitches.
  • Reply 3 of 42
    macsrgood4umacsrgood4u Posts: 3,007member
    Why start another thread on this subject anyway. The stupidest post is the one my friend ran into the other day while jogging.
  • Reply 4 of 42
    gargar Posts: 1,201member
    Quote:

    Originally posted by hmurchison

    Congrats..this is by FAR the stupidest post of the day



    well actually he has a point there, the boys at weta where screaming for a 64bit shake. i think updating a application from 32bit to 64bit is worth a real update... oh no, your right sorry, they can name it shake 3.5 v64 and indeed it will take some time to do so. since apple bought shake after the november 2001 motorola G5 debacle so by now apple should have been toying around with 64bit osx for a while...

    so... well... sorry, i go to bed now, stupid white beer



    well at least it is good promotion for the ppc970 chip that it will run shake 3.0 faster than the current G4 although it is 64bit.



    bye
  • Reply 5 of 42
    hmurchisonhmurchison Posts: 12,425member
    Quote:

    well actually he has a point there, the boys at weta where screaming for a 64bit shake. i think updating a application from 32bit to 64bit is worth a real update... oh no, your right sorry, they can name it shake 3.5 v64 and indeed it will take some time to do so. since apple bought shake after the november 2001 motorola G5 debacle so by now apple should have been toying around with 64bit osx for a while...

    so... well... sorry, i go to bed now, stupid white beer



    well at least it is good promotion for the ppc970 chip that it will run shake 3.0 faster than the current G4 although it is 64bit.



    Yeah I think what you would most likely see is Apple ensuring things work fine at 32bits and then looking to tweak for 64bits when the time is right. Shake would be the first candidate..DVDSP 2.0 doesn't need to run at 64bits really IMO. FCP might do well at 64. I didn't mean to sound like an ass but I don't think our friend Placebo has anything to worry about.



    If anything watch the movement of the GCC compiler and how it's optimized for 64bit and other features. That might tell you a bit more about Apples plans. At any rate get the apps here asap and then ship those 970 systems and then update the apps when necessary.
  • Reply 6 of 42
    snoopysnoopy Posts: 1,901member
    Who is to say it isn't 64-bit ready right now? New 64-bit applications will be made to install and run on a 32 or 64 bit Mac. The code could be in there right now, no? Or is there something I don't know that makes this unlikely or impossible?
  • Reply 7 of 42
    sc_marktsc_markt Posts: 1,402member
    I noticed that one of the apps won't be available until August. Don't know if it means anything.
  • Reply 8 of 42
    programmerprogrammer Posts: 3,458member
    Quote:

    Originally posted by snoopy

    Who is to say it isn't 64-bit ready right now? New 64-bit applications will be made to install and run on a 32 or 64 bit Mac. The code could be in there right now, no? Or is there something I don't know that makes this unlikely or impossible?



    Considering that there are no 64-bit APIs or hardware to test against yet, this is unlikely. And I'm sure some nosy busy-body would have noticed by now if there was another executable stuffed into the application bundle.



    Regular release schedules generally reflect major new feature releases -- updates for new hardware or ports are often introduced between these major releases. A 64-bit version that is feature-identical to the existing software could be released without distrupting their development schedule. This presumes the existence of a 64-bit OS, of course.
  • Reply 9 of 42
    danmacmandanmacman Posts: 773member
    From Apple:



    "DVD Studio Pro 2 is expected to be available in August through the Apple Store® (store.apple.com), Apple's retail stores and Apple Authorized Resellers for a suggested retail price of $499 (US)."



    Bring on the 970
  • Reply 10 of 42
    brussellbrussell Posts: 9,812member
    And neither Shake nor FCP 4 will be available until June.
  • Reply 11 of 42
    cliveclive Posts: 720member
    I really think you people are dreaming if you believe that Apple is going to introduce a 64-bit chip, a 64-bit system and a bundle of 64-bit apps simultaneously - just isn't going to happen.



    Take a lead from any other new technology integration - AltiVec for example, or even PPC - it took a long time for those technologies to be fully integrated. Apple doesn't have the resources to do what you wish it could.
  • Reply 12 of 42
    keyboardf12keyboardf12 Posts: 1,379member
    if the subset of features that could truly be enhanced by a 64bit conversion is a manageable number then why not? its not like apple hasn't had test machines for at least 6months....and plans to go 64bit before even then...
  • Reply 13 of 42
    cliveclive Posts: 720member
    Quote:

    Originally posted by keyboardf12

    if...



    Don't ask questions and then try to build concrete arguments based on them - it's simple, you don't know.



    Guess what, neither do I. But history is a good teacheer, just look back at how things have been rolled out in the past.



    Take a choice, be a realist (970s early in 2004, 64-bit apps and system tweaks over thee following two years), or dream on.





    -- Clive
  • Reply 14 of 42
    myahmacmyahmac Posts: 222member
    yeah but it owuld be sweet if they had the resources to do it. hey maybe they do bbut they don't.



    for example when they bought shake, noway they got rid of everyone. y not let them continue where they are going for now and give them exclusive acces to os 64. then the resources need for developing yet another app and streamlining it for se in a 64 bit system are not wasted.



    personaly i think it would be sweet if they could do it. cuz i know that weta was looking to buy a whole new computer setup just to do the final battle in the return of the king. i saw in a pr that the current setup would not be able to handle the amount or complexity of the battle. it suposed to be 5x bigger than the battle for helm's deep.
  • Reply 15 of 42
    keyboardf12keyboardf12 Posts: 1,379member
    How about this:



    970 announce late june

    machines ship late aug

    shake 64bit ships late aug

    FCP4 & DVD2 ship with 64bit features nov...



    and what part of "if" is so impossible???



    Is there a possiblity what i mentioned in my previous post _could_ be true??



    I bet most would say, it _could_ be...



    so if it _could_ be true what's wrong with me saying _if_



    ??
  • Reply 16 of 42
    kickahakickaha Posts: 8,760member
    Well actually, work logs on Darwin and gcc have shown excellent and continual improvements to 64-bit clean rs6000 code (read as: 970 codebase) for about a year now.



    If gcc is ready to be spitting out 64-bit executables, and the code has been tweaked for 64-bit cleanliness (and let's face it, most moderately decent code out there is already ready to go - it takes some pretty boneheaded assumption use to screw it up anymore in most of the app's functionality), then moving to full 970 64-bit sweetness is a recompile away.



    I fully expect to see a 970-compliant gcc shipped with the 10.3 developer tools. It may not be perfect, but I'll bet you anything it's in there, along with a 970 emulator, like they shipped the AltiVec emulator before the G4 was available.



    Apple has set themselves up for a slick, clean and smooth transition from 32- to 64-bit, unlike Intel/M$. Those poor bastards are talking about a three year transition, if everything goes well. Since the 970 will run 32-bit code natively, without emulation, you lose nothing by running 32-bit apps. You gain plenty from a code tweaking and recompile for apps that can take advantage of 64-bit computing. Best of both worlds. Again.
  • Reply 17 of 42
    airslufairsluf Posts: 1,861member
  • Reply 18 of 42
    programmerprogrammer Posts: 3,458member
    Quote:

    Originally posted by Kickaha

    (and let's face it, most moderately decent code out there is already ready to go - it takes some pretty boneheaded assumption use to screw it up anymore in most of the app's functionality)



    This just isn't true -- code which is performance optimized to minimize its memory footprint or use the vector unit, or which relies on binary data loaded from disk in a fixed format can easily contain assumptions about pointer size, and these are entirely reasonable assumptions. This doesn't preclude boneheaded assumptions in some cases, but not all such assumptions are unwarranted.
  • Reply 19 of 42
    sc_marktsc_markt Posts: 1,402member
    Quote:

    Originally posted by BRussell

    And neither Shake nor FCP 4 will be available until June.



    I wonder if they'll be available after WWDC, which is Jun 23-27?
  • Reply 20 of 42
    kickahakickaha Posts: 8,760member
    Quote:

    Originally posted by Programmer

    This just isn't true -- code which is performance optimized to minimize its memory footprint or use the vector unit, or which relies on binary data loaded from disk in a fixed format can easily contain assumptions about pointer size, and these are entirely reasonable assumptions. This doesn't preclude boneheaded assumptions in some cases, but not all such assumptions are unwarranted.



    Note that I specifically stated "most of the app's functionality". Most.



    The bits you're talking about are I/O or specific optimizations that one would expect to be small, minimized, and site specific, if the developer has done even a decent job of developing the system. In such cases those details aren't assumptions, they're requirements. Big difference.



    For most apps, this will hold, but of course it's always possible to find a counterexample... which is why I specifically said 'most'.
Sign In or Register to comment.