cwright's picture

We've been kicking around an idea to take QC plugins up a step.

Right now, there's a ton of duplicated header information in each plugin's source code. Each time we discover something new about the internals of QC, we update the project we're working on, but those changes do not get applied to all the plugins that already exist. This has caused some confusion (which our 0.5 template release scheduled for later today should amend somewhat, albeit temporarily).

There's also a pretty big lack of inter-plugin resource sharing. This isn't too important now, but as more plugins take advantage of customizations not available in the QC core itself, more code gets needlessly duplicated, and, more dangerously, more code gets to suffer bitrot, and slowly drift away from more active projects' upkeep.

To address these issues in upcoming releases, we've decided to start work on a plugin/project called 'KinemeCore'. This will be a framework for other plugin developers, and a plugin for QC itself. The framework will help keep all plugins synchronized with the latest template headers, and will allow them to take advantage of updates made in later plugins.

The first beta release of KinemeCore is quite a ways off. However, the better we plan on it now, the more robust and powerful it will be when the time comes.

Here are some features/ideas we've been considering:

  • A modified fork of Sparkle for automatic updates for all plugins (handled by the KinemeCore plugin, so plugins require no additional code, just some plist settings).
  • Numerous port-type enhancements. Presently, we're working on "transparent array" ports that behave like single values to non-array-aware ports, audio ports, 3d data type ports (from points up to models and skeletons).
    • along with the above, we're also planning on making a QuartzCore test suite which will profile the internals of the QC runtime objects. We plan to find slower objects, and possibly re-implement them to respond faster. This will be transparent to users and developers, they'll only notice more nimble execution.
  • Convenience methods for common application needs, to make QC-aware applications a bit more versatile. This includes loading plugins from arbitrary locations on the fly, creating compositions from raw bytes instead of just files, and perhaps even a programatic interface to allow compositions to be altered on the fly.
  • possibly some wrapper layers for easier Tiger/Leopard compatibility for plugin developers. Images and OpenGL are in need of this, with OpenGL being trivial, and Images being more non-trivial.

What are some other features that would help out QC users, excluding more patches :)? What are some features that would help QC plugin developers?

Comment viewing options

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

tobyspark's picture
sounds an act of sanity

the idea of a core sounds like an act of sanity.

sparkle auto-updating is gravy.

audio port type would be the bomb. 3d a bonus.

tiger compatibility don't give a monkeys: imho don't sacrifice anything for anything that doesn't improve the state-of-the-art.


cwright's picture

Here's a screenshot of the UI-tweaking portion of KinemeCore. Yes, both of those options actually work :) (though Snap To Grid doesn't persist across sessions yet, though that's pretty easy)

Screenshot of Quartz Composer with a modified user interface

KinemeUITweak0Teaser.jpg54.27 KB

tobyspark's picture

looking forward to the goodness...

franz's picture

so the wiimote patch is on its way to be working again i see.... :)

cwright's picture

yeah :) It's Really Unstable right now, but I'm working on it slowly -- There's so much to do right now...

On the plus side, my sister happened to pick up Guitar Hero 3 last week, so I might end up porting that interface to the WiiMote framework too (long term project, not in the next month or two). Image it: Fake Guitar input for QC! :)

franz's picture

give Trauma Center a try ;)

cwright's picture
UITweak - 2

Ok. Getting close to a skeleton KinemeCore to begin really developing with.

To turn heads, I've added even more insane UI tweaks too. :)

Quartz Composer UI Modification via KinemeCore

So, regarding the port stuff, I'm thinking audio will be the most useful and different, so we'll probably start heavily there (especially after seeing how Structure access has changed to be more array like anyway). Currently, I'm thinking of audio in 2 ways: a stream, where the port transports a small number of samples (512) frequently, and a monolithic dataset, where an entire audio file could be decoded and accessed arbitrarily. There are pros and cons to each, and both could probably emulate each other given some tweaks.

Any ideas to rectify/unify this? which would be more useful? is there a completely different model?

KinemeUITweak1Teaser.jpg54.97 KB

tobyspark's picture

This comment has been moved here.

yanomano's picture
Floating viewer or editor...

Menu item for :

Floating viewer ( to work with the editor full screen....) Floating editor ( to work with the viewer full screen...)


cwright's picture
full screen

The viewer can go full-screen with ⌘-F. The editor doesn't seem to have this function. This might be possible though.

How exactly do you envision editor full-screen? no title bar, like the viewer? Or just maximized?

yanomano's picture
Like this :)

Ideal GUI for me..... for expert ! you must know the short cuts....


QCcustomGUI.jpg268.83 KB

cwright's picture
Glass Windows

The KinemeCore Beta has a feature called "Glass Windows" which might actually allow this... or at least something similar.

Was this picture photoshopped, a Beta version, or an existing hack?

yanomano's picture
After effected...

I'll really like to help you if you go in the way of ergonomy with QC :)


cwright's picture
I'm all for it

I'd love to make the UI more usable, for developing patches, developing compositions, and for other uses too (VJ? it's a bit underpowered for this though perhaps). Please post your thoughts under one of the KinemeCore betas, or under a unique forum topic though so it's easier to access (this thread's a bit long now :)

cwright's picture
Try this on for size

Here's a quick "pro-mode" mock-up. The toolbars are automatically removed and hidden, and the windows are 'panelized' for the slender titlebar look. Not entirely like your picture yet though.

Picture 3.jpg
Picture 3.jpg230.31 KB

cwright's picture

So, I rewrote part of the DarwiinRemote framework to address the connectivity issues (updates for tomorrow, framework-based timeout handling, much better), and I decided to experiment with the Guitar while I was at it. For the life of me, I couldn't get the framework to say "I don't know what kind of device this is!" like it should for unknown devices. Reenabling some debug output shows that the GuitarHero3 guitar is actually just a classic controller.... so I guess there's nothing to port, other than mapping the buttons :( lame...