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.

Best, Joshua

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.

Karl

> 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?

Karl