StorePatch: Load OR Import.

I would like to introduce an idea that could help for different matters such as Kineme 3D Licence, Copyrighted media (music, video...), composition sharing, composition carrying (on other computer), Application building, etc...

Some Patches import media (such as "Image importer") and imported media are saved and embeded with the composition. Other patches only load media (such as 3D, Video, audio files loaders) which aren't store in the composition. This is a bit confusing...

StorePatch: The idea is to separate those 2 fonctions in 2 patches in every cases with only one new patch: the StorePatch. A "loader" will only load a media (datas, video, 3D Models, music...) and the StorePatch will only store and embed (and protect) those medias in the composition (or application in the case of Export2App) like the "Import image" do !

Those 2 different concepts should help in many ways. If you want to create a composition with embeded stuff, you should link a Loader Patch (3D, Audio... as you need) to a StorePatch and when your datas/medias had been stored, you could remove the Loader from the composition ! Datas/medias are include, no need to manage them out of the composition ! If you want to create a composition with a browser ability, or a flexible management, you could choose to link a "Loader Patch" as usual, to your renderers, without using the StorePatch.

Then only the "Loader" could be copyrighted ! If you produce a composition/application to be shared or sell, you could include all the pluggins you need with it. Only the "loaders" could be copyrighted (by Kineme or others). People using your composition or application doesn't need loaders, they use you embeded datas/medias. They don't need a specific licence because they don't "Create" things with those pluggins.

Only copyright or serialise the Loaders. In this way, Kineme 3D plugins (or other future Kineme Pluggins) could be include in your Application (see: Export2App) or shared with your compositions. The StorePatch should work without licence, but the loader don't ! In the case of Export2App, Kineme 3D's pluggins could be include in the application without their Loader patches. If someone try to hack the application to grab the Kineme 3D Pluggins, he couldn't have the "3D Models Loader" which isn't there and which need a licence to be used in QC... And without a loader... You could do nothing with Kineme 3D...

If you want to share an application or a composition with your music, video... the StorePatch could help to embed all your media (useful for sharing, carrying or displacing projects) without the ability to catch them out of the composition. Useful to protect your work !

If you create a big project with a lot of sounds, pictures, StorePatch coudl help to create a full embeded and autonomous project.

When a loader has been linked to a StorePatch (every kind of datas), the StorePatch will import and store them and doesn't need more loaders to run in your composition.

The StorePatch isn't a ValueHitorian but it could store valuehistorian data ! This could help to create a kind of Value Bank ! or to build a kind of "Multiple Take" player without creating more patches than: StorePatch...

The StorePatch doesn't store running values (like the valuehistorian), it store static objects or different backup (like structures, audio files, video, 3D Models, xml, valuehistorian datas...).

The StorePatch should be linked first to a loader. All things that could be saved or loaded in Quartz Composer could be imported by the StorePatch.

What do you think of that new Patch ? Do you think it could be useful to embed/protect your datas/medias in the composition or application ? Do you think that it solve the question of sharing protected/licenced Pluggins ? Do you think it could be useful ?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

gtoledo3's picture
Re: StorePatch: Load OR Import.

That conceptualization is interesting... but maybe overly complicated? I don't know... seriously, I don't know!

However... I will throw out there that the value historian CAN record static stuff. You can pipe in a kineme3D object in static pose for example (haven't thought to try to record images or music though...probably wouldn't work at all?).... or you can record it after a set of deformations and such. The problem is, there is nowhere with a QTZ to embed that sort of info :o( So, you can't "save" it.

[You could possibly write the info to file (I believe)... but then there is no point in it, since you still have a file that has to float around with the qtz.]

My take is that all that would really need to be done to address what you are talking about, is an enhanced Value Historian. At that point, maybe "Value" should be lopped off the name :o) I think it would be really interesting to be able to embed that stuff- totally apart from your point about authorization and such, and I whine to Chris about this at least once every week or so since Value Historian came out.

I would bet with the way that patch/subpatches work, from my limited understanding, that the idea of doing authorization for just one subpatch within a plugin(patch) doesn't fit in? An interesting concept though.

mfreakz's picture
StorePatch is really different to ValueHistorian.

The StorePatch isn't a kind of simplified ValueHistorian. There is very inportant difference between them, i think. The ValueHistorian record value in real time, it's not an importer (and that's what ValueHistorian is a great tool: real time !!!).

Let's take an exemple: You want to embed a music (or a video) in your composition/application. This music could be used just to accompany your composition or to be analysed and used for interactive tricks, it doesn't matter.

Then: A "Kineme Audio File Input" could be provisionally linked to a StorePatch, Then the StorePatch grab and embed your MP3 directly. Then you doesn't need more "Kineme Audio File Input", so as you remove it, there's no path linked to an external MP3 file, but just an embeded MP3 file in your composition. Your could share or carry your comp with all needed medias or datas inside ! Loaders import media/data into computer memory. StorePatch do the same, but embed them too (like the "Image Importer") in the composition.

In this exemple there is some difference between StorePatch and ValueHistorian: 1) You doesn't have to "wait" all the playing time of you MP3 to grab audio in a ValueHistorian... 2) ValueHistorian may record raw media files (heavy size), StorePatch only import a "small" MP3 file...

There is another "big" difference between StorePatch and ValueHistorian (or other loarders). StorePatch does not load or save things. It may be strange for users to think about an importer without a path input for loading files, but that's the "special tricks" of the StorePatch. It's very important that the StorePatch does not load itself Data or media, because the StorePatch Protect the stored data/media to be catched outside of the composition/application ! With this special "no path input", the StorePatch need to be linked to a loader before, but it let every user build composition with Kineme 3D and share them with no Kineme Object loader inside ! The StorePatch just replace the Kineme Object loader (or other loader like audio files, video files, xml...) then there is 2 advantage: No files could be loose or should be provide separatly with your composition, all is include inside ! No Protected materials or plugins could work independently without a Loader, so with an embeded material, there's no matter about Licence or copyright ! No "hack" could grad ALL the Kineme 3D plugins out of an Application or Composition. We could freely distribute things because other people won't have the ability to catch our media or to catch plugins (no loaders means no use independently !). Without a loader what could we do with Kineme 3D Plugins ? Nothing than modifying the same only composition...

The StorePatch doesn't record or load things: it only STORE them into the composition. It solve both: embeded media matter (if you need) and protected media/plugins too.

cwright's picture
Re: StorePatch is really different to ValueHistorian.

mfreakz wrote:
A "Kineme Audio File Input" could be provisionally linked to a StorePatch, Then the StorePatch grab and embed your MP3 directly. Then you doesn't need more "Kineme Audio File Input", so as you remove it, there's no path linked to an external MP3 file, but just an embeded MP3 file in your composition. Your could share or carry your comp with all needed medias or datas inside !

Except that the audio file player only takes a path input (so it needs a file that's living on the disk, not in memory).

mfreakz wrote:
Loaders import media/data into computer memory. StorePatch do the same, but embed them too (like the "Image Importer") in the composition.

No patches in QC are designed to work with in-memory data (except for the image loader), so this doesn't automatically do anything without requiring all patches to be rewritten to make use of in-memory objects.

mfreakz wrote:
It may be strange for users to think about an importer without a path input for loading files, but that's the "special tricks" of the StorePatch.

"special tricks" is only 2 words, but it's not that simple. that's like saying "then we have an algorithm that does everything instantly!" -- it's easy words, but they don't mean anything, and aren't possible.

mfreakz wrote:
The StorePatch doesn't record or load things: it only STORE them into the composition.

Once it's possible to store unstructured arbitrary data, I'll take a swing at this. but not before.

mfreakz's picture
Not an insistent comment !

Don't take it as a redundant and insistent comment. I was replying to George before reading your explanation ! I understand that my idea is very naive. Sorry for that.

cwright's picture
Re: Not an insistent comment !

it's ok -- I'm not trying to pound you into the ground or anything -- but I do want to have a record of as many hurdles in solving this as possible, so future googlers/feature requesters might get lucky and find out it's impossible before asking. :)

cwright's picture
Re: StorePatch: Load OR Import.

Quote:
The idea is to separate those 2 fonctions in 2 patches in every cases with only one new patch: the StorePatch.

Unfortunately, this is simple in words, but ridiculous in code.

First: nothing takes Movie data (the file contents) as an input in QC. so, to handle movies, we'd have to write an in-memory file player to duplicate the Movie Loader patch. This is annoying, but possible.

Second: nothing takes FBX data (the file contents) as an input in QC. so, to handle Kineme3D data, we'd have to write an in-memory file player to duplicate the Kineme3D Object Loader patch. This isn't feasible with FBX's SDK without rewriting half of it yourself.

Third: nothing takes audio data (the file contents) as an input in QC. so, to handle audio data, we'd have to write an in-memory file player to duplicate the Kineme Audio Tools patch. This isn't too difficult, and we're slowly working on a different audio toolkit to deal with this anyway.

So, if you haven't noticed the pattern yet: Every data type requires a custom rewritten plugin. It requires a custom-written encoder, and a custom decoder as well (called "serialization"). There isn't a "store whatever the hell I throw at you to a file!" function, and there isn't a "Decode whatever the hell this file is, and give me a meaningful object out of it even if we don't have any code to deal with it!" function either. serializing arbitrary objects is actually ... not possible to do automatically. really. it's not. I promise.

So this idea, while cool, isn't possible, and any approximation is going to be more of a problem than just not trying to fake it.

mattgolsen's picture
Re: StorePatch: Load OR Import.

I don't understand this near to the level that you guys do, but couldn't something like the SQL Lite DB plugin be used for something like this?

gtoledo3's picture
Re: StorePatch: Load OR Import.

(not in response so the SQL Lite DB idea....)

... but I will chime in that- from an interested 3rd party perspective- with a QuartzBuilder application that wraps your qtz and resources (music, 3D objects, pictures) up as a bundle... and if the "non-free" plugins can be authorized/protected in a decent "other" method than what mfreakz conceptualized above (which I believe they can)... there isn't really any need to embed in the composition.

It's one of those cases of a great idea (mreakz's loader authorization/embed concept), that should probably be approached differently, with already established methods for the same basic end functionality. Only difference is that the resources wouldn't be embedded in the qtz, they would just be in an app... and the authorization would probably work differently.

cwright's picture
Re: StorePatch: Load OR Import.

No

Everything in QC is an "object" -- an object is a collection of data and methods.

When a function gets an Object, it sees something like this:

0xbfff5120

That's just 32 bits of information, called a "Pointer". A pointer points to the memory location where the object actually lives (so in the above example, the Object lives at memory location 0xbfff5120)

The function doesn't know what's inside. It doesn't know how big it is. It doesn't even know what the object is. The object could by a 4-byte (32bit) integer. it could be a 32bit float. it could be a 64bit integer. a 64bit float. it could be a 76MB NSImage. it could be a 2GB NSData object. it could be a string. it could ... you get the idea.

with objc, you can ask objects what they are (-[obj class] method). This will give you some info on what the object is. But just knowing what it is doesn't help you automatically save it. There's no "Insert into myCoolTable my_objective_c_object" SQL query. You can do blobs though, so let's explore that.

We've got a 10x10 pixel image. that's 100 pixels. So our blob could just be 100 pixels in a row, right? no. when loading, it might be a 1x100 image. or a 2x50. or a 4x25. or anything. So we need to store the width and height too. so, we store width, height, and then 100 pixels. cool. that works.

Now, let's store this object:

@class myCoolClass: NSObject
{
   void *_youReScrewed;
}
@end

now what? the class is only 4 bytes (plus NSObject overhead, so maybe 16-32 bytes, who cares). We don't have any idea what _youReScrewed is though. All we know is that it's a pointer (like the stuff above).

So, we can store that pointer. A pointer's only 32bits (64 in 64-bit mode). What happens when we load the object back? we get a pointer. to. nowhere. the pointer points to somewhere in memory that hasn't been initialized. or to some other object. or garbage. who knows.

So, rather than storing the pointer, let's store the data that's located at the pointer...

except, how much data? we could guess that it's 100 bytes. but if it's 101 bytes, we lose. we could guess that it's 10MB. but then if it's 10.001MB, we lose. we could guess that it's 4GB! nothing can be bigger than 4GB, right? right. except, now we've got a 4GB blob. in SQL. good luck using that.

Further:

struct _myStruct
{
   void *someOtherPointer;
} myStruct;
 
@class anotherClass: NSObject
{
   void *_thisWillConfuseEveryone;
}
@end

We initialize an "anotherClass" object, call it foo. we set foo's _thisWillConfuseEveryone pointer to point to a myStruct called bar. Inside bar, we set someOtherPointer to point to an integer in memory somewhere.

So we have a pointer to a struct that contains a pointer that's pointing to an int. But all our serializer sees is the pointer to foo. it doesn't know what _thisWillConfuseEveryone is or where it points. if it gets lucky (ridiculously improbable) that guesses it's a mystruct, it still doesn't know what's pointed to by that.

So, in a nutshell: no, there is no automatic way to store arbitrary unstructured data to a file, regardless of your storage mechanism (to a file, to a dictionary, to a plist, to the internet, to a sql db, to a cd-rom, to a network share, to your friend's iphone, to a postit note, to your screen, anywhere).

To quote an oldie:

willy wonka wrote:
You Lose, good day sir!

(please please please don't make me explain this further... ;)

mfreakz's picture
Mad Conceptualizator !

Thanx to throw light on this ! I understand that... it isn't so easy as i imagine... Sorry for that, but you know, as a simple "Conceptualizer" i'm working with strange and poor materials !

Sometimes it help to be naive, not this time ! Sorry to bother you with "another bad genius idea", i think i need a snack time... ;)

I just would like to go back on a George's comment. If StorePatch isn't possible (i understand fully), could we include protected media/data in the future Export2App ? I understand that QC isn't working "alone". It call for many resources and libraries... Quicktime is also working... ok... i understand it's not so simple. Could the future Export2App solve the matter of embeded materials and Licenced Plugins ?

Signed: Mad Conceptualizator (I will be back !) Gniaaaark ! Gniaaaark ! Gniaaaark ! (With a sound of thunder and a ghostly 60's Sci-Fi music...)

cwright's picture
Re: Mad Conceptualizator !

Media can be included, but it can't really be protected -- all the patches LOAD FILES FROM DISK, so at some point THEY HAVE TO BE AVAILABLE ON DISK -- encrypted files aren't immediately available. "hidden" files are possible, but I hardly consider that protection.

It's not Export2App's job to handle media/resource protection, because it can't -- the composition it can work with (because it handle the loading), but the composition's patches handle loading other resources (so E2A can't help).

Licensed plugins will be handled by a completely different mechanism (we're slowly working on that with franz on test piloting the technology, but we're slow and overbooked at the moment, so it's slow going).

gtoledo3's picture
Re: Mad Conceptualizator !

I think that just the ability to bundle resources standardly is enough for my needs. It would be awesome to encrypt included media, but as you say, it doesn't fit into that way that stuff works.

And while hidden files aren't REALLY protection, "dot trick" still isn't a bad one!

mfreakz's picture
StorePatch is born dead (again a "Mad scientist" movie...)

Well,maybe we could have an Export2App template that could embed all those needed medias/datas into the Application package. I hope this option could be done. Managing with external files could become a pain when we plan to share Applications !

I use "kineme Document Info" to bring the composition location path to a directory scanner, then i could browse into medias easily if they are store in the same folder than the composition. I could move this folder (composition + medias) everywhere and the path is always ok. Does the "Kineme Document info Patch" will be sufficient and help to return the good path into the Application package, like it does with compositions ? Maybe we have to find another solution to communicate medias/datas path to the original composition that will be turned into an application ?

About "hidden files": If someone has the "basic knowledge" (and above all: the idea) to right click to open an Application Package, i will probably have the basic system tool that show hidden files... But as we say ironically in French: "Ca peut pas faire de mal..." (It could'nt hurt !)

Thanx for all.

cwright's picture
Re: StorePatch is born dead (again a "Mad scientist" ...

DON'T USE DOCUMENT INFO -- it's a hack, and it really should be avoided (it makes assumptions about the app it's running in that aren't always valid -> 'splode).

In Export2App, resources will generally be automatically bundled in -- you can add others if you want. To get the path, it'll be an input to the composition (so it can load resources from there without needing Document Info etc).

mfreakz's picture
Re: StorePatch is born dead (again a "Mad scientist" ...

An input directly in the original composition ! That's a really good feature. Many thanx.

gtoledo3's picture
Re: Mad Conceptualizator !

(I have no friggin' clue what Chris has to say about this...)...

...but, inherently- any type of app can have a resource...and I believe that other "apps" that make "apps" have this ability. I think that the idea of this QuartzBuilder/template has been to have a way to send around your compositions, and have them be totally portable, and not have to have everything reside in this folder structure that typically gets sent around to share compositions that have resources.

... which an app sort of is! It's a "codified" way of approaching it...An app file is essentially a directory, and clicking on it initializes runtime... you have your executable file, .nib, plist, resources, etc, etc... It's a folder structure. So when you click... the "main app" which is the OS, knows what to do!

I know I am describing this in horribly caveman like terms.

In a similar way... you can have your own class of file created by an app, which is basically a little bundle (I am using luddite/potentially wrong vocabulary here).... look inside the package contents of a garage band file for example. That doesn't quite fit into the QC paradigm.

A qtz isn't THAT type of file.

Having these little "bundles" and being runtime oriented is kind of the obj-c/cocoa approach. It's not a bad idea to read up on as much about obj-c and cocoa as you can- even if you are mainly using QC, it will help you understand the reasons WHY behind various things, and perhaps even give you new insights that further simple nodal based stuff that can be done in QC. The other thing that is cool, is that you can see how different QC-esque things can be done without QC, and how you, already being familiar with QC, could shave off time that someone would spend trying to get an effect without QC... it cuts both ways.

Alright! That was some extemporaneous blather on my part, but may point you in an interesting direction, because you seem to have a real zeal for this!!! Apologies for any potentially incorrect terminology usage.

mattgolsen's picture
Re: StorePatch: Load OR Import.

So I think.. and I could be wrong here, is that what you're saying, in detail.. is that... it can't be done :D

franz's picture
Re: StorePatch: Load OR Import.

If the final destination is an App, why not store all the resources in the "Resources" folder of your bundle ? They won't be encrypted, but do you really care ? Just protect your QTZ (by hiding it in the Xib/Nib in a QCpatch controller for instance.) and you're good to go.

I guess the path would be something like tilde/Resources/myResource.FBX (i haven't tryied it yet, since usually my resources a +-= 3Gb , so this would make a pretty big .app, but i don't see why this shouldn't be feasible).

If you meant "Store in Ram" , then your best bet is to use a Ramdisk. (maybe script one so that it gets allocated + initialized when the app loads up)