freeframe for max/msp/jitter , why?

[MJ]

What would be the advantage of having freeframe in max?
I mean when you program in max you can make it all youre self in jitter so why freeframe

[sleepytom]

what's the point of having max / jitter when there is C++

what's the point of C++ when there is C

what's the point in C when there is assembler

most people who "program" in max / jitter aren't very good coders - they will benefit enormously from being able to intergrate freeframe plugins into there max patches

take grid or neromixer for example - these apps will never benefit from freeframe plugins until there is a simple max external that adds freeframe plugin support.

plugin support is an essential extension of max - it already supports VST plugins so freeframe is a logical next step

why don't you want to see freeframe support in max?

[KillingFrenzy]

Ok,
Program "patchbox" inside Jitter.

In a more general sense, a hard-coded effect can use a lot less resources than a jitter patch that does the same thing.
Having spent a tremendous amount of time making a few nice effects/filters in Jitter, I find that they suck up resources I'd rather spend on general flow.

Considering Jitter only has about 20 filters to play with, adding 80 new ones should liven up the possibilities. Just think of these new effects as "externals" and maybe you'd understand the concept.

[charlielangridge]

Originally posted by sleepytom
what's the point in C when there is assembler

Cos assembler is an arse to work with ;)

[sleepytom]

err i kind of meant that as a rhetorical question

[dlublin]

There is a HUGE difference between programming in Max and programming in C or C++, and I'm not just talking about C & C++ being lower level or more efficient or any of that. As far as programming languages go, they are very very different. Max/MSP is object orientated and in many ways far more powerful than C can ever be. When you are making a Max patch, you are stringing together pieces of powerful C code. There is a reason why someone like David Rokeby who makes SoftVNS uses Max instead of just writing his own applications in C (I know because we asked him). A good Max programmer is just as careful about order of operations, commenting code, and efficiency of their code as a good C programmer. It's very easy for a patch to get out of hand in Max, like Killing Frenzy points out, when you have to string together several objects to do a single operation, if you aren't very careful it can be very inefficient. If you know C, it's pretty easy to make your own objects for Max for combining several operations into one. There are a few really great things about Max 4.5 - like js and jsui. Javascript is a wonderful language that is both easy to use and for certain types of operations very fast.. and with Max 4.5 you can seamless integrate javascript and C to do incredibly powerful things. The actual processing objects in Max tend to be *very* well written, most Max patches get bogged down when creating the logic around these processing objects. If you were you look at the code for GP, you'd see that the program is a bunch of processing objects that are dynamically being controlled and re-routed by a few javascripts and several custom externals. We choose to stay in Max, not because we aren't knowledgeable programmers, but because Max is a wonderful programming environment that only gets better as you learn more.

It's hard to think about FreeFrame pluggins simply as new externals - maybe a similar "concept", but they aren't. I don't know the details of how the FF objects will work, but chances are it'll be some sort of a wrapper that converts Jitter matrices to data that can be processed by the FF pluggin, and then it has to convert the data back to a Jitter matrix on the way out. This adds two steps to the processing. Now, if the person making the FF took the time to actually make their pluggin into a Max/MSP external (which wouldn't be too hard if you already figured out how to compile a FF pluggin), that would be a different story.

Do I think having the FF wrapper as a standard Max object is good? Yes, like Tom said, it's going to let a lot of artists try out a lot of filters / effects that they would not normally have access to. But as far as putting FF in GRID, if it was something we were really really really excited about, we would have figured out a way to do it earlier.. and if we couldn't, we would have just hired one of the many professional C programmers that we know to do it for us.. We'd rather go through and re-code every FF module from scratch so that we knew it was 100% optimized to work in our software. With that said, I've been wrong about things before, so the case is still out until C74 releases the wrapper object.

- DL

[sleepytom]

sure its possible to write bad / slow code in any language having said that all the max apps that i've seen have seemed slower than there non max competitors..

anyroadup the main advantage of freeframe has to be the 150+ effects that are ready to load up - even if you can write them all yourself you'd have to agree that from an end users point of view its nice to be able to load 3rd party plugins. these plugins keep being developed and whilst some of them might be a bit slow this is clearly down to poor programing by the plugin developer, end users can choose wether to use an effect or not based on its style and perfomance

[syzygy]

Originally posted by dlublin
We'd rather go through and re-code every FF module from scratch so that we knew it was 100% optimized to work in our software. With that said, I've been wrong about things before, so the case is still out until C74 releases the wrapper object.

- DL

If you stick with that approach then I think you will end up really holding your users back.

Obviously I am speaking as a freeframe developer here, but it just seems obvious to me that a live video application not supporting the most widely used live video plugin format is a bad thing for users of that application.

How many successful music packages do you know that refuse to support VST plugins because they prefer to write their own versions that are optimised for their software?

If you are a completely badass programmer, you might be able to reimplement, test, debug and support 'native' versions of all of the rapidly growing list of freeframe plugins but I certainly don't know anyone who could do it easily enough for it to be worthwhile.

Why not just support freeframe and give your users access to all of the effects? That way, you can spend your time working on your software rather than reimplementing other peoples ideas.

As for implementing equivilents of freeframe effects directly in MAX/MSP, give it a go and see how efficient your versions are. For my experience of MAX/MSP, I'd guess the MAX/MSP version will be significantly more processor hungry for an effect of any complexity (assuming the freeframe programmer is any good and has put some effort into optimisation)

The wrapper is unlikely to add much inefficiency. MAX/MAS (AFAIK) represents a matrix of video pixels as an array in which each element consists of 4 chars. Freeframe does the same. The difference is in the ordering of the components - MAX/MSP uses ARGB whereas freeframe uses RGBA. It will not be a huge processor hog to reorder the components.


Dan.

[DrEskaton]

I think the issue for the Vidvox guys is that GRID and VDMX process internally in YUV while freeframe is RGB based, meaning a YUV-RGB-YUV extra step for any freeframe plugins in GRID or VDMX.

right?

[dlublin]

Dr E is right, VDMX and GRID are using SoftVNS which passes video around as YUV streams, not ARGB. It's about half as much data. We're not trying to limit people's creativity, but our priorities when writing an application are: stability, frame rate, image quality. Everything else is secondary. So until actually trying out it our software, we're not going to commit to a standard that could potentially really slow down the frame rate.

Personally I've just found that Jitter is already too slow to do any FX processing unless it's being done on a GL level, so the thought of converting our very fast YUV stream to ARGB, then converting to RGBA, processing an FX in RGBA (which will be about twice as much processing as doing the same processing in YUV because it is literally twice as much data) .. then back to ARGB, then back to YUV.

I totally agree that a FreeFrame pluggin would be more efficient remaking them with Jitter objects.. and maybe the bridge objects will be trivial .. so it's great that people who use Max/MSP/Jitter will have access to all those FX. Unfortunately going from YUV to ARGB is not a trivial conversion.

With that said, I've heard *amazing* things about the next version of Jitter, at which time all my reservations about Jitter are likely to change. But the parts of the next version of Jitter that really excite me are the prospects of YUV video streams and Pixel Shaders for doing FX on the GPU..

- DL

[sleepytom]

what format yuv are you processing in? 4:2:2?

[KillingFrenzy]

So,

SoftVNS is only available for MAC
Most Freeframe effects are only PC

90% of the people who will use freeframe support will be PC users, just dealing with Jitte, since none of the heavy hitter externals like SoftVNS or the AUVI objects are available for PC. Tthe freeframe objects will add a nice new resource for these folks.
Whether or not they're comparitively fast to some other method doesn't really matter, since PC users have already chosen to use the slowest VJ app around, with the understanding that they'll have full control of their application. Just turn on DSP and run a single Quicktime object, and you're slower than most PC apps.

[VJamm]

Well I'm hoping that FreeFrame for max will open things up in mac FreeFrame land too. I guess we'll have to see whether the new FF support will interface with SoftVNS, and how fast the conversion is.

Hey look - something has occured to me - are you using 4:2:2 quicktimes? It seems likely that something is already doing an RGB -> 4:2:2 conversion somewhere in your grafix chain a lot of the time - maybe within QT as you are asking it to serve you up 4:2:2 . If that's the case you could run freeframe on the RGB before doing the conversion to 4:2:2

There is also 16 bit RGB freeframe if you want to run at a lower datarate - some plugins don't support this though as programming is more difficult at 16 bit but I think all of petes plugins for the mac do


what format yuv are you processing in? 4:2:2?

I seem to remember it is 4:2:2 here tom

Most Freeframe effects are only PC

That's because most hosts are PC. Lots of the main plugins developers are keen to product mac versions, and host support is developing fast now with max and arkaos coming on board.

Mark Coniglio has ported the FreeFrame SDK to mac which should help:

http://www.troikatronix.com/files/ffsdk-xcode.sitx

Is anyone from SoftVNS in contact with the FreeFrame project?

BTW: YUV support is top of the list for the next version of FreeFrame.

Russell

[dlublin]

SoftVNS uses yuv 4:2:2, I personally use SheerVideo, which has both rgb and yuv options, so I of course go for the yuv so that there is no conversion from rgb to yuv. We generally recommend to our users to use uncompressed yuv for the same reason. Again, my main concern with rgb processing is that it is too slow, so even if the user was using an rgb format (like photojpeg), the conversion needs to take place before any processing happens. Processing at 16-bit doesn't sound too appealing because of the quality loss and to look at only the Mac pluggins that support 16-bit.. narrows the list of pluggins quite a bit.

Sounds like everyone is jumping on the yuv wagon, I hear the next version of Jitter will also support yuv 4:2:2 as well. I'd be very excited to try out the yuv version of FF, sounds promising!

I'm not sure if anyone at SoftVNS has been in touch with FF.. VNS is really just one guy, David Rokeby, and I doubt he'd be too interested - he's an installation artist, based off the works of his that I've seen, I'm not sure how excited he'd be about FreeFrame, but you never know.

- DL

[jaw]

hmm, does openGL support loading yuv or do you have to make a final conversion before uploading to texture?

[DrEskaton]

Originally posted by dlublin
SoftVNS uses yuv 4:2:2, We generally recommend to our users to use uncompressed yuv for the same reason. Again, my main concern with rgb processing is that it is too slow,

I kind of think I have to disagree with your philosophy here dlublin.

YUV may be faster for raw cpu processing but if you want to use pixelshader filters processed on the GPU aren't they all done in RGB colour space?

You may buy yourself some speed up on raw cpu power but you are cutting yourself out of the next generation.

Future VJ apps will be pixelshader and GPU accelerated for all effects and this gives a many times faster speed up than the benefit of going YUV over RGB.

I would rather have the benefits of access to freeframe effects + GPU processing in a VJ tool and take the slight performance hit of RGB over YUV.

[sleepytom]

also bear in mind that 32bit rgb (and even 24 bit) is much higher quality than 4:2:2 yuv

[petewarden]

Apple has their own extension to OpenGL, to allow YUV422 bitmap data to be uploaded directly to textures.

All further GPU processing is done in RGBA of course, but it's definitely possible to pass the footage to the card without doing a conversion.

Pete

[DrEskaton]

pete, ok sure but that leaves you with going it alone largely.

Even if the freeframe spec gets YUV plugin support I imagine most freeframe plugins will not bother to support YUV clips.

I imagine most CoreVideo filters will also be written with RGB clips in mind.

Going YUV means largely cutting yourself out of the third party plugin market, freeframe and corevideo and only gives you a minor speed gain.

[sleepytom]

well we will have to wait and see what corevideo brings (omg i've only just got the "core" pun - god i'm sloow sometimes)

i'm willing to bet money that it blows all the nonsense about max/msp out of the water though - if they do it properly then we should be seeing 32bit RGB flying round the system loads faster than what you can achieve with max currently. (and without having to resort to cheap tricks such as 4:2:2 yuv to be able to get to acceptable speed)

finally we might start to see applications on the mac which match the performance of the best windows apps.

<rumour>
aren't apple getting Pete to make us a VJ app now anyway? It would seem logical now that motion is launched.
come on Pete spill the beans :)

ps need any beta testers??
</rumour>

[syzygy]

Watch out, Apple sue people for spreading rumours about their products nowerdays ;)


At least we'd find out whether there is a VJ app in the works then I guess...

Let us know if you get any terribly well designed legal threats Tom ;)

Dan.

[petewarden]

> pete, ok sure but that leaves you with going it
> alone largely.

The significance of the YUV support in textures on OS X is mostly that you get the conversion from YUV to RGB for free on the GPU, so YUV and RGB can play happily together, and you _don't_ have to go it alone.

> Even if the freeframe spec gets YUV plugin
> support I imagine most freeframe plugins will
> not bother to support YUV clips.

True, I think that hosts that work in YUV internally will end up having to convert to and back when handling non-YUV supporting plugins. Hosts already have to do this for 16/24/32 bit stuff.

I think dlublin is concerned that there's a significant speed hit to the conversion in software, and he's right.

It's nice to let the user decide though between paying the performance cost or not using the plugin, by giving them a host that does the conversion.

[VJamm]

hey pete

can anyone throw any light on this business of RGB vs YUV in the storage of data in Quicktimes?

what sort of quicktimes are people using for VJing on the mac generally?

can't the freeframe plugins be processed on the RGB data served up from QT decompression before YUV conversion?

or are you all using YUV quicktime movies?

Russell

[sleepytom]

there seems to be a trend / push towards YUV quicktime codecs by the softVNS brigades - they are suggesting that people use the sheer codec - lets ignore the stupidity of converting dv clips to a codec with a higher datarate or the basic misconception that 320x240 sheer looks better than full res mjpeg and concentrate on the YUV issue.

with these YUV streams apps like grid are processing in softVNS and (presumably) uploading all the GL textures as YUV so with sheer video the process is 100% YUV as so its relatively fast as no colour space conversion is done by the CPU

when playing back an RGB clip presumably grid converts to yuv directly after decompression and then processes it as YUV until its finally converted back to RGB by the GPU for the output (this makes any rgb codec clips seem slow due to initial inefficient CPU based colour space conversion)

if RGB>YUV>RGB>YUV conversion is a native GPU effect then why not use the GPU for the initial conversion? (quicktime>GL>[convert to YUV}>SoftVNS>[processing]>GL>[convert to RGB]>Output)
similarly why not use the GPU to do colour space conversion before a freeframe effect - starting with sheer YUV file this time (YUV>SoftVNS>[processing]>GL>[convert to RGB]>Freeframe>output ) here we are just creating one more agp / pcix pass so the performance hit should be minimal (you would only be able to add freeframe as a final effect though)

the other option is to use RGB source files and process freeframe before converting to YUV for softVNS processing

whilst none of these solutions are perfect they all offer a way to integrate freeframe with a minimal performance hit - even this level of freeframe support would greatly expand the range of options for your users.

[DrEskaton]

I agree tom, 640x480 Photo Jpeg 75% looks better than 320x240 uncompressed YUV or sheer video YUV and is a lower data rate. Anyone who says otherwise is just making excuses to justify working in YUV.

All the mac Vj's I know use Photojpeg RGB quicktimes.

I would like to see all the SoftVNS based VJ tools do Freeframe processing on the RGB clips, then convert the result into YUV for everything else.

Even better I would like a preference option for the engine to either process effects and mixing in RGB or YUV. Let the user decide depending on how fast their machine is and what clips they have.

Certainly a 1.5Ghz Powerbook is fast enough that the RGB performance hit is not a big deal, especially if you start using the graphics card.

[KillingFrenzy]

It seems like this conversation is going around in circles when the only people that really have anything to say about the matter are incorporating all the options in the next release. It sounds as if Jitter is going to have support for dealing with YUV, which means it will have to provide conversion tools. Hopefully, these will allow you to test all the options and see for yourself which speed vs. quality issues you want to deal with.
SoftVNS is doggedly Mac-based, so wasting a bunch of time worrying about Freeframe's relation to SoftVNS is somewhat moot, especially with the high proportion of PC freeframe plugins. Grid may use SoftVNS in some way, but I figure they've coded their way beyond it, if they're producing PC versions of Grid. Besides, they're going to recode all the Freeframe plugins for speed efficiency anyway =)
I'm excited about YUV options, in the sense that speed improvements could allow me to jump from 320x240 up to 640x480 final output. I could suffer the quality of processing to get the final output resolution up a notch.

[syzygy]

Totally agree KillingFrenzy. The test will be when Jitter has freeframe support and the various mac developers can easily test how their applications perform with a freeframe effect in the chain.

Mac versions of freeframe effects are on their way, so hopefully the attractiveness of freeframe to app developers will only increase.

Dan.

[sleepytom]

Originally posted by KillingFrenzy

SoftVNS is doggedly Mac-based, so wasting a bunch of time worrying about Freeframe's relation to SoftVNS is somewhat moot, especially with the high proportion of PC freeframe plugins.
no that's the point - we want freeframe to be as usefull and usable on the mac as it is on the pc - freeframe was designed as a crossplatform standard and is totaly usable on the mac.

atempting to help people develop a way of using RGB freeframe effects in YUV hosts has to go some way towards improving the useability of freeframe - it should be possible to achieve a workflow that allows RGB FF effects without creating too large a processor hit - the best methodolgy being inserting freeframe effects on RGB source files before converting to YUV for the rest of the VNS processing.

The main requirement for mac freeframe at the moment is more host support - this way we can encorage more mac plugin development and thus have more mac plugins which will make for mac hosts feel like supporting the standard.

[dlublin]

On my way to a meeting in NYC, just wanted to reply to one thing in this thread real quick:

Graphics cards that are on an AGP slot are really great for doing video processing on the card, and getting video to the card is very very fast, however getting video back from an AGP (even on an 8x) card is much slower, so it really isn't feasible to use the GPU for doing yuv->rgb conversions and then moving back to the CPU.

- DL

[vjpixylight]

Originally posted by dlublin
On my way to a meeting in NYC, just wanted to reply to one thing in this thread real quick:

Graphics cards that are on an AGP slot are really great for doing video processing on the card, and getting video to the card is very very fast, however getting video back from an AGP (even on an 8x) card is much slower, so it really isn't feasible to use the GPU for doing yuv->rgb conversions and then moving back to the CPU.

- DL

It would seem like the new PCI-e specs would support doing this conversion.
With 8 more pixel pipes, it can push most of this to the CPU, leaving the GPU for more important processes like pixel shading, 32 bit processing and the like..
As for the PCI-e specs, it is supposed to double the speed of 8xAGP, but unfortunately won't be avaiable on Mac's any time soon:(
maybe the G6???

[murk]

Can a developer add effects to the Quicktime Effects library? or are those not expandable? If they are expandable, couldn't one just write a freeframe host for Quicktime? Then maybe the Quicktime APIs could handle all of the RGB to YUV conversion. I dunno, maybe not.

[vjpixylight]

Originally posted by DrEskaton
I kind of think I have to disagree with your philosophy here dlublin.

YUV may be faster for raw cpu processing but if you want to use pixelshader filters processed on the GPU aren't they all done in RGB colour space?

You may buy yourself some speed up on raw cpu power but you are cutting yourself out of the next generation.

Future VJ apps will be pixelshader and GPU accelerated for all effects and this gives a many times faster speed up than the benefit of going YUV over RGB.

I would rather have the benefits of access to freeframe effects + GPU processing in a VJ tool and take the slight performance hit of RGB over YUV.

I agree! you know, the colour space in question is actually YCbCr and not YUV, which is the colour scheme employed in PAL TV systems,YUV being somewhat different.. (NTSC TVs use YIQ which is different again). Why the PC video giddy's adopted the term YUV is a mystery..
YUV actually has 2 flava's as well.
There is the packed formats where Y, U (Cb) and V (Cr) samples are packed together into macropixels which are stored in a single array, and the planar formats where each component is stored as a separate array, the final image being a fusing of the three separate planes.
The latter format can actually be more processor intensive than the RGB>YUV>RGB conversion schemes because of the componet nature of 3 seperate color spaces needing the bandwidth and bussing to and from the CPU..
(I'm not sure, but probably more GPU's are actually doing this planar processing, which still makes the RGB>YUV conversion more costly in the long run, but I would go for more 3rd party plugin support over the closing conversion costs anyday..

[KillingFrenzy]

The handling of Quicktime effects in Jitter is pretty Dicey... especially on a PC.
I also think you'd lose the parameter control and multiple input capabilities, which is a pretty major part of good freeframe plugins these days.
The absolute best thing is if Cycling 74' makes the host.

If I were a freeframe programmer, I'd make sure there was a host for each major motion graphics program, that way I'd broaden my market into that territory.

[VJamm]

cycling is making the host, they've had it working in dev.

as far as we can tell most mac VJ clips are stored in RGB QuickTimes - so it should be possible to get QuickTime to serve up the video frames in RAM to a FreeFrame plugin in RGB(A), and then do conversion to YCbCr straight after - this could be just as fast as what is happening now if done right as QuickTime will be doing the conversion on the processor at the moment internally.

I'll contact the guys at cycling to see if this is possible within the way they've done the Max FreeFrame support.

The handling of Quicktime effects in Jitter is pretty Dicey... especially on a PC.
I also think you'd lose the parameter control and multiple input capabilities, which is a pretty major part of good freeframe plugins these days.

Yeah I don't think anyone has done quicktime effects integration for FreeFrame yet. I hope we do get a FreeFrame QTFX host at some point - it would be really good for people to be able to try out using FF effects without much programming, but for the moment I think people have decided it's not the best way to go for performance and flexibility in VJapps.

Russell

[sleepytom]

well actually most people are VJing in YUV QT but quicktime itself will do an extreamly fast conversion to RGB if RGB is the requested stream format for the file

this doen't change anything though - the fastest simple way to do freeframe is to have a FF effect directly after the decompressor - the deompressor will output RGB to FF which can be converted to YUV after the FF stage (this YUV conversion can be extreamly fast as shown by the conversions done by QT)

on modern computers with effecent code it is so fast to do rgb/yuv conversion that nobody will notice the processing.

and as has been said before it is best to let the user decide if something is "too slow" - they do not have to use any freeframe effects after all.

[jeremydb]

Hi - Jeremy from C74 here. I just wanted to respond, at least partially, to this thread, which I've just skimmed through.

We've announced FreeFrame and YUV 4:2:2 support for the next update of Jitter (Jitter 1.5), and the FreeFrame object has been working on both Mac and PC for several months now. I personally think FreeFrame is a great idea and am very happy to be able to provide "official support" for the community's efforts. I'd like the see the spec expand, as well, but that's a discussion for another time.

Since Jitter is a "generic frame processing system", which happens to be optimized for video data, using UYVY in Jitter is no different than using ARGB, as far as the system is concerned, except that UYVY matrices are 50% smaller, with predictable performance improvements, as well as certain benefits for people working with openGL textures in Jitter.

Probably many of you know that there are currently "bridge objects" between softVNS and Jitter, which David Rokeby and I put together a long time ago. They might need a minor dusting off in order to know that UYVY data might be coming, but we'll make sure this happens. So, no worries for all you frame-rate-junkies out there, or for the good people of vidvox.com.

And "The handling of Quicktime effects in Jitter is pretty Dicey"? It's the first I've heard about it, if that's the case. As ever, we invite you to report problems, send example patches, rant or rave over at our mailing list (max-msp@cycling74.com), or send such info to our support email (support@cycling74.com). That's the kind of bug report we can't do much about, except a little head-scratching.

I think that was it - later -

jb

[jeremydb]

Dave expressed some concern about the need to convert from the "Jitter format" to the "FreeFrame format". Luckily, at a certain point, these formats just wrap blocks of memory. In the case of Jitter->Freeframe -> Jitter, we're able to do this without any "extra" copying (more than would be necessary for an ordinary Jitter external), except in cases of horizontal resolutions which are not factors of 16 (this is one of those FreeFrame spec expansions I'd like to see - rowBytes, please!).

Since FreeFrame is just a published standard, and not a code interface, the speed of processing really only depends on how well the particular plug-in is implemented - just like with Max externals. Since everything has been compiled in C, it's pretty quick.

Someone else asked whether QT effects could be expanded -- they can, but it's a PITA. They have to be coded as Quicktime Components and then added to the System, typically at startup. Everything but ideal.

jb

[syzygy]

Originally posted by jeremydb
In the case of Jitter->Freeframe -> Jitter, we're able to do this without any "extra" copying (more than would be necessary for an ordinary Jitter external),


That's great news! Sounds like software based on Jitter will be able to implement freeframe support in a really painless way.

Originally posted by jeremydb
except in cases of horizontal resolutions which are not factors of 16 (this is one of those FreeFrame spec expansions I'd like to see - rowBytes, please!).


We're definitely heading for the point where the next version of the freeframe standard is agreed so that everyone can plan it into their release schedules. There have been lots of great ideas suggested for improvements and extensions; the important thing is to get agreement from everyone...

Dan.

[KillingFrenzy]

My qoute...
"The handling of Quicktime effects in Jitter is pretty Dicey... especially on a PC"

In previous versions of jitter, I'd end up hanging the system when I went into the Quicktime effects dialog.. However, it occurs to me that I had similar trouble with them in some other PC application (albeit not on my new laptop with everything up to date, as in this case.)
Admittedly, I haven't tried it for awhile because it really isn't a horribly convenient way to use an effect. A Windows user delving into Quicktime effects is about as common as a Mac user playing with Windows media player visualizations. I especially think it would end up just being a really roundabout way of going at freeframe integration, therefore I was being fairly dismissive.

So, I'll say that in my very limited attempts to use quicktime effects in general, they aren't very convenient or stable on a PC. And, given the stability of using native Jitter objects, it seemed like a step backwards.

If I get a chance, I'll do another run at quicktime effects in Jitter and try and come up with a reproduceable example that hangs on my computer.

[dlublin]

Thanks Jeremy,

We were really excited to hear that both Jitter and FreeFrame are both going to support yuv processing, can't wait to try it out. I wasn't so much worried about the copying of data from Jitter to FF, my concerns were more about unnecessary conversions from yuv to rgb (which won't be an issue since both will support yuv), or having to go back and forth from the GPU (not so much concerned about going to the GPU, but coming back from the GPU as AGP cards are faster in one direction than the other, it could create potential bottlenecks). Like I said, can't wait to try it out.

My main beef with QT Effects isn't the way Jitter or SoftVNS support them, just that they are slow and pretty much unusable.. they just weren't really made for real-time processing.. anyway, that's off topic, and the whole QT Effects thing looks like it is being replaced by Core Image in 10.4

- David @ VV

[bluebox]

3rd-design is a collectif of artits and programer based in Istanbul (Turkey) . Our focus :
-Prototyping multimedia installations ( Real time processing , streaming...)
-Video creation and diffusion ( We are resident Vj in 360 Instanbul..)
-Sound production

Here is a Pack containing ViP 3.0 ( Visual Interactive Processor ). It's only a beta version ..and will be available soon for download at
our website ( www.3rd-design.net ..under changes ..be patient ). Anyway since this time , feel free to use and test it , and if you have any
sugestions or problems contact us .
ViP3.0 Pack content :
- Vip3.0 guide : Some quick start indications to start running the software
-The Main patch Vip3.0 ( a mxb file )
- Vj : the folder that contains all the subpatches to run the soft ( you should not rename or change those file otherw/ise Vip3.0 may not work propely )
Notes:
Vip3.0 is written under Max/Msp/Jitter environement . You have to download the Runtime versions of Max/Msp 4.5 and Jitter to use Vip3.0 ( Free
downlooad for Mac OS and Window Xp at www.cycling74.com ) .

3rd-Design
www.3rd-design.net ( under changes...)
studiodub@hotmail.com