RFC: MetaFFRend / FF meta-plugin authoring

[victimofleisure]

Originally Posted by sleepytom

(pete's lgpl effects might be the exception to this)

I just re-read the relevant sections of the GPL. Looks to me like it's not a problem to distribute embedded GPL/LGPL plugins so long as the metaplugin is GPL. In other words, if any component is free software, it all has to be free software. This is by no means a unique situation: it's called a derived work.

Regarding source availability, the source of MetaFFRend will be made available. Regarding license availability, the distributor is responsible for including a copy of the GPL with the metaplugin. The author/license information of embedded plugins can be checked by simply opening the metaplugin in FFRend.

In practice there will be three legal usages:

1) Free metaplugins composed entirely of free plugins
2) Proprietary metaplugins composed entirely of proprietary plugins
3) Metaplugins that don't use embedding

[KillingFrenzy]

Here's another question...
Does this mean that a Metaplugin with embedded plugins can still be modified, or is it "compiled" as such and therefore not modifiable?
I mean if it is possible to have it just do referencing, then it would eliminate having multiple copies of the same code all over the place. For example, if I had 200 compositions made by linking vs. 200 compositions each of which had to include the embedded code.
I don't suppose you can support both?

The difference between the two systems in practice would be that I could create 10 compositions using only pete's plugs and another 10 using some effects from the Inside-us-all package. With the embedding model, I would not be able to post all 20 as free downloads to all users on my website. With the linking model I would. Include a link to the Inside-us-all site for purchasing, and anybody that wants to download my compositions, and purchase the IUA pack would be up and going. By the embedding model I would have no recourse other than trying to have somebody prove they bought the IUA plugins before giving them compositions, and even then I'm doing something illegal.
I mean, if it can't be done, it can't be done. But if the matter is a matter of decision making rather than necessity, I'd prefer both options or the one for linking. As far as linking conventions, I'll play by whatever system involves the least headaches, and am happy having 1 extra copy of all the Freeframe plugs I have tucked somewhere it needs to be.
Ummm... not to mention if somebody actually upgrades/bug fixes a plugin then a linked plug would be automatically updated, as opposed to an embedded one which would save at whatever state you created the Metaplug at. So, for example every plugin made up to this point with those buggy Pete's plugs would have to be re-embedded/built.

[beatfix]

So we can see that the intention of the bundling feature of MetaFFrend is to allow the distribution of the meta effects.

Yes, I would think this is the most exciting feature - non-coders being able to create and distribute new and original (albeit derived) plugins that are installed and used like any other Freeframe plug.

However how many effects do you have on you computer? and how many of these are you licensed to distribute?

I was thinking mostly in terms of free effects like Pete's and Chris' - there's a lot of mileage to be gotten out of various combinations of those.

Actually, I do see and agree with the point about linking being a useful method for sharing metaplugins that include commercial effects, or for managing a large number of metaplugins that share a common base. It absolutely makes sense and actually adds convenience for people in that position.

I'd just hate to see the bundled method get abandoned altogether, because I think it's a good set of training wheels for aspiring plugin creators.

This avoids the possibility of user accidentally distributing DLLs illegally - which would be a very significant problem if bundling was included.

"Accidentally" bundling and distributing commercial dlls wouldn't be a problem for me, or for you, I'm guessing. But there are other people out there for whom this sort of thing might happen more easily, or with less concern for the rights of the creators.

The same type of argument could be made against cassette tapes, CD burners, Bittorrent, etc. - and of course it has.

I don't mean to be overly glib - I understand that how best to respect and protect copyright is a very difficult and frequently divisive issue. I've also never created anything myself that would qualify as having great commercial potential, so I may not be the most qualified to comment on it.

On the other hand, I think that projects such as OpenTZT, FFRend, Pete's plugins, and FreeFrame itself all represent significant contributions to the free software and VJ communities, and I have endless respect for all of them. Making them easier to use and integrate seems like a logical extension of the spirit in which they were created.

[sleepytom]

well freeframe was deliberately licensed under the LGPL / Mozilla licenses to allow the creation of commercial plugins and the including of sample code in commercial applications - this is why it is such a widely adopted standard - it might be a purer approach to force others into opensource via the GPL but we wouldn't be here discussing freeframe if that had been done.

bundling ONLY serves to annoy commercial plugin developers - it doesn't actually improve the ability to create and distribute legal plugins - the search for dlls method allows distribution without creating any licensing issues at all.

Please stop the comparison with P2P etc it's a nonsense - your arguing that metaffrend is specifically designed to allow the distribution of commercial plugins. This is a very easy way to put people off developing freeframe plugins. (take syzygy for example - they make almost nothing from selling their plugins at a very reasonable cost - your potentially removing what small income they have from plugin dev by allowing widespread distribution of "free metaplugins" that bundle syzygy DLLs) it seems silly to put dan off coding plugins for the sake of the end users convinence (most end users will not have a need to copy plugins to more than one computer so bundling is only very marginally more convinent UNLESS your planning for widespread distribution of plugins.)

why not just have it work like this.
MetaFFRend composer is used to compose metaplugin. when you create a metaplugin the DLLs you use are added to "%application data%/FFrend/plugins"
if you transfer the metaplugin to another machine it looks for the dlls in "%application data%/FFrend/plugins" if it cannot find the DLLS their it prints a message to screen saying "plugin path error please open this plugin using metaFFrend to resolve" - the user then opens the plugin in metaFFrend which does a full search to see if they have the plugin anywhere on there machine. when it finds it the plugin is copied to "%application data%/FFrend/plugins" and the metaplugin will now work correctly in any freeframe host (even without resaving it)
To smooth over the user experience you could distribute all the free plugins with metaFFrend so everyone had a good set to get started with. You could even link to the commercial developers sites to buy the missing plugins if you wanted. (seeing as their are so few commercial FF plugin developers this would be easy to do)

this would create a better system of sharing and would encourage everyone to have a go at making metaplugins rather than simply leeching the good ones .

[victimofleisure]

Originally Posted by KillingFrenzy

Does this mean that a Metaplugin with embedded plugins can still be modified, or is it "compiled" as such and therefore not modifiable?

A metaplugin can still be modified regardless of whether it's embedded or not. Once a metaplugin is imported back into FFRend it behaves like any other FFRend project. You can edit parameters and automations, add or delete plugins, etc. and then re-export the updated project as a new metaplugin. This "round trip" capability means it's possible to create derived metaplugins, e.g. I could create a metaplugin and send it to you, and you could then enhance it and send it to someone else.

Originally Posted by KillingFrenzy

I don't suppose you can support both?

The plan is to support both.

Originally Posted by sleepytom

bundling is only very marginally more convinent UNLESS your planning for widespread distribution of plugins.

I don't agree that it's only marginally more convenient. It's much more convenient. And yes, I plan to distribute my metaplugins, as free software, derived from other free software. This is exactly the type of unanticipated, synergistic re-use that the FSF licenses were designed to encourage. I see no good reason to Vista-ize free software. I'm not Micro$oft, and syzygy isn't Hollywood. If you don't want to use embedding, just leave the checkbox unchecked.

And again, there is absolutely nothing to prevent someone from illegally distributing a commercial plugin right now. Anyone with a hex editor could change the license/author field if they wanted to. Has this happened? If so I haven't heard about it. No doubt most people pay for their commercial plugins, and a few people scam them from their friends or whatever. This is just part of life in the software biz, and it doesn't appear to have put commercial FF plugins out of business so far.

[KillingFrenzy]

Well, there you go. If you can support both methods then that's the end of that.
I can post linked versions, and people can build the embedded version themself, if they have the plugins and that works for them.
Best of both worlds.

[sleepytom]

no but it will make you unpopular with commercial plugin developers and put them off from developing more plugins. (not a good way to help the freeframe scene at all imho)

it is not much more convenient- if you distribute the free plugins with the installer of the metaffrend composer and address the path isssue correctly then you will not actually notice that the free plugins are not bundled with the metaplugins.

The only value that bundling has is to make it easy to distribute meta plugins that contain commercial DDLs to people who do not own legal licenced versions.

To distribute a commercial plugin now requires a deliberate act of piracy - you are suggesting building a application which actively encourages piracy for the sake of convenience.

I can assure you that end users DO NOT CARE ABOUT LICENCES I have distributed many "free" VJ clips under various share-alike licences which REQUIRE end users to SHARE ANY DERIVED WORKS - yet despite thousands of download of my clips i have not seen A SINGLE DERIVED WORK available as a download.

Your metaplugin app will encourage users to think that THEY HAVE CREATED the metaplugin and are thus FREE TO DISTRIBUTE it.

For the sake of the wider Freeframe scene and the developers within it i ask you not to include any function to bundle other peoples DLLs into your metaplugins.

[beatfix]

seems like we're just going to have to disagree on this one. i understand where you're coming from, but i don't share your perspective.

Please stop the comparison with P2P etc it's a nonsense - your arguing that metaffrend is specifically designed to allow the distribution of commercial plugins.

i could just as easily say that you are arguing that all sharing technologies are specifically designed to promote piracy. now, i don't really believe that you think that way, but i will say that you seem to be taking an awfully hard line against someone who has done a hell of a lot of work for the VJ community, with no expectation of any kind of financial reward.

i generally give away my content for free to anyone who expresses an interest in it. to the extent that i do make money as a VJ, i tend to do it through live shows. bittorrent, the internet archive, youtube - these technologies create outlets for digital media artists to share their work.

youtube is a particularly good example - before it came along, it was possible to share video online, but few people did it because it was so damn difficult. today that seems quaint. when you make something easier for people to participate in, eventually you reach a tipping point where community and creativity explode.

of course, there are people who believe that youtube should be sued out of existence. i'm not one of them.

to go even further down a controversial path, i also believe that there is room in this world for VJs to sample copyrighted material in the name of art, provided it is done in a non-commercial context. i like remixing other people's art, but i would never confuse it with my own, and i would certainly never try to sell it. of course, you'll just have to trust me on that one.

like i said before, this is complicated territory, but it is also the inescapable reality. i used to think that i needed to protect my work from others in order to build its value, but over time i've come to see it the other way around. it's a lot easier to build bridges than fences, and more satisfying as well.

j e f f

[Mavrick]

VJO uses a similar idea for it's freeframe compatibility.

A fxc is freely distibutable, if it uses a freeframe node it has a reference to it.

If you don't have the FF plug on your system VJO just lets you know it can't find the dll, and prints the test to the screen.

I would have thought that any distributed metaplugs would have something similar (store the reference to the needed dll) - storing the actual dll could cause some nasty violations of the original authors, no?

[victimofleisure]

Originally Posted by sleepytom

no but it will make you unpopular with commercial plugin developers

Commercial plugin developers can speak for themselves. If we're going to hear from them, now would certainly be the time. Otherwise I suggest we table the hypothetical intellectual property theft issue for the moment.

I'd like to see some discussion of more technical issues, e.g. how to handle the interesting problem of multi-input metaplugins. I've said that a exporting a project as a metaplugin would have no effect on its behavior, but this isn't quite true. As it stands now, a FFRend project only has one default input, the "clip" which is received by the first plugin in the chain. There needs to be a way to specify other inputs, ideally in such a way that the project works more or less the same way whether it's a metaplugin or not.

One idea I had: you could use the PlayerFF clip player plugin as a placeholder for additional inputs. When you export the project, the UI would allow you to designate certain plugins as placeholders, and when you load the resulting metaplugin into a host, those plugins would be replaced by additional input frames. OK it's a little convoluted but it allows the project to behave similarly regardless of whether it's a metaplugin or not.

BTW FreeChain dealt with this issue, but my impression is that it you couldn't test the plugin from within FreeChain, so it's not exactly the same situation.