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