Warning: These patches are now part of DataTools. Use that plugin instead.
|
|
Unsupported — We cannot guarantee that this software will work properly on Mac OS 10.8 and above. Please be careful.
Release: Spooky Send/Receive, v0.1
Release Type:
Production
Version:
0.1
Release Notes
Warning: These patches are now part of DataTools. Use that plugin instead.
This is the initial release of our "Spooky" patch plugin for Leopard. Included are two patches:
Whatever you provide to the sender becomes available to the receiver. You can "tune" each sender and receiver to have multiple pairs. Multiple receivers can listen to the same sender. If multiple senders are on the same channel, the one with the highest Layer Number prevails. As an added bonus, multi-patch applications that make use of this patch can actually pass data Between Different Renderers — that's right, you can tie all your compositions together with this patch set. Apparently this is possible ;) This patch is named after quantum entanglement, sometimes described as "Spooky Action."
Installation InstructionsPlace the plugin file in |
While handy in its own right, this patch was brought about because the audio thread stuff needs to be lifted off the normal composition graph so it can evaluate independently. With this, we'll still be able to provide input to an otherwise isolated piece of the graph.
Not sure how to go about solving output from the isolated graph yet though...
I like when you play with fire ! Work well Sending video from QC to QC on PowerPC G5/Leopard. So.... I try to do an FXplug, to send video From Motion to QC...edit in QC, and back to Motion... But... Bou-ou, snif...
it don't work....BUT... QC receive a freeze image from Motion one time.... Do you think it is possible do do this in theory ?
BEST REGARDS.
yanomano
Right now, it only works in one application's memory space. In non-programmer terms, this means that it says within one program, not to others.
In theory it may be possible, but Really Really Difficult; It'd need to use network stuff, and some data types don't support that automatically (Numbers and strings handle that well, but images would need to be taken off the video card, sent over loopback, and then reuploaded to the video card in the target application's memory space... this is really expensive.)
Alternative theory: We can do some Really Dangerous Stuff and use shared memory... still not sure how images would handle this, but it'd be faster than networking.
Now wow ! i've just been thinking playing with virtual compositions in QC leopard, the idea being to opening up a part of an application so people can plug in extra functionality, now i guess this spooky patch(aptly named, as it did give me a little tingle when it worked) would work great for communicating with users own (plug in) compositions. :) once again great work
...this is one thing i've been wanting in QC for long long long time. its going to make my compositions _so much cleaner.
i'll only be able to test in a week or two, stuck on-site with no spare time and a full internal hard drive so no leopard upgrade for me until i get back.
I didn't test it at all off of Leopard, but it might work on Tiger too. No fancy 10.5 hackery involved in this one :)
If you choose to try it out, please let me know how it goes.
It seems that the spooky patch don't work very weel inside an iterator...or i'am missing something....?
I didn't do any testing in iterators, but it looks like it's only setting the last item. Is this what you're observing? Is the expected output the channel number for each channel input (from 0-7 or 1-8 or whatever)?
I was doing a "simple test" to see if it was possible to do it...Any idea why it is acting like this ?
yanomano.
I've got an idea (need to tinker with some test builds to confirm it), it's probably the same thing that the MIDI patches in iterators suffered from around Christmas time last year. It has to do with the way the patch tells QC to execute it (executionMode and timeMode). Just need to change 2 lines of code if this is the problem. I'll test later tonight (heading out for the evening...)
Ok, I spent a bit of time exploring the Spooky Patch today to look at this problem.
It looks like the sender removes the value it added previously intentionally. I did it this way to keep someone from plugging in patch time to the sender, eventually using up all available system memory (otherwise, there's no way to remove items so they just keep accumulating).
After discussing it with smokris a bit, we decided to add an input to enable/disable the auto-cleanup feature for cases like this. I'll try to have a 0.2 out in a day or two with this new option.
So it's mean we must be carefull with it ! But it will work in iterators, so it will be ok to transmit events...
Just a couple of quick questions, as I'm thinking of using this to cut down on spaghetti:
Does it have much of a performance impact? I know it will have some, and I guess it will be negligible compared to the rest of the stuff in an average composition, but I really need to keep speed up on my current project (it'll be released publicly, so I expect bitching, and it's already so big + complex that I've made a loading screen that shows while it warms up :)
Second question is the opposite of the first, asking if it provides a speed boost ;) I'm really guessing here, but I assume that separate compositions run in separate threads. If that's the case, and you have a composition that hits the CPU fairly hard, would splitting it into two separate compositions and using spooky to communicate between them actually speed things up on a multi-core system? Any idea?
The performance impact of the Spooky Patch should be negligible.
Compositions do not execute on separate threads automatically. Your application can create multiple renderers, and run those on separate threads, but unless you've coded explicitly do to that, you'll be mostly single threaded (notable exceptions: the directory scanner, image downloader, and video input patches create their own threads, but those are only to keep the QC graph from stalling while their operation take place.)
QC's pretty efficient at passing values around (it's only a couple Cocoa messages from source to dest), so if you were to use this to, for example, pass a value all the way down into a deeply nested macro patch, it probably wouldn't have an appreciable impact on performance (Spooky only dispatches a couple messages too, so you're just trading which messages are invoked :)
As always with performance, benchmarking with reasonable tests is the best metric for performance. I can guess all day and say it should be about the same (no positive or negative change), but developers are often mistaken on critical-path questions :)
...on rendering start.
no more debug info for now, m'fraid. just a heads up.
I've found what causes this, but not all the plugins that have it are fixed yet. Can you confirm that it's this patch? (there will be a couple lines in console.app that indicate which patch fails).
In the mean time, a work-around that I found was to start QC from terminal ("open /Developer/Applications/Quartz\ Composer.app")
...i actually took spooky out of the patch; as it turned out, its use was slightly gratuitous.
edit - so how do you paste in code with angle brackets, then? ah well.
[ admin edit: fixed angle brackets ;) ]
I've confirmed it on my end as well. I've got a 0.2 on the way very shortly to address this (and some other tiny issues). Thanks for the report.