Intrinsic Effects as Max/Jitter objects?

    Apr 06 2006 | 1:04 pm

    • Apr 06 2006 | 5:33 pm
      Hi Karl,
      These effects look great. I can't speak for what demand would be for
      these effects as native jitter objects rather than as freeframe
      effects, since most of the messaging functionality can be accomplished
      with subpatchers wrapping the parameters of the said freeframe effects.
      However, three possibilities if you convert to a jitter object would
      be: a) eliminate the need for byteswap on input/output on little endian
      hardware and thus get a performance boost, b) that you could also
      support slower, but higher quality floating point input/output for
      non-realtime processing with your effects, c) support uyvy mode for
      processing chroma reduced streams. If you have any technical questions,
      feel free to let us know.
    • Apr 06 2006 | 6:21 pm
    • Apr 07 2006 | 10:46 am
      Quote: jkc wrote on Thu, 06 April 2006 19:33
      > be: a) eliminate the need for byteswap on input/output on little endian
      > hardware and thus get a performance boost
      I have looked into the freeframe specs about endianess and FreeFrame seems to support no flag to communicate from the host the endianess of the input/output data. Correct me if i'm wrong here.
      On windows .dll is the prefered FreeFrame effect way of distribution and .dll's are always the same endianess and can expect data in/out to be of Win32 endianess.
      On PPC mac dynamic library in a .frf folder is prefered by programs like Isadora, so all effects compiled to this binary format can expect ppc endianess.
      On Intel Mac there have yet to bee seen what kind of distribution binary becomes popular, .so files? Anyway all these files will have the same endianess if Intel Mac.
      So since all FreeFrame effects have to be compiled to each target specifcally there is no fear of endianess mixup if the effect is properly coded.
      If jit.freeframe recodes the byteorder i think this is unecessary because the endianess and the ARGB/BGRA format will be target specific for each platform and really handled in the freeframe effect.
    • Apr 07 2006 | 4:56 pm
      > The problem is that Jitter matrices by default are ARGB on both
      > platforms, and hence we have to swap on Intel.
      Ah, i see. So for jitter we should compile for ARGB on both platforms?