freeframe builder with gui?

[devonmiles]

hulloh,

is there any need for a freeframe builder with intuitive graphical user interface that enables users with few/no coding experience to create their own freeframe plugins ? if so I will discuss it with our coding guys. thnx for your valuated feedback!

rirkrit
elektroschroeder inc.
___________________________________________
you have been videotaped

[burstingfist]

Hell yea, that sounds sweet. I would like to use something like that. Using the FreeChain tool, you can combine two or more FreeFrame plugins and create a new composite plugin.

[PilotX]

yeah man, sounds good to me.. dan programs freeframe atm and I want to learn so this sounds like a good in for me.. I have a little programming experience but not much.. I would be prepared to pay a small amount for it, if I could have a looksie first..

tom

[akira_k]

I'm definitely interested. For the less programming-oriented among the visuals community, such tools are always welcome. I have programming experience but I rather do things this way.

Would be nice if the price is a small shareware fee, or free. Obviously I can't talk much in this area, I don't know how hard would it be to make this.

[sleepytom]

i think that it is most important that a tool like this makes decent code that runs reasnobly fast, is stable and fully complys with the freeframe standard.

plugins that it produces should be standalone and transferable to other computers.

as for pricing / licencing i would prefer to see this developed under the GPL - ie make it opensource and prevent people from selling any plugins that are made using it

[akira_k]

Originally posted by sleepytom
make it opensource and prevent people from selling any plugins that are made using it But, under the GPL license (which I don't know completely), can these plugins be used in commercial venues under a VJ tool? Or used to make content that will be sold?

[sleepytom]

yes

the GPL would prevent plugins being sold that have been made using this app - it would not prevent the sale of footage made using the plugins, nor would it prevent the use of the plugins for comercial VJ work (eg filmgimp is a GPL application - it has been used to do hires compositing on hollywood feature films such as "scooby do")

[seex]

Sounds like a great idea, I have no programing skils and such a app wuld realy come handy. I guess GPL wuld make the whole shere the plugin thing easyer but i guess that bouilding this also takes time and skill.

If some sponsor or donator wuld be interested, it culd be an elegant solution.

[jaw]

does the freeframe standard allow openGL processing of openGL texture data? It didn't seem so from the site and the implementations i've seen so far...? (as one of the fine aims of freeframe that it's to be platform independent I assume directX is out of the question wich IMO is a good thing - platform independency is good)

[sleepytom]

freeframe is an independent standard for video effects it doesn't use opengl or directx - effects are processed by the cpu.

the full spec can be found here (http://cvs.sourceforge.net/viewcvs.py/*checkout*/freeframe/docs/specification.html?rev=1.2)

specific developer issues / technical discussion is best done on the http://freeframe.sourceforge.net/

[VJamm]

Few points here:

1. If the app is gonna give birth to plugins with a prespecified license then that should be the LGPL or similar. Plugins on the GPL can only be used within GPL applications. The LGPL is kind of the same as the GPL except that you can use the plugins in commercial apps. As it goes none of these licences stop people from selling the plugins, it's just that they have to keep the source open

This tends to work out in a very positive way for the community actually, as if someone wants to package some stuff up really nicely and sell it for a bit of money they can, but if they try and sell it for too much they will get had by someone else either selling it, or making the stuff available for free from the source. cf. Redhat / mandrake etc linux distributions

2. It would be possible to do OpenGL processing within a plugin, but we have shyed away from this so far, as it opens up a can of worms. As Tom says, its better to think about doing all the processing on the processor - ideally in very compatible C++ that can be mac / PC portable.

3. FreeChain would be much more useful for this kind of thing if we had a lot more very basic (but fast) plugins to use as building blocks.

Russell

[jaw]

Just some random thoughts:

Right, I understand.. I don't think it would be sane to make the stuff I'm working on do what this thread suggests, but anyhow, as videos (so far) are rendered by the CPU it would make sense to have freeframe support in my app. As the gfx hardware is so immensly superiour in crunching pixels it makes sense to do as much as possible in there. If so, a chain could look like:


Video-source -> Freeframe plugin chain -> Upload to gfx card as texture (openGL) -> drawing with the texture -> on to the screen.

This would be pretty nice, right?

However if you would do something like this:

Video Source -> [possible freeframe chain] -> Upload to gfx card as texture (openGL) -> Draw in openGL onto pbuffer -> download from gfx card into primary RAM -> freeframe plugin chain -> upload to gfx card again -> drawing with the texture -> on to the screen

..you would suffer from terrible frameloss (the worms you mention ;) )as the download speed of the AGP port is one quarter that of the upload speed. AGP isn't designed for sending pixel data up and down every frame.. For a texture to look OK it has to be at least 512x512x32.. That would mean 200 Mb each second. The AGP 4x upstream deals with 119 Megabytes per second so this is already too slow..

(bold are hardware-accelerated stuff)

[sleepytom]

russell
as i understood the GPL a plugin released under the GPL could be used (by the end user) in any host application (commercial or otherwise) - the GPL would prevent developers from using the sourcecode in any nonGPL app and possibly prevent them from distributing GPL plugins as a bundle with there non GPL software.

freechain would be better if it made selfcontained plugins - the reference model is no good for distrobution as everyone has there plugins in a diffrent place
-----------------------

Jaw
your example of "Video-source -> Freeframe plugin chain -> Upload to gfx card as texture (openGL) -> drawing with the texture -> on to the screen. " is pretty much how VJamm works - freeframe effects are processed before the video is mapped as textures on an opengl serface it is a good method that allows you to use the full power of opengl but has the disadvantage that freeframe effects must come first in the chain (ie the gl lumakey takes place after a freeframe colour change effect) - it would be nice to have the ability to process freeframe after the gl on occasions but as you have noticed the up>process>down>process>up method is just too much bandwith for the agp buss

[jaw]

ok, cool :)

thanks for fleshing these things out.. with this I've decided to add freeframe support to my app.. to do the first scenario. so people who want to mess with pure software-rendering where the pixeldata comes from a sonique plugin or webcam or whatever for instance.. and then mess around with the result using openGL plugins that are not freeframe.. :)

however, again, creating a freeframe builder is a totally different story.. :(

[VJamm]

Yeah - sounds like a plan

Have you registered with us at SourceForge?
the freeframe-develop mailing list is a good place to ask questions about freeframe host inclusion. I always try to help there.

We really need someone to update slightly the host inclusion template code for windows too if you happened to get chance to do that. (I presume you're in C++? - MSVC?)

We've also talked about one day starting a FreeFrameGL hardware plugins system, but this is really not trivial. GL hardware is a bit variable on different systems, and what kind of thing would a FreeFrameGL plugin be anyway? Its so much simpler just using framebuffer dlls on the processor - I think we did well to limit things to this, as it has let lots of plugin developers and VJapps get involved.

as i understood the GPL a plugin released under the GPL could be used (by the end user) in any host application (commercial or otherwise) - the GPL would prevent developers from using the sourcecode in any nonGPL app and possibly prevent them from distributing GPL plugins as a bundle with there non GPL software.

Well we discussed this at length on freeframe-develop when we established the licenses of PetesPlugins, C base Plugin etc etc.

Actually you would be arguing with micro$oft here - they are in court still i believe over this as GNU argue that there is GPL code in windoze stolen from Linux, and m$ argue that it is OK because it is in .dll's. Anyway, if we're going with the opinion of the GNU foundation, we understand that this is the whole point of the LGPL - it offers the same protection against commercialisation of the code, except that it specifically allows the use of compiled libraries of the code within non-GPL / LGPL applications (like VJamm / Resolume)

the L is often taken to stand for 'Library'

blah blah open source blah ... we love it really

Russell

[jeremy]

this is the kind of small tools that i can buy... (freeframe gui tool)


Jeremy from VJ's AlexetJeremy
www.AlexetJeremy.com