Well, let's start this great feature project.
It's about creating a new option or application, to export directly your comps in a suitable, executable and fully "stand alone" application !
For many of us this could be simply: a dream !
1) This could be:
- A new option for Quartz Composer itself, provided with a new version of KinemeCore Plugin.
- A new option include in QuartzCrystal as an Export option (so it could be paid a few for this great feature).
- A new Kineme's application made for such a specific function (with more option about Plugins integration, embeded medias, etc).
2) This could have:
- Two preset option:
- One simple full screen (you have no option available for your app, or they must be set in the comp itself with your own menu).
- One adjustable application with a simple menu bar (Quit, play, stop, preferences...). Preferences could report input and output settings, editable numerical and boolean options as in your root patch...
The adjustable application could also includea a file browser in the preference settings, for loading what you want: Structures files, medias, 3D models (maybe several). This feature could be linked directly in every kind of published loaders in your comp (in the root patch). It's just a simple way to link a path to your composition. It could be great that the application keep your last choice in memory at startup (settings, paths...).
If the composition use loaders and savers patchs, it could be great to keep those files into the package of the application. This way, people could make their own menu and option. Maybe it could be done with "Kineme Document Info" to keep the right path...
The application should include your needed medias (automatically or manually) and integrate Official and non official Plugins. This app need to be compatible with all Mac and configuration (with restricted area like Tiger or Leopard only if this a difficult tricks).
For Official or non official payable/not free Plugins (as Kineme 3D for exemple) the application could check in the user library if there is or not the legal Plugins. For the others it could be really really great to include them with the application or to generate an installation option for the application.
What do you think of that ?
I think this is a great idea. I don't think the simple one would be too hard. QC already has an option to "test" your composition in a wrapper. IF it automatically exported published controls to a HUD window that was trigger-able via hot-key, that would be great too.
This will be a standalone product (we're hashing out details on it internally at present)
We'll introduce a new protocol that provides inputs (and possibly outputs?) for the composition.
Kineme Document Info is trash -- it doesn't work properly in most situations, and certainly wouldn't here (it expects the app to be document-based, and if it's not, it freaks out... no good). But anyway -- resource paths will need some kind of proper handling. (perhaps part of the protocol?).
I don't care at all about Tiger compatability anymore -- just juggling Snow Leopard/Leopard compat is going to be a handful.
It could easily auto-include used plugins (with the expectation that such plugins are freely distributable -- for non-free plugs like Kineme3D, it simply wouldn't work. We could make a distribution build of Kineme3D for projects like this, should the need arise).
Stop/Play/Start should be the composition's job, not the app's (otherwise, it's just glorified QuickTime Player, no point re-writing that).
Things you left out:
Regarding some of the inputs/outputs, we might tie NSApplication events to the ports (openFile, shouldTerminate, others), so the composition can control the app to some degree. My vision is that this would be a kind of thin QC runtime to make QC-based applications easier -- just making a QCPlayer isn't terribly interesting or useful (and there are a zillion projects/samples that do that already).
[this is all preliminary, and subject to change. Feel free to toss in other features/ideas]
Yes, Awesome, Superb, Everything Good!
Some sort of scriptability would be nice to I think. I haven't really thought this through, but if there was someway to copy resource files from inside the app to specific locations. The font question I had the other day comes to mind.
Encrypt-ability would be swell as well. And some sort of unique log file for the application, with a filename that changes based on what comp you have loaded. So if you run it multiple times with different compositions it logs a different filename ie KinemeQCApp-Composition1, where "Composition1" is the name of the original composition file.
I like the sound of this.
Chris on the encryption question, can an exported .mov from QC be opened to get out the .qtz equivilant by somebody. How hard is it if possible.
What can the zillion QCPlayers do? Can they produce a double click app with your comp (and plugins?) inside?
Back in tiger, I made a little proof of concept Safari/Quicklook killer .mov where I modified the .mov file's qtz to do something nasty -- from that, I gather that the qtz is stored plaintext, so a simple .mov parser could probably extract them. I haven't done anything with .mov (other than through QuickTime), but it can't be too difficult -- do you want some compos extracted? or were you thinking that .mov might be a protection mechanism?
the zillion qcplayers can: load a composition in a window (or fullscreen) and run them. That's all I've seen them do. The proposed product above would produce a double-click app + plugins (also + resources) bundle.
I was more wondering if I distributed a .qtz product inside a .mov file, could a competitor (all hypothetical mind you) get to the comp tweak it 10% (for copywrite) and re-badge it.
Answer sounds like yes, with your help at least ;)
Also wondering about using .qtz inside .mov on web pages but that's less interesting. One advantage of Flash (.swf) is it protects your code doesn't it?
...although not something i'm in need of personally, it does indeed seem to be hitting the right note :D
Good idea with the encryption. So long as the pre-built app and the QC export plugin share the same key I can't see an issue there. But how about (assuming you're going to have some kind of UI in QC for export options, as you're planning more than the basics) a simple licensing option?
You could ask for the private key in the export dialogue, and provide a super-simple key generator with the plugin that asks for the private key and sale number to generate the serial. I'm guessing you have most of that already for crystal and performance tool.
A lot of these cool features could be a fair way down the todo list, and saved for a later version of course :)
I've actually been mulling the registration stuff over in my head since this morning :) I'm not sure if it would work seamlessly with our current registration system, but something conceptually similar... probably not for initial release, but it's definitely on my personal "I think this is a cool/useful feature" list :)
(I'm also not personally in need of this tool, obviously, but I can't even pretend to know how far people would take it -- Simple mac-based games without a line of code, etc... it could be pretty interesting :)
I think it will really lower the barrier of entry for creating software by users. QC does that to a certain degree, and entices you to learn more. That's how it got me hooked :D
It would be a great starter to get people interested I think.
I was just tonight thinking of a use for a program that can present a QCompostion in a window and present a series of published values to the user. The user can alter these just like we do with top-level published inputs in the Viewer Window but the layout might be a little less overlayed and more GUI.
When the user is satisfied with the comp, the application can then export a (non-rendered) QuickTime .mov file for pasting in productivity applications. One app in particular which I'm bashing my head against currently.
The idea would be to protect user from all the underlying noddles and nodes and let them just tweak the knobs, then export. I suppose a rendered export option would make it Quartz Crystal Pro. I'd actually like to customise it to a specific purpose and package it with some comps. There's nobody touching this in the area I'm thinking (Chris!!) So a distribution version of the app would be a good option for licensing or some such. A bit like those old (OS 8) installer apps you could roll your own with.
Not sure if this could be incorporated or is a separate application proposal from app in discussion above.
Hmm, but no matter what was used to export to ".mov wrapper" it seems that the same limitations would still apply.... eg., it wouldn't load any non standard api stuff on the play back.
It seems like the recurring .mov thing that crops up in this thread is a way separate idea, no?
Finally got the chance to read through all of this! What a cool discussion.
Ok, I'm going to be a jerk and suggest some interface builder type options for it, where you could do things like change how the publish inputs appear, stylistic options, etc, etc... and export to TI-86 functionality.
oh okay :|
Now that's I'm talking about... You could have a few standard controls: switches (throw, MOMO, (Off || On) ), sliders, knobs, value displays. These controls could be skinned various (user determined) ways. Actually, that sounds like a big ask, (and something for akin to XCode and NIB... but I'm not a programmer so I'll stop).
I'd be happy with just having the controls in a simple OSX-GUI-rules compliant kind of look with maybe the ability to control layout of controller positions, viewer window and a TIFF/PDF background.
If could package .qtz with plug-ins for Screensavers (.saver) that would be cool but only the screensaver app can deal with these, no?. It's not possible to have a .mov file with plug-ins? I guess not as it's QT. What about .qtz files that are encrypted?
To get to the point, I would like to distribute some artwork for Keynote themes that is animated using the Graphics Card not as a rendered movie out of QCrystal (which is deterministic by it's nature). I can do this with either .qtz or .mov wrappers and it's pretty impressive (experts on the forums say it isn't even possible to do what I've managed to come up with as Apple hasn't released this feature!). But these file formats are a) unsecured and b) do not support 3D party stuff (ie. assume it is there or worse won't run anyhow) c) there is a visible glitch between slides as .mov restarts.
An app that spits out encrypted unrendered .movs or .qtz files would be great! I use some code in the Comp to trick viewer of the movie in Keynote that it is continuous across slides even though it is restarting the .qtz on each new slide (it's completely independent of runtime). I obviously cannot do this with rendered .movs (but they'd be better than nothing).
If that's not possible I guess I could feature request Apple to allow .saver files into Keynote and perhaps relevant iLife apps and FinalCutStudio now I think about it. I should prob stop here, learn to code and make an iPhone application.
Yes! especially if other apps could be made to run them. I know FCPro doesn't like .qtz files. Apple might consider it a security risk having such files inside iWork documents if they can bundle 3D party plug-ins. (hey, Kineme GL could be downloading all my banking detalis right now!! haha)
Funny how someone always starts these discussions at just the right time!
I'm pretty sure that for iwork and the rest, you'll be limited to a basic .qtz or .mov file rather than anything coded (unless you want to code a plugin, and plugins are allowed..) so bundling plugins etc. is out. (Of course you could make an installer that installs the .qtz file plus qc plugins.)
There's no way I know of to encrypt the .qtz file or the .mov file directly and have it still work (the app will expect a normal file after all). But there may be options to protect it a bit more.
On one of my previous crazy attempts at doing something cool with QC (actually trying to make a QC-based demo, with music, in a 64kb .mov file) I took a good look at the quicktime docs. It's actually possible to create a .mov file that contains compressed data, which means you could create a .mov with embedded .qtz but it would be much smaller, and much more difficult to read (you'd need to look into the file, realise it's compressed and how, and extract and decompress the .qtz file.. not very difficult, but at least much harder).
The catch here is that I've not seen any simple way of enabling compression in the .mov output, quicktime pro certainly doesn't expose it. You'd most likely have to write your own .mov compression app.
Also, it's possible that quicktime might allow encrypted data. I didn't look into that, as it wouldn't have helped what I was doing at all, but if it's possible that would give a pretty well protected .mov file.
Well, i'm very happy that many people seems to like this project ! I just want to add some constatations:
The most important thing is that the app is protected itself an can be reversed. For the rest, we could do as we want, and this could become a problem in the future. Kineme couldn't help with that kind of managment ! (Oops, i've lost the serial...) Many of us just want to share their work and just be shure that it won't be stole. If the resulting App coud'nt be un-build that's enough.
Well, that's my opinion about protection stuff. Only the final App should be encrypted to solve all those questions.
We could had an "about" window in the menu bar, that let user write something spiritual (as - usual !) with an unremovable link at the end: www.kineme.net !
For those who persist to have a serial number generator, that's mean you plan to make money with your work (that's fully understandable) I think you'll have to ask something before to Kineme staff... in private, of course... Anyway, the only way to make money with your Apps nowadays is to make something stupid and fun for iPhone users... Promise, i stop speaking about iPhone... ;)
That's a good point... theoretically(haha) QC is a developer technology, and as such, your comments about 3rd party plugins makes sense. If you only have access to say, whatever settings are in the .qtz, then that is far from having full access to the plugin. (though taking something like an image filter plugin, publishing inputs and outputs, wrapping it up as an app... would be a little iffy, at least on a moral level... still not as useable as if the person had the plugin, so it IS limited...)
(I've always wanted to be a musician, so I could title an album after the subject ;)
Let me be clear on the plugin thing for a moment.
Plugins are compiled, and as such, this app can't do much with them other can copy them. Copying plugin bundles is super easy, not a problem. However:
If you use a plugin that isn't freely distributable, this tool has no way of knowing that. I don't feel that there's a good way to solve this, so the tool will probably just copy them in -- thus, the burden of following "The Rules" is on you, not us. I don't believe in making tools that can't be used to break laws.
Thus: the burden of being "protected" as a plugin lies with the plugin. For example, Kineme3D, ArtNet, and PerformanceInspector are plugins that protect themselves -- they can work outside of QC, but they don't work without a serial number. So in the above case (just copy it, and expect the plugin to do its thing), it works properly (no one gets free kineme3d). for non-kineme plugins, that's not always the case, but again, there's nothing we can do about that.
As a compromise: We can modify Kineme3D to be redistributable (but then tie it strongly to your composition/app) -- we haven't done this at all (because there's no need right now), but the theory behind it is well known by us, so it wouldn't be a big deal. This way, people could View Kineme3D stuff in a compo/app, but not be able to copy the plugin out of the app and use it elsewhere.
Plugins inside the app will pretty much always be accessible (View Contents) -- executable code stuff can't really be protected as easily (it can, but doing so is a pain, and fairly lame for the simpler ways of doing so -- I'm opting to just include them as-is).
The composition can be encrypted, not a problem. Resources used though, might not be encrypted. (embedded images would be, since they're part of the composition, but movies/stuff loaded from paths won't be)
+1 for a redistributable Kineme 3D. I occasionally release .qtz's as screensavers, and it'd be great to include k3d stuff in the mix.
And as soon as you release a beta of this, I guess I'll have to start making games with it. I've got a few ideas that would definitely be possible...
Also, it might be a good idea to have two price points for this tool, one that's just a drag and drop utility like QuartzCrystal and a second price point that gives you access to the code & a license to modify the code. (For example - let the people who want to password protect and encrypt everything, or pop up a window add that themselves)
A point about suggestions.
1) Integrated editable and readable encrypted String with the App:
I don't think this App need to integrate a Serial Number generator for the begining. But as someone seems to be very interested in, i would like to insist: we could make a kind of Serial condition in our native composition. Maybe a kind of XML file could be auto-edited by our composition and include in the main encrypted package with the composition. This could help saving preferences, last used conditions, and the boolean result of a kind of authentication.
More generally, Chris: Do you think this idea is feasible: Add and protect a kind of "Text file" with the encrypted Composition that could be edited by the composition itself and only ? This feature seems to be more useful than an include system of serial number, because it let the creator make what he want: Serial number authentication, but also limited time, number or date of use. It could help to make other tricks too, like start you App with the last settings, autorise only one computer to run this App, autorise or limit features in the main comp, store a list of IP, etc... I think a simple editable and readable "String" could do all the stuff.
2) Interface: I think the preference window should report the published input as there are named and listed in the root patch. If it's a boolean there will be a Check box and so on for all kind of inputs... Path should have to be linked to a real Browser. For special interface design and innovative concept: they could be done in the comp itself.
3) Many export option: I think it could be great to choose betwen many type of export: - A simple player for simply protect the original comp in an encrypted projector. - A real application with preference settings (published inputs and outputs), play/pause/restart, stop, quit, load/save (only XML like files), an "about window" (with your own text and links!). Startup option would be nice too (Full screen or not for exemple). All those options should be selectable. - A ScreenSaver file mode (very good idea) with published inputs for preference settings.
4) About this Project: - It should be an independent application like QuartzCrystal. - It should integrate ALL the needed Plugins in it, but with the limitation that they couldn't work if there are grabbed and droped in the Quartz Composer Plugins folders. - The resulting Apps, Projectors and ScreenSavers should be encrypted and self-protected. - There should be many selectable option for running the resulting app: Menu Bar or not, Fullscreen or not, etc...
And, at last but not least, an Adobe Flahs®, Apple iPhone®, Microsoft Vista®, C64® export option... Ok... sorry... I was joking... But it seems that we have the famous: Georges "DeNiro the King of comedy" Toledo in this thread, so it's difficult for me to resist...
A protected preferences/text file would be possible.
I don't see much of a difference between "simple player" and "real app" -- behind the scenes, they're the same app. Each different "product" that can be produced is a project we'll have to write, debug, and maintain, so fewer is easier (and less buggy) for us. I think there'll be one "app" (and one screensaver), and how it behaves is a function of what parameters you set when you create it (so you could create a player with no options/preferences, or one with preferences, or one with publishd inputs, preferences, etc.) hopefully you get the idea.
Regarding grabbed plugins not working outside the app: There's no way we can possibly do that -- not working in a separate app would require re-compiling the plugin with additional checks in the source code. Automatically modifying compiled code is extraordinarily difficult to do right. By "extraordinarily" I mean there are only a couple products in the world that do this, and they're not cheap.
You're right (that's not a question, i know you are Wright... ;)
When i describe those 3 export types (Simple Player, Real App and ScreenSaver), i was not thinking about 3 different Kineme Application, but 3 export presets in the same application. For the simple player, i'm totaly agree with you, it could be done by deactivating all option before exporting your App !
It could be great that this Kineme Application could produce both Apps & ScreenSavers. Maybe you plan to sell a simple ScreenSaver maker (low cost) and a Bigger Application Maker separatly ? There is a French expression who say: "Qui peut le plus peut le moins" (those who can do the best, can do the fewer). The "Big" Application Maker could do ScreenSavers too.
QUOTE:"(I've always wanted to be a musician, so I could title an album after the subject ;)"-cwright
Before I EVEN read the rest of the post... on bad puns... I've always wanted to make a movie where Bach is a secret action hero, staring Arnold Schwarzenegger called "I'll Be Bach". I can dream, can't I?
Another feature came to mind: not just making app bundles, but making screensaver bundles as well.
This would make screensavers that work without needing to install plugins or anything. Useful?
Mos def.... that one would be a cool option.
So ... everybody's going to laugh ...
What I use QC for is to make cutesy wootsy stuff that I can show friends via virtual webcam + video conferencing client. You know, Skype, etc. Except, nobody wants to bother with the conferencing client part. lol. and .. I'm rather uncomfortable publishing the things on the web, as if I thought I was some kind of artso dude or something. So what I would do is start sending out naggy (albeit colorful) little apps to all the folks who won't turn on their Skype and then skipping all that web publishing garboa. ahaha. I'd pay a good price to have that capability, eh? These will run on Windows, right? (kidding) :-)
All levity aside ... I want this. Sounds really great.
Yeah, I will pay a buck fifty for someone who will write an export to Windows function (sorry, I couldn't resist... hehehhhhhh). Maybe even two dollars. Hard to say.
and regardless that it can't be done ...
To be clear, I've never, ever, even once used anything but a Mac. Although it's true that it's only been ten short years that I've been using a computer. That said .. I've also never, ever personally met more than three other Mac users and, I do believe it would be easier to get those three to install and open a custom home-made app from me than to get them to click on a link to something I published. I'm serious.
But, I still want it anyway.
lee... that is actually hilarious. oh man. That is a keen observation. I think you are probably right.
It's morose. I know. Well, maybe the link-clicking part is exagerated, but not the part about resistance to video-conferencing. And that's a real pity. I can pop every one of these things I make right into Skype on zero advance notice. But nobody is there. har. :-)
Honestly, I'd be simply elated to distribute those pieces as gift apps. With end user access to published ports? Mmmmm. It just sounds soooo inviting. Count me in. :-)
Window options for the resulting Application:
1) An option to publish inputs and outputs settings in a classic preference menu style or in an independent floating window (like a tool and settings window).
2) Options about for the composition rendering window: - Scalable or not, "Drag-able" or not, fullscreen at startup or not, defined width/height (ratio or defined pixels), position at start up (like: Left up corner...) - Title Bars and Scroll Bars or not, classic or slim (like in the KinemeCore). - Floating Options: Always in front, in backgroud, floating or not... - Transparency and Borders Options like in the Vade project: "Borderless":
The main window could have a defined scale but without border, it could be transparent too (you can see your OSX Desktop through Alpha levels !).
3) The "so wanted" multiple rendering windows option ! The Export2App could create an Application with multiple Compositions (it could be great to create a "Real" Application), assuming, if needed, that they are running at the same Frame rate, with the same Local Time and that they communicate together with in a strictly defined method (Spooky Patch or other). Each Composition rendering window should have all options listed in the second suggestion.
A Composition per Window !
All those Window Options could help to create a "Real" complete Application. For exemple: - A composition could only render a simple image input (comming from another composition) so it could be a kind of prewiew window (useful for VJ's) as an other could render a more complex patch, the main window, and could be scaled, positioned or rendered in fullscreen on another screen...
A little App could have multiple windows, a main rendering windows and other little windows (useful for those who want to manage a special design for option and settings...).
A live installation could be render with a single App. Each Composition is a window with screen option... (Numerical Artist just ask for: "a Big Mac...).
Users have to manage with the complexity of their comps and the frame rate (like in QC, anyway...). Some imported Comps should be very difficult to render in real time, some other not... This system increase QC in another level: Over composition (windows) there is the main Application... and over Application there is nothing else (or God if you like !).
I'm normally fairly cautious, but I predict substantial numbers of purchasers for Export2App if it comes to fruition. I'm guessing that everyone commenting here has also probably arrived at a similar conclusion.
As Matt already observed, it could well have significantly broad appeal. We all know what its like to arrive at that sweet-spot grouping of ports and settings in our compositions and then become mesmerized with repetitive port fiddling for lengthy periods. Its a seriously addictive experience. :-)
So many positive comment and only 5 votes ! See at the top of this page... and add you vote !
heheh, I bet this will happen regardless of the votes, given Chris's strong comments. What a heck of a development within the course of a day basically. (though I think there has been talk of modding that skeleton project way back ago?)
This is kind of a lame comment, but I would LOVE for this to have the code for a multi-screen (and successful loading/rendering of 3rd party plugs within the multi screen environment) integrated as well. I say it is lame, because I am certainly overlooking something obvious in my lack of success with that...
multi-screen is a bit complicated, but not unrealistic. Perhaps not 1.0-worthy, but we'll see what happens.
for multiscreen stuff, there are a few issues to deal with:
First, some lame video cards barf if you make the composition context as large as both screens combined (mine, for example) -- doing this can cause it to behave oddly, and explode with weird errors, or possibly even panic (unlikely, but possible).
Some Mac Pros have multiple video cards, so spilling a context across both doesn't even make sense (half rendered by one card, half by the others? concept is simple, but actually pulling that off is extraordinarily difficult, hence all the hardware-nerd noise about SLI and all that.)
So, to resolve both of the above, it's probably safer to have 1 context/composition per screen. this is more taxing on the system (multiple renderers, more memory usage), but it works around existing driver/hardware quirks.
This means compositions would have to be designed to work on a specific screen though, so it's hardly automatic.
I'll perhaps check out QCPlayer/whatever the multi-screen tool is, and see if I can figure out why it's weird sometimes...
That would be cool... you might/ would note the prob with that one WAY before I would... it's "Visualizer".
The probs are understood.
Like you said multi-screen probably isn't a 1.0 release feature, but enmurating how many screens there are and choosing which screen would be highly beneficial.
enumerate screens at build time? that's a bit iffy, since there isn't a set number of screens per machine (typically, there are 1-4, but I've used several with 0, and a couple with more). I'm thinking some kind of criteria-based approach might be more tenable -- for example, lowest/highest numbered screen (so it opts for internal/external displays), larges/smallest screen, maybe left-most/right-most? (top-most/bottom-most?)... I'm not sure if the orientation ones are possible (I think so, but I'd have to check a bit more).
I don't really understand the screen problem (but i'm shure you know those kind of difficulty more than us !). Those who doesn't appear to make problems for me is that, as i'm working with a two screens configuration, when, usualy, i start a Software for the first time, all the windows are inevitably grouped in the same screen. If i move them to re-organise my two screens space as i want, some Applications remember this new arrangement at startup, others won't. I prefer an Application that feel more clever and memorise my screen settings, but it's really a problem ! When i was thinking about Multiple Composition Inportation, i was thinking of tha ability to create small composition to control, set or preview the Master one. If someone try to import two or more "Big comps" and fail to run them correctly or with good performances, it doesn't matter. As in QC (or whatever), when someone try to make an huge huge comp that slow down, it isn't our problem ! We all try to optimise things in QC ! (especialy now we've got the Great Performance Inspector !). Export2App doesn't need (for the begining) to remember screens setup. If the windows are dragable and scalable, we could put manually the main window in the right screen (or TV, projector...) and keep the others in an other starting screen. If OSX knows about the number of screens linked to your computer, why does we manage with this information ? If i insist for the Multiple Comps importation and integration, it's because i think it is one of the major feature for this new Kineme Software, and i think that people who knows how to build a simple App with Xcode would be also interested by this fonction too ! The Export2App software will raise another level an become more helpful for every user. With more than one window, we could really build more sofisticated Apps. This feature manage with a lot of other features who was exposed in other thread. Build an application could be the safe an efficient solution for multiple Screens management, Safe distribution for our works, presentations, sales, developments... I insist for this Multiple Comps importation ! By the way, as you would probably make this great App, would you mind to give us his future probable name ? It could be more simple in this thread to talk about, without confusing The App that make the apps... ;) You will be the father of another great Stuff, but i'm very proud to be at the begining of this idea ! (It was the case also for the ValueHistorian that was born under the name of Sequencer Patch !) Really, really thanx for all Chris. Kineme continue to be the most productive place for me. It could seems stupid, but i'm just happy...
"We all try to optimise things in QC ! "
Speak for yourself! I'm always proudest of the ones that make spaces, and dock nearly inoperative, and that run -1fps. :o) Maybe not "proudest" but it doesn't make me flinch, that's for sure... if your aim is just to render for video, to use with a music vid or whatever, it truly doesn't matter, and that's my aim sometimes. If I think it looks better with 20 expensive CI filters, so be it.
My own minus one fps comps seem to run somewhat better if I open the doors and windows for a couple of hours and let in the subzero Canadian winter air.
Regardless, I'm suspecting that I'll be learning to optimize for Export2App because if I send 'em almost anywhere else, the open portal trick won't be worth beans.
There's actually a precedent for this: one of the intel profiler options is "notify me when the cpu's critical temperature is reached", so you can spot "hot*" code (code that makes the cpu core heat up a lot). When the critical temp is hit, the cpu will reduce the clockspeed and step down the voltage a bit to prevent itself from self-destructing. So, when operating hot, you'll actually get a bit lower performance (for cpu-bound tasks, at least). I'm not sure if GPUs employ similar techniques, but I wouldn't be surprised if they did.
So that cold Canadian air (is that subzero in metric? ;) actually helps hold off that overheat trigger :)
(*) not to be confused with "hot" code as in "code that's in the cache"
So now I can blame bad fps on the fact that I live in Florida... sweet!
...this brings to mind the nice "cold" computer lab in elementary school... would always try to slip off of 90 fahrenheit + Phys Ed fields and INTO the computer 60ish degree computer lab, hoping no one would notice... I wonder if we even had to have it that cold (Apple II's and such), or if the computer lab teacher just made up an excuse so that he could max out the A/C...
I dunno. errr ... we go down to -20 celcius (is that metric?) for durations of several days to a week at a time .. but usually only a during a few instances each winter.
I actually only tried cooling the computer that way twice but the room became far too chilly to be acceptable. I was thinking however that it wouldn't be very difficult to pipe that air into the unit via a small tube, in a more controlled implementation. I might try that sometime.
I guess celcius is metric? (non-fahrenheit, which those of us south of the border use still...). I guess sub-zero here is more brutal, but much less common (0° F ~= -17.78° C).
I've heard of a couple datacenters using "outside" as a cheap alternative to Air Conditioning during some months.
I think K(elvin) is the proper metric measurement, but most places use C(elsius). K is good for science, as 0K = absolute zero. C is best for general use as it makes some sense (water freezes at zero, and boils at 100). F is just.. odd :)
That's why I wasn't sure -- Kelvin is just C with a sane offset (0=0, not -273.15=0). There aren't really kilo-degrees or anything, so I'm not sure if metric applies. K and C are definitely used with science more.
Some would argue that F is better for general use, since it provides more resolution (between freezing and boiling, there are 180 units, instead of just 100). If it didn't have the goofy offsets (32 = freezing? who thought of that?), it might be more useful. And with freezing/boiling points varying based on ambient pressure, they're all a bit silly, being based on water and all...
Anyway, I'm comfortable with metric personally, I just default to "temperature numbers = °F", so I figured I'd ask :) Long ago at another job where we'd sell stuff in pounds (and sometimes ounces), Canadians would come in an ask for amounts in grams -- most coworkers' eyes would glaze over, but I'd round 1 pound to ~450 grams, and work from there. ahh memories :)
We have a horrible mix of units here in the UK. It seems we're stuck half-way between the old imperial stuff and nice clean metric units.
E.g. most measurements are in metres, celsius, kilograms etc. Except roads, which are always in miles. And height of people, which is always feet + inches. And weight of people, which usually seems to be in "stones".. I've absolutely no idea what the weight of a stone is, but I know my weight in that and not kilos.. crazy :)
Likewise. I'm an immigrant to Canada from the States. 'Almost a Canadian' is how I sometimes describe the circumstance. Then, since I'm already approximating, I can sometimes also get away with tossing out an 'almost a fahrenheit' conversion scheme:
For quick approximate conversion of above-zero celcius to fahrenheit I double the celcius and add 30 to arrive at a sorta-kinda fahrenheit amount. It's not broadly accurate but I can do it quickly in my head. Close enough for casual conversation on the metro. :-) Closer: (9/5)*(celsius)+32=fahrenheit.
The zero point of the Fahrenheit scale is defined as the steady-state of the frigorific mixture salt-water --- i.e., when you add salt to ice, water's freezing point is lowered 32 degrees Fahrenheit.
...so Fahrenheit does have some kind of rational basis, albeit a not-very-useful-or-friendly one.
I'm thinking Celsius, keeping in mind STP, is the clear winner for us terrestrials, as water in its various forms is way more frequent and familiar than absolute zero.
Please Georges... You doesn't seems to be very interested in this project (and i could fully understand). So if you consider that it's useful to step in, why couldn't be more productive ? I apologize for my bad English (sometimes, it could take me 5 minutes to wrote a little post !). So excuse me to include you in those who want to optimise their comps... OK ? I'm sorry... I'm apologize... I was speaking about those who buy the performance tool, and wrote those thousand threads about Framerate, ierator tips, etc...
Now, Could you explain me the point of interfering to say: Optimizing is not always my interest (because i'm making movie), we are talking about making Apps so it's all about realtime not ?
I have the performance tool, and AM interested in optimization for real time, when applicable. Only pointing out that there are two sides to every coin.
I'm sorry that you view that as interference, in the same way that you viewed the serial registration option and encryption ideas that people were inspired with. It's great to come up with an idea, but also to be tolerant of what other people end up adding to it. It can be irking when you throw ideas out and they kind of mutate outside of comfort range... I've done a few worldwide remix contest things where first impulse is to think "oh they are killing my idea!", and it can be a bit cringe inducing. Your point of view is understood, and again, I was not meaning to be dismissive of your idea as it is great, only rooting for another perspective (mine, lol!).
George, even if you're not aiming for realtime, you should always optimise stuff. I guess that applies even more so for non-realtime stuff, because you don't want to wait days for it to render. The only time when it's not so import is when you're doing some private stuff as a bit of a test, and you care more about getting some results than the rendering speed. That's not a case where you'd use export to app though. Also, if you just want to play with visual effects rather than doing stuff realtime, why not just use after fx or something?
Apart from that, I don't remember seeing anything done in QC so far that isn't possible realtime, and that really makes the effort of optimising worthwhile if it goes from 1fps to realtime!
Anyway, take that as constructive rather than criticism - I think you can learn as much from optimising as from actually building stuff (at least I do). And also, I suspect that I hold the record for "slowest composition" - can anyone beat 8spf? :D
I agree -- the only times I don't optimize are when I'm trying out a new theory (to see if it's even functional), or when I'm trying to figure out accuracy (i.e. over optimizing and getting things wrong -- this happens in most kineme3D builds, unfortunately, because it's difficult to get specially crafted datasets. parametric surfaces provide some great corner cases, but there are others that can't be as well tested with that alone). Otherwise, minimizing memory usage, cpu usage, disk usage, etc help other things keep running smoothly (i.e. it's possible to make QC drop the rest of the system to its knees - no fun).
Part of what I find fascinating about optimization are all the little tricks -- it really makes you think about problems in a completely different way.
This one time, I made a composition with a javascript patch that performed an infinite loop -- that's about ∞spf :) (actually, it's happened a few more than one times, I'm afraid to admit :/)
..is where apple make their products. Makes me worry about the code a fair bit really. I think we've all been there though, with the javascript + infinite loop. Especially trying to write a 'while' loop while the code is running, I've killed QC tons of times that way :D
The 8spf thing was actually running correctly and generating frames btw, and that was running at 640x480 AFTER optimisation. (It was the slit scan video thing)
I think that "optimization" in QC is a tenuous term, because it does tend to mean doing something that can in fact have a different visual result. Not always of course, and on those kind of things, I agree 100%. There is always a point of "diminishing return"... you can disable color correction, blah blah, and it will look pretty much the same- but not quite the same. I agree that it is important to be aware of the shortcuts/optimization possibilities, I just believe that it's "a matter of relativity".
I find myself often making different versions of a comp, and there not being a big difference visually, but oftentimes the one that is less efficient is better looking for offline render and in the fine points. I definitely understand how one small choice can bring a 60+fps comp down to 5fps... I just stand on the side of that being a justifiable choice in many cases.
psonice, As to why I wouldn't use aftereffects.... because I don't want to! Aftereffects is it's own program, and in QC you are making specific little programs. I also work with Adobe products all the time, and kind of dislike them even though they can crank out great results.
If we are talking about optimization with 0% difference in visual output, then I agree with all of everyone's points :o)
If you wanted to wrap up an app where a user could chain together a number of CI filters to process video, willy nilly, with no care for render time, efficiency, or whatever... the proposed product would be a great way of doing such app. That's what I mean. I may know how to optimize an app, but for certain scenarios, you would just have to bite the bullet and give the user the ability to do something that may not be as "efficient". Another spin is that you could give someone an animated characters that they could setup some movement for and that they could process through various filters and render to video, making unique vids each time.
Agree to disagree, and most importantly, I wasn't trying to "not add anything useful" and be a Debbie Downer as whatever the comment above said, I was just sharing my opinion.
Not trying to incite rioting and panic :) (and this is all rather off topic, but interesting to discuss none the less).
Nor was I accusing you of being a "Downer" :) (I hope you didn't take it that way)
There are plenty of non-destructive ways to optimize compositions as well. Silly things like moving parts out of iterators, or not using macros (just having a macro for the sake of a macro has a few percent performance hit -- look it up in PT sometime :). even with shaders/filters/js, there are little things to reorder (allocation outside of loops, processing in vectors rather than floats, blah blah blah). Destroying output though is then a tradeoff -- those are much more difficult to make (and rely on artistic ability, not just technical ability).
And of course, there are times where there simply isn't anything left to do -- if it'll be slow, that's that. gaussian blur, radial blur, etc are all simply expensive. rendering 6-million poly meshes is simply expensive.
But on the other hand, I see a dangerous precedent/attitude being set, where people just say "well, it works! it can do what it needs to, so no need to improve it!"
A case in point: My wife uses Skype at work, so I use skype when she's there, so we can coordinate chores/to-do stuff (or just chat). Skype works rather well, and never feels laggy. However, when I run it, my cpu fan kicks on much more frequently. Top reveals something stupid like 10-14% cpu usage while it sitting there doing nothing but waiting for packets! Doing some more tracing, it's because they use webkit to render the chat windows, and some emoticons are animated -- thus, it has to redraw the icons, update the window, notify GL that the texture changed, redraw it to the screen, and then do it all over again endlessly (there's an option to disable this, which I discovered shortly after hunting down the annoyance). All of that could have been prevented if some engineer/developer checked the actual cost of their code, not just the "it works ok for me" benchmark (which is also important).
Anyway, sorry to let this get out of hand -- I hope no one's feelings are hurt :) I think we all actually agree, just with slightly differing points of view (some as developers, some as demoscene coders, some as artists, and others as just lay people). :)
[ps: as this gets to narrow for comfort: smokris and I have started drafting the design for this tool, and have a few use cases in mind to aim towards, so I'll be starting development on it hopefully within the week :)]
No offense taken..
I do think we all pretty much agree... I just felt that mfreakz was taking the character of my comments to task.... I'm not used to sharing my opinion and having an innuendo of trollism tacked onto it, or being asked to defend why I am "interfering" and such. I just thought that was an odd take on what I meant.
I see you're now taking offense then! Only joking of course, but your title shows how easily misunderstandings can happen :D
(queue sound of dead horse)
nah nah, no offense taken by anyone, I just wanted to say no offense meant on my part! :o) I wanted to reassure mfreakz that I wasn't trying to throw a cog in his works and always have good intent behind my comments when it comes to QC. The way I look at it, there is a really great community of people active in QC, and I have benefitted immensely from the selfless sharing of info by people like cwright and smokris, or zuga, the qc compositions stuff, toneburst, psonice, vade, memo, the very rich apple examples, lee, qarl, the developer list and a million others.
My original comment about ignoring optimization was slightly joking in nature and somewhat self-deprecating... though I do stand by my comments of it being a "what matters more to you" situation much of the time. I mean... running a humongous 3D scene behind a sprite, and you can't see any of it... OF COURSE you nix it :o) I as much as anyone will go through and tweak a comp to run really quick for realtime and know all of the things that I LIKE to do that add small visual refinements that bog things down. I would even venture to say that at this point I could figure out how to speed something up about as well as anyone. I have no problem NOT doing those things for realtime, because the things that I do that typically bog fps down only add a bit of polish anyway. (unless we are talking silly/sloppy stuff like having offscreen stuff running).
I always harp on the concept of QC being able to be used for offline based stuff simply because it can be, and also because I would hope that my puny pleads would help to inspire any chances of Apple making more robust tools for QC being able to be used in blender/maya-esque capacities, or simply to refine the engine so that it can do the stuff that is "borderline realtime in this version" more efficiently in future versions. So I always agree in optimizing, just not in "optimizing for real time".
A great, great, example of that is the "quartz crystal render" tab that smokris puts in his explode composition. Though I was already thinking in terms like that for some heavy video filters, I thought that was a really interesting way of making a composition that works in either paradigm- realtime AND render, with just a click.
Like... I would LOVE to be able to process the final output through CI filters to add shading and dof style effects to just about EVERYTHING and still get realtime, but it is simply inefficient much of the time. I want Apple to get their %^*& together and have stuff like a depth computation kernel that works without bringing things to a "groan".
This is like the most polite of all internet forums! :o)
the end :o)
I don't think that Export2App could turn a comp with an "Export Movie Patch" in something as good as QuartzCrystal. For non-realtime rendering (20 expensive CI filters for exemple) there is QuartzCrystal ! It's not a restrictive opinion, i understand that it could be great to manage with options and interface tricks but what about quality ? I just think that QuartzCrystal is the best quality output for our linear comps (I use QC to produce video FX too). It's not my function and i'm unpretentious, but i was just trying to manage with Kineme Softwares: QuartzCrystal for High quality linear rendering and Export2App for realtime Application exporter...
Also, i would like to add that you could use Export2App for a comp that run 1 fps or less, as you want ! That's why i don't understand the pertinence of your comment. Sorry for that ;)
(edit).
I don't disagree about Quartz Crystal being nice. I remember when I went on the Dev List and was haplessly whining about how much QC export to mov. sucked, and Chris popped up with Quartz Crystal. LOVE it.
Just like people are throwing out ideas for multi-screen things that may be impractical with this version... I am throwing out the idea that one could have an app designed to work with pause step rendering- that the user could possible change parameters on, and export to movie. You can use command line to render without Quartz Crystal as well... I think it's not a crazy idea and I'm sorry you don't understand it or think it's necessary... In the same way you seem to not understand why some would want serial authorization options or encryption- that's fine. People have different ideas.
I didn't even realize the site had that capability... It is entirely possible that I am the only dunce, but I wonder if that is the reason for the low vote count.
For the traffic we get [591 hits just from Apple this month!], voting and polls get somewhat disappointingly low turnouts. We try to focus efforts where votes/hits are, but with low stats, it's difficult to pick what people are really interested in :) sometimes it just ends up where lots of replies/discussion are...
From my experience, the vast majority of the people visiting sites like this never participate. They're either "just passing through, hunting for a bit of info or whatever, or are just interested in the plugins etc. and not the discussion.
From the small number that do get involved, just take a look through the user list.. how many of the names would you describe as 'active'? What we get in the forums, votes etc. is a tiny but very vocal minority.
I really don't know if what us minority shouters want is what the rest of the silent QC users want, but with no way to tell there's nothing else to be done really.
And YOU - yes YOU out there reading this and never saying anything, get involved now and again, it'll do you good :)
I know the breakdown -- we actually have a rather high retention rate (>80% of our hits are repeat offenders, with referrals providing about 8-9%, and search engines the remaining 10-12%)
So there aren't actually many passers by. But as for repeat visitors to active participants, the ratio is much much lower (2-5% maybe? from user list.. from repeat visitors that aren't registered users, it's probably much lower still).
I completely agree with the "don't know if the silent community wants this" sentiment -- that's our general approach. Better to do something rather than wait for a consensus that's never likely to happen at all on what should be done. :)
Yes, I am one of the silent ones, who daily checks kineme, downloads stuff and doesn't post much. But, as a silent one, I can loudly say that your work is great, and very, very appreciated... You guys are always helpful, and always willing to give sample comps and such. I mean, you rock. In regards of this export2app, I already gave it a vote.. and many months ago I bother you chris to give me some hints on how to compile a qc comp with xcode (me being a total ignorant with code) and you gave me some great hints... I tried and not succeeded... so, for me, there is no doubt on the usefulness of this app. Keep up the great work! I will try to be more active ;)
Would it be worthwhile to post a query somewhere to attempt to determine the demographics of the community? I'd be interested in knowing.
mmmm, now I feel bad about not doing as many of the votes :o) Only in elections. I mean, the vote I did on the particle tools had a set of premises that almost seemed overly harsh! At least I make my thoughts known in the discussions I guess :o)
Actually, I'm thinking that the forums could get somewhat busier if Export2App becomes popular. It might well be a broader general Quartz Composer interest grouping than is normally seen here, however. I'm not clear if that circumstance would be a burden or a blessing, but CWright is probably the most frequent current responder over at the QC dev mailing list anyway, as near as I can discern, so maybe it wouldn't make any difference. But then, as a guest here, it's really none of my business, regardless. I merely thought it was worth a paragraph of speculative comment since the subject came up.
In short and for better or worse, I think if there were anything that one might possibly look to as a source of increased forum participation ... the potentialy broad appeal of this proposed Export2App seems like a fairly decent candidate.
what does the "reset vote" next to every post do?
besides that, export2app seems like a very nice idea.
re: posting, i tend to post based on problems arising during projects. i always have one eye on kineme. i appreciate very much the work and the community. i'm learning a ton from the generosity of others.
To the left of each post there is a box showing the current number of votes, with a plus button beneath it so that you can up-vote it. If you click "reset vote", it will remove your up-vote.
Currently voting only has a substantial effect on Feature Requests and Bug Reports --- it affects the sort order in the lists.
We are planning to integrate this in other ways, such as causing posts with more votes to rank higher in search results.
Delightful!
I suspect once this (Export2App) app's exported apps get around a little you are going to get feature requests for gamer frameworks for QC by the boat-load. It'd cane the (platform) stuff that's out there at present for image quality.
I'm agree with you. Export2App could open a kind of Pandora's Box... We could have a lot of unrealistic features request after that ! But on the other hand, i saw some funny Games running on QC. That's just another branch of developpement ! Nobody could really say what QC is about not ? VJ's filters, Interactive Art, little applications... I think Kineme 3D has open the biggest Pandora'a Box ! The first models imported was a kind of Game characters... Wait and see... I think it's not a problem, maybe it's the begining of a great developpement ! Just imagine that we could distribute our works (Applications, Games, FX...) on OSX in a safe and clean way !
This tool isn't any more or less safe than other application (and in fact might be slightly less safe -- you'll be building apps that distribute executable code that you cannot guarantee safety of).
Simplicity is a definite benefit, but safety is definitely not.
Just wondering, what are the games you've seen in QC? I've done a few 'lunch break games' (done in 1 lunchbreak, with all the quality that implies ;) but other than that i've only seen an asteroids game.
Oh well... I was just thinking about Asteroid (and other pping-pong games !) But things could change...
Definitely desirable. After experimenting with George's recent 3D Object Loader work, I would say this functionality should be high priority if acheivable.
If multi-screen export-apps are a no go, perhaps they could be enabled to sync with each other when a preference to look for each other is set. Either 2/3 export apps on one machine (small, fast comps!) or multi-apps on networked multi-macs. QC-Visualiser like (but I haven't used it yet). Not high priority I guess but could make a great presentation app for delivering compositions to say clients or public distribution of a campaign of some sort.
self-synchronizing apps don't make much sense. Multi-composition apps are planned eventually, but we want to see what happens with single-compo apps first. mis-designing early on can be painful to undo later (breaking compatability, rewiring compositions, etc).
For the initial release, as cwright said, we're designing export2app to turn a single composition into a single app.
However, there's nothing stopping you from using any of the already-existing composition-synchronization techniques:
...and then building two or more apps with export2app.
Separating logic from interface calls for dual applications. I've started a project where one composition resides on a machine and decodes a home made controller, another one over the network does the rendering job.
It's hard to try to catch up with you guys, you are always ahead! Guys like me stay silent because they are affraid to say something stupid :)
You work counts so much to me, every day i am getting new ideas thanks to you. I'm dreaming of the day when I can contribute that much! So thanks!
"Guys like me stay silent because they are affraid to say something stupid :)"
Ah man, there is no such thing as a wrong question. QC is a deep subject to understand, and even when you understand it, it's easy to forget things. Just the other day I asked Chris a really dumb javascript question and later realized I had made at least half a dozen qtz's that employed the exact technique I was asking him how to do. THAT's stupid! However, asking about something you want to learn about is just a sign of strength my man! I feel like some of my most naive comments have ultimately led to some of my coolest results.
Points taken Mr Wright and Mr Mokris. I could do more – post less, but this discussion over-excites me. Would OSC operate without any network configuring? I'm thinking of an app (group) that you might email for an event and the recipients can just line up their {insert Mac hardware here eg. iMacs} boot and double click the apps and have a multi-screen performance without time syncing/start together issue . Again, sorry for the ignorance.
No, to use
OSC Senderyou need to manually specify the receiving network address.However..
You can do this using Network Broadcaster/Receiver.
Go to
/Developer/Examples/Quartz Composer/Compositions/Conceptual/and check outNetwork Broadcaster.qtzandNetwork Receiver.qtz. This should work on a local network without any additional per-machine configuration.On a semi-related topic, how hard do you think it would be to implement a Bonjour plugin for this functionality?
The Bonjour part of it wouldn't be too tricky --- QC already provides a Bonjour Discovery service, so we'd just need to implement a Bonjour Advertiser informing the network about which services we provide.
However, Bonjour only provides service discovery functionality --- the actual connection and communication are left for the application to negotiate. This wouldn't work with QC's built-in Network or OSC patches, because there's no way to parametrically modify the send/receive addresses (they're locked away in the Inspector Settings panel). So we'd have to reimplement those.
Well, after many posts of apology and pacification (we just want to be productive), i would like to go back on a specific topic of this thread:
What about Multiple Screens with Multiple Compositions ? I don't understand the screen problem. Chris could you tell me about ? If we could scale and move the different windows that a good point for the first version not ?
As psonice said below, single compo/single window is much much easier, and is useful to everyone. Multiscreen is significantly more complex, and significantly less useful. it's on the roadmap but not for the initial version.
We very rarely build all the feature's we'd like into 1.0 versions for 3 reasons:
1) the products need to ship. Adding extra stuff is cool, but it increases development time, building time, and testing time. No one wants a killer app that never sees the light of day.
2) we aren't omniscient. We don't know what features people would actually like/use (for example, we were very proud of Performance Inspector, due to its technical elegance, and its relatively error-free operation. It's also our worst seller of all time). We like to build in easy, well-used features, and see where people take it before planning too far in advance. (you should check out QuartzCrystal's development, from 1.0 to present -- new stuff came with each version.)
3) circumstances change. A feature might sound cool and useful, but just around the corner there might be an even cooler feature that does more. By putting it off some, we're better able to asses design and direction, without painting ourselves into a corner. (Everyone wants multitexturing in Kineme3D, but the proper place to handle that is GLSL/CoreImage -- it's not our place to force their hand with that, and it breaks existing compositions when things stop working in GLSL patches because we have to override glsl behind the scenes for the "feature". So while it's perhaps cool, it's actually setting us back farther than if we didn't do it in the first place).
Multi-screen/Multi-window requires a more complex UI, and we're not UI hotshots yet, so we're sticking with simple, and building from there.
(oh yeah, and I want a pony)
I understand. Export2App is simply enthusiastic, that's all ! Well i hope this feature (multiple Screen windows per Comps) will be integrated in a future version. For screens management, i think we could place and scale window manually for the begining will the ability to switch in fullscreen mode like in other Applications (Cmd F). Well, i hope you like this idea for a future feature.
Not wanting to tread on kineme toes here, as I don't know what they're planning, but I'll give my take on the whole feature list thing.
To keep it simple: tons of people will have a use for "basic" export to app features. Basic being: choice of fullscreen or windowed, published ports accessible or not. Encryption would be very desirable as people might want to sell their app and not have it easily stolen or modified.
The rest of the features like multi-screen, multi-composition, network features and the like are cool ideas, but they'll be very rarely used compared to the basic stuff. Things like that are also much more complex to do (e.g. multiscreen: i run the app on a mac pro with 8 screens. How does the app know which screens to show stuff on, and what to put where? Should the other screens be blank or what? It's impossible to plan for everything, and super complex to handle it nicely).
So anyway, keep discussing all these things, as it'll make for an excellent list of possible features (and sometimes a discussion like this leads to some idea that just HAS to make it into that first version :) but don't expect everything to get made ;)
I agree with you. It will be probably discuss again in the future... I just want to add that an option to keep Alpha transparency is very useful in this first version of Export2app with Fullscreen or Windowed option. Or maybe, more simply, the Export2App could keep Background settings of the source Comp ! I think about Vade's Borderless Application that stack a Comp "under" the Desktop... (That's great !) I think that keeping (as an option or not) the transparency (background alpha set to 0 in the Clear Patch or everything like that) let people create a kind of Finder's toy, or interface designs... As a comp could have a transparent background, we should keep it in the application settings not ? People could use that.
c/f Adobe Air applications.
I'm very happy to see that Export2App seems to be integrated in the Kineme's project ! As i couldn't help with code, i continue trying helping with concepts... Here is a non exhaustive list of idea, i hope that you find them useful and that other user would like to add their own.
The Option Board: (Optional settings for Export2App). Those options could help to create a "professional feeling" for the resulting Applications (great for users!), and suggest how to integrate native Quartz Composer's ability.
The real App's cosmetic stuff (may be previously managed by user in their original compositions).
1) Splash screen An option to import a picture (with a fixed size if necessary) that will appear first in the loading process of the resulting Application (this Could be useful to name and to sign the application, to add version informations, etc...).
2) "About" menu An option to wrote stuff (text and url) in the "About..." button in the main menu bar (could be dynamic using a specific published string output, named "about" in the original composition). It could be very useful to name/sign/number the Application too, but it could be also very useful for other "dynamic information" (such as Serial numbers, expiration dates, owner informations, etc...).
3) Save/Load option in the menu bar. An option to manage/route a published save/load input and output of the original composition (only one save output and one load input by Comp) in the main menu bar as a "save as..." and "open file..." option. It could be very useful for building many project (such as CI filters ;) and to help saving the state of an application. The save/load format are strictly the same as the published Quartz Composer's save/load patch in use in the original comp (Text files, xml, structure2File, ValueHistorian files !!!...).
4) State autosaving. An option to autosave the status of an application when quiting/launching. The user could "play" with the application and quit, when he launch it back, the application is in the same state (or not if this option isn't checked in Export2App of course). It's an alternative of the only Start/stop option, a kind of Star/pause. It could be integrated even if there is a save/load option, because it's not the same thing.
5) A Preference panel in the menu bar. An option to manage/route published inputs to a preference panel in the resulting application. Enable some selected published inputs in a real preference window in the menu bar.
6) A floating settings/option window. It's the same thing as the preference panel but using a different approach. The user could select published inputs used in the preference panel and other to be used in this floating window. Some inputs could be cosidered as preference, other as option or tools...
7) Preview picture. An option to display a small preview of the main window in the "Tool window". That's not really the Two window renderer (i hope that will be a future feature) but it could be very very useful to have this floating "Tool window" to control/manage the main window (the renderer) and to have the ability to have a small preview in it (VJs or live performers should be happy with this stuff...).
This Option Board for Export2App could be a kind of check boxes grid (with 2 entry). There is the full list of published inputs (all kind) on the right of the table, and the 3 possible locations on the top: Preference/tool window/load-import. With Check Boxes, the user choose which inputs are routed (or ignored) in which direction. The inputs checked for preference will be editable in the preference settings of the resulting application, those cheked for Tool window will be editable in the floating window and those checked as a load/import option could be launched or imported using "open file..." in the menu bar of the resulting application.
For the outputs, it's the same kind of table but with different route. There's also 3 ways: "About..." menu/Splash Screen/save option. Each option appear in two different panel (preference and tool window) in the order of publication. The unchecked imputs/outputs are ignored, all those personnal option could be edited in Export2App in a kind of "advanced option".
After the comfort/cosmetic option, here is some idea about the main fonction of Export2App (yes, i know, again a night burning the midnight oil...).
A) A 3 way export. - Export as a screenSaver (with the correct extension) - Export as an Application (basic one) - Export as an Installer !!! Those installer could help with future feature (as serial numbers - i don't ignore it ;) ). It could also help for including media or data with the application. This idea should be linked with another different thread (i'm on it !) called "Load or Import". About the installer: There different way to load or import things in our composition. The installer should create a new folder in the user's Application folder, which could contain other things like videos, datas, presets, sounds or images... When "Export as an installer" is choosen, the user could browse and select manually a folder with files/folders (respecting sub-folder like an image folder for exemple, or a preset folder...). This folder should be embeded in the installer. Then they will be installed with the Application in a main folder at the same destination (user/application).
Rather than having fixed functionality, we're actually thinking of creating templates for this sort of thing -- that way, we can introduce new templates as time goes on, without having to make everyone upgrade.
I'm agree with you, nobody need the same functionality. I will probably buy them all !!!
what about the not-so-cosmetic stuff (a way to manage with published inputs and outputs in Export2App) ?
Really, i think Export2App and QuartzCrystal are a great couple of applications that increase the potential of QC in those two different directions: Autonomous interactive application and Quality linear rendering...