StorePatch: Load OR Import.

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.

(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.

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... ;)