karloie@gmail.com

intrinsic-effects-as-maxjitter-objects

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, 

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.

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

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

> The problem is that Jitter matrices by default are ARGB on both  
> platforms, and hence we have to swap on Intel.

Intrinsic Effects as Max/Jitter objects?