It's just going to be a Plugin with no app. Since people are
primarily interested in QC because of the costs, I don't see anyone
spending more money on additional QC software.
I suspect most people use QC at the editing stage, and their finished
compositions run in their own apps, information booth apps, VJ apps,
video apps or whatever. Roll your own if you can't find a free one and
find the QC editor unusable.
You need to sit down and design a couple of classes to dispense
devices so they can be acquired and shared across plugins.
Yes but it can't be in a stand alone QC plugin then can it?
That's not what I mean. Classes, not processes. Don't try to do
everything in your QCPlugIn subclass.
This is perfectly doable.
T
On 23 Oct 2009, at 22:47, Milton Aupperle wrote:
Hi Tom;
On 23-Oct-09, at 12:03 PM, Tom Butterworth wrote:
Hi Milton
I haven't tested your reported dealloc bug, but remember that the
QC editor is probably not going to be the app in which your plugin
is run by end-users.
It's just going to be a Plugin with no app. Since people are
primarily interested in QC because of the costs, I don't see anyone
spending more money on additional QC software.
If Apple provides a free product, people will use it over a
competitors product. Free almost always wins.
Secondly, the only reason I'm doing it is because Apple removed the
"Settings.." button from their own Video patch. If that was still
there, I wouldn't even bother.
If it's causing a problem for you at testing, then set Xcode to
launch another QC-cabable app when you hit run.
Oaky. W hat QC app that is free and offers the same sort of ability
as "Quartz Composer" is out there?
And what do I tell the end user whom wants to run it under free
"Quartz Composer" besides the fact that "Quartz Composer" leaks like
a sieve and you can't use it more thand once or twice before the
hardware is lost?
So we have a catch 22 situation here. The device doesn't get
accessed from the -createViewController until the -startExecution
method gets called because it hasn't been opened yet and -
createViewController is already allocated by the plugin so it's
all set to fail!. And if device is released in the -stopExecution
call, then it once again can not be accessed at all in -
createViewController. This is just a very poor user experience - I
expect Apple to be better than this kludge!
I don't see the catch 22 here.
The Catch 22 happens because I want to do the exclusive allocation -
init call of the however there is no guarantee that a plugin will
receive the -dealloc call to clean up after itself.
And the QCPlugInViewController code can be called before the device
is even opened in the -startProcessing calls.
So either way it becomes a mess.
You need to sit down and design a couple of classes to dispense
devices so they can be acquired and shared across plugins.
Yes but it can't be in a stand alone QC plugin then can it? And that
means they need to run another installer to install whatever thing I
do here. And it also can't break our existing QuickTime VDIG plugins
either.
You could subclass QCPlugInViewController to retain and release the
device as long as the view is around. You could also acquire and
retain them in startProcessing: and release them in
stopProcessing:, or at plugin init/dealloc, whatever performs best
in the way you anticipate your plugin being used. It should be
simple to share the same device (and textures/buffers) across
multiple plugin instances, and dispose of devices when no plugin
retains them.
Unfortunately that has really bad performance when starting up. You
could be looking at seconds of delays depending on device your
working with to get things started up. Or even failure to acquire
the device because a second plugin may have already grabbed the
device.
If you don't want to, there's no need to access the device in
createViewController. You could have a button in the view which
accesses the device and exposes the options when clicked.
createViewController does get called a lot in the QC editor, so
this might improve performance there.
And how does the createViewController tell you which Device is
supposed to be passed by this Button?
If you look at the QC Plugin code, createViewController is called in
the QCPlugin. However the setup and load code for this is done
Before -startProcessing and -stopProcessing are ever called.
So this is the first Catch 22.
The second Catch 22 is you can not create input ports when your in
the execution section, as from form Apple pointed out.
I looked at inputs and but the first major stumbling block was I
could never figure out how to limit the values into a rational
range so that the user gets what they want. In most cases hardware
wants discrete value ranges so that the is actually changing
something with their supplied value. So if a controls supports a
range of 0 to 23, there is zero sense having it as a float of -1.0
to 1.0 I seem to recall someone complaining about this from
lurking on the list for almost a year to see what problems
developers people had with it before I dipped in my toes.
Also inputs don't handle things like dynamic change. For example I
am using Device A and want to switch to using Device B or C or E
from within the same plugin. There is no way to handle that with
an input, because the end user would never know if and input
value of 0.23 is device "B" or if it's Device "E".
You can set minimum and maximum values for inputs, add and remove
them at run-time, and supply strings to populate pop-up menus, and
name inputs. I'm not as hardcore as vade about everything being
exposed as inputs, but if you want to go that route it is easy to do.
As troy pointed out, you can't create input ports on the fly from
the execution section and you can't configure the inputs for the
device unless it's open.
Type QCPortAttribute into the search field of Xcode's documentation
window, and also see addInputPortWithType:forKey:withAttributes:. A
glance at the Quartz Composer Custom Patch programming guide might
help too. As you say, inputs are read-only, so you would either
have to rethink ways of describing parameters so you have none that
affect another's value, or abandon inputs for configuration and
have them in your settings view.
I've read the guide cover to cover multiple times. I also played
with the samples too for about a week before I started this. The
lack of -deallocate method makes this a complete mess to work with.
Thanks for the suggestion though..
Milton J. Aupperle
President
ASC - Aupperle Services and Contracting
Mac Software (Drivers, Components and Application) Specialist
#1106 - 428 Chaparral Ravine View SE.
Calgary Alberta T2X 0N2
1-(403)-453-1624
[email protected]
www.outcastsoft.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com
This email sent to [email protected]
