|
|
Unsupported — We cannot guarantee that this software will work properly on Mac OS 10.8 and above. Please be careful.
Release: KinemeCorePlugin, v20071110
Release Type:
Beta
Version:
20071110
Release Notes
Numerous small fixes: Native 64-bit Leopard build (including removal of legacy cruft from Sparkle), more intelligent auto-updating (daily now, instead of every time you start QC).
Installation InstructionsPlace the plugin file in |
Hi, Am I missing something really obvious here ? I put the KinemeCore.plugin in the usual place (/LIBRARY/GRAPHICS/QUARTZ COMPOSER PLUGIN/), and then, nothing happens, no Kineme menu, no UI hacks....
/LIBRARY/GRAPHICS/QUARTZ COMPOSER Patches/
is the place to go :)
The QC Plugins directory is for official API plugins.
Thanks a lot. BTW, i noticed that "Duplicate Viewer" option to be released.... Sounds interesting... are you really going to implement this ? (is it already possible to duplicate a QC view without rendering it twice ? )
It's a somewhat often requested feature. I'm hoping that it's possible without double-rendering (that's pretty useless, performance-wise). There's a lot of stuff going on to connect the editor to the viewer though, so it's really tricky (especially since it's all QC.app stuff, not QC.framework stuff, which is way easier to manipulate).
So, I'm remaining optimistic, but only time will tell.
"especially since it's all QC.app stuff, not QC.framework stuff, which is way easier to manipulate" do you mean that you already have a technique to do it, say, under Xcode when compiling an autonomous app ?
To clarify, when double rendering, would the app read a footage twice off the disk ? (or just render twice the quad on which the footage is textured to ?)
QC comes in 2 main parts: QC.app (the composition editor program itself) and QC.framework (the libraries that drive it, and other programs makes use of).
The patches and almost all of the work we've done on kineme are in QC.framework-land. We've taken it apart a lot, and it's designed to have people poke at it (in a totally undocumented kind of way).
QC.app, on the other hand, was not designed to be modifiable from the outside. So doing this requires more poking and some ugly hacks.
so it's simply a matter of design. frameworks are designed to be flexible, apps are not, and this is just a case of that.
As for how it would work, I'm sill figuring out how the original works. Some apps use CVDisplayLinks, some use QCViews, some use other methods of rendering. Depending on how QC.app does it, it could be simple or not simple. Hopefully it'll just require a memory copy (normal output to duplicated output), with no rereading, no rerendering, etc.
For info, i managed to duplicate the comp rendering with a little trick, for those interested. Render the whole comp in an image, then publish it. Then you can have it both in a QCview (bound to patch controller) and an NSImage bound to the published image , in a separate window. But the framerate is pretty lame....
The proper technique to do this would ben (quote): "a QCRenderer to render the composition into a pBuffer, create a texture from it, then display that pBuffer into two OpenGL contexts (preview and full-screen)" , which is way beyond my ability (esp. the two ogl contexts part, and subclassing the events to forward keystrokes and such because of the QCrenderer). If anyone got sample code for this, plz let me know.
Anyone else noticing huge cpu usage when using certain windows, especially the Javascript source inspector panel? I'm thinking this has to do with how I'm glassifying the editor window, but I want to make sure it's an actual bug in KC and not some other pre-beta...
is that kineme core connecting? whats b33p.net, the website there is a void.
b33p ("beep") is an internal site owned by kosada. you'd have to ask smokris for more details, I don't do much with it.
absolutely brilliant to have these two to hand. - private patches - search with category and possibly snap to grid, now that i'm back playing with qc i'll see whether i like it.
i wonder whether its possible to show split private patches into two groups, the CI ones and the not. that means we can have the mighty duo of log and signal to hand, without wading through a thousand CI filters.
After Months of work with kineme core, I can say that this is an awesome add to QC....I cannot work without it !
I was thinking to 2 or three things to improve it :
Maximum Regards.
yanomano.
the composition/macropatch would be pretty difficult, but very helpful.
separate slim titlebars is pretty easy (the viewer doesn't have scrollbars, so that's not necessary)
I think I have an unreleased build that has floating editor support (somewhat ugly, though). I'll see if that's what I think it is.
Load from Finder would be a separate patch from KinemeCore :) Do you mean that when you click the input port, it'll bring up the finder chooser window thing?
At this point, it's a bit difficult to update kinemecore because of the new goodies that are built into it (ala kineme3d). perhaps in a month or two, when it goes beta.
ok this is a reasonable delay!...:)
yanomano.
...would be to have the virtual patch system exposed à la 'make clip', qc prefs -> clips, without needing to restart qc.app etc.
i mean, they built it in, the most useful thing*, and then make it completely inpractical to use.
i kinda imagine this is well beyond kineme core, but hey just flagging it up.
toby