quick intro to say having tinkered over the years i've been using qc
quite heavily this year for vj related projects, mostly in
conjunction with vidvox's vdmx. lots of bug/feature requests to come,
but there's an obvious step i need to work through properly before
filing them against, ahem, tiger.
point of this post, tho, is to release the *spark titler, a
standalone application for running titles at events with a quartz
composer macro at its heart that can be edited to tailor the output
for each event. the xcode project contains two classes that others
may find of use, excerpts below. this is my first non-tutorial cocoa
code, so all suggestions/improvements welcome. even better, the xcode
project is supplied, so take it, improve it, and share it back.
thanks to roger bolton for the quartonian source and ray of vidvox
for the [NSBundle] cocoa pointers.
cheers,
toby
1 ------ Full-screen, second monitor output -------------------
This seems a perennial question to pop up, google wasn't too
forthcoming, so here is the magic. Subclass NSWindow including this
function, assign your output window to that subclass, et voilà.
// Idea is to override NSWindow's 'create window' function to parse
in fullscreen parameters, so any window subclassed to spkOutputWindow
will go fullscreen on the second monitor if possible
NSLog(@"screens: %i",[[NSScreen screens]count]);
if ([[NSScreen screens]count]>1){
NSLog(@"creating fullscreen output window on second monitor");
NSScreen* secondScreen;
secondScreen = [[NSScreen screens] objectAtIndex:1];
// Call the function we're overriding here, with the fullscreen magic
NSWindow* result = [super initWithContentRect:[secondScreen frame]
styleMask:NSBorderlessWindowMask backing:NSBackingStoreBuffered
defer:NO];
// Make it display above anything else
[result setLevel:NSScreenSaverWindowLevel +1];
return result;
}
else{
NSLog(@"second monitor not found; creating conventional output
window");
// Call the function without any modifications
NSWindow* result = [super initWithContentRect:contentRect
styleMask:aStyle backing:bufferingType defer:flag];
return result;
}
}
2 ------ Embedding resources for QC in an Application's bundle
----------------
Subject: Re: the view from inside a QCPatchController
From: jcburns <email@hidden>
Date: Sun, 8 May 2005 18:21:56 -0400
My question is...I have a Quicktime Movie in the app
bundle...trying to access it with the 'image with movie'
patch...and I haven't (so far) been able to figure out the
correct relative path to the movie as far as the EMBEDDED qtz is
concerned.
I don't think you can use a relative path in that specific case.
If you cannot have an absolute path, best is to specify the path
from the application directly and publish the Movie patch path input.
It's hard to specify an absolute path when your QT movie is inside
an app bundle on someone else's machine. Sounds like maybe another
feature request...maybe an idea that hooks up with the comments
about being able to tell what kind of environment "you're" in...the
QC app, a Quicktime, a Cocoa app, a screen saver...each seems to
have its own advantages, quirks, and issues.
I agree the oversight of this is surprising, however it boils down to
a line of code, a connection, and a published input in your patch.
the magic is -
