Forum Replies Created
OF client is in a transitory state, pending some changes in the framework. IIRC, the stuff in SVN should work if you add SyphonNameboundClient.h and .m from the Shared folder in Syphon Implementations to the OF project. Get back to us if not.
What do you mean by “output” from Final Cut Pro? FCP’s output is usually a file, often rendered at less than real-time.
If you’d like to send clips and sequences to QC through Syphon, it is probably possible if you do some coding and write an FxPlug that would render in realtime, but then it would only work while you were playing those clips/sequences in FCP, and if FCP decided to render in realtime (depends on system, codec, other variables).
FCP is an awkward choice for real-time video editing. Do you have to use it?
skawtus – calls to Cocoa-land need an autorelease pool set up around them –
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; // Cocoa calls here [pool drain];
sbook – as vade says, breaking the functionality down to something similar to the Cocoa API (the three distinct objects) seems the simplest way to do things – but you don’t need to exactly mirror the API where it doesn’t make sense – for instance it may not be feasible to support new frame handlers. If you get one way of serving frames and one way of drawing them from clients working, then perhaps someone else will flesh that out if they need the other features…
Great that there is a start at this – thanks!
As an addendum – if you were thinking of using a new-frame handler in a SyphonClient to achieve this, you shouldn’t make any assumptions about the thread the new-frame handler will be invoked on – assume it could be invoked on any thread, and that invocations for the same SyphonClient may happen on different threads.
As vade says, you can use QCRenderers on background threads, so long as each renderer doesn’t cross threads.
Hey, it sounds like you’re getting there, but yes, it may take some time for SyphonServerDirectory to discover servers, so it will often return an empty array at application start.
You should take a look at the state of our OpenFrameworks stuff on svn – it would be great if you could integrate your stuff with that.
You can get the current context with CGLGetCurrentContext() – no need for a modified GLUT.
Hey thanks, this is great. I’ve put this up on svn as an OF addon – it should integrate with the OF directory structure, but if I’ve got things wrong give a holler.
Further to vade’s changes I’ve removed all the Objective-C code from all the files except ofxSyphonServer.mm so the rest of the project remains pure C++ – makes it easier for folk to integrate with the rest of OF.
We’ll take a look at your Cinder stuff and get it up on svn soon too… many thanks for this.
There does appear to be a problem with the syphon client rendering to a matrix if the jit.gl.renderer doesn’t also have a window attached. Thanks for the report, I’ve opened a ticket for this, which you might want to watch
Hi Karl, could you drop us an e-mail at contact [at] v002 [dot] info and we’ll try to join up the folk working on Java implementations?
That got clipped
Syphon implementation with Processing would be amazing!!
Indeed! If skawtus or anyone wants to get going on one, let us know..
Hi… I’ll try to address all your points…
Simple Server won’t run – what do you mean by “does not start at all”? Nothing happens when you double click it in the Finder? (if that’s the case, are you sure you’re running MacOS X 10.6?)
“how do you get image or video to server.” – Simple Server is just a demo, it only plays the Syphon logo, it’s not very useful, so you can probably ignore it anyway. The server needs to be made inside the application that’s sending the images.
So can I use any app (Alchemy, Photoshop) that puts out a image/video through GPU or only apps that are *implemented* do it among each other?
No, the application needs to support Syphon, either natively (because the developer has integrated Syphon), or through a plugin or similar extension, like Quartz Composer, FreeFrame, etc.
I don’t know much about Alchemy, though it looks like something it would be great to get working with Syphon. I’d suggest asking on the Alchemy forum – if anyone there is interested in working on Syphon support we’d be happy to lend a hand.
Thanks for the report – the jitter objects are probably our shakiest code as the jitter API is new to both of us. We’ll take a look… keep us posted on any further issues you run into.
Yep, as you say, MadMapper makes us optimistic about Modul8…
Syphon needs to be supported in the sender – either natively or through a plugin or by the sender using some technology that already has a Syphon implementation – eg Quartz Composer.
We’ll have a public beta for you to play with really soon…
SyphonClient will return unusable SyphonImages from newFrameForContext: if used with multiple contexts which aren’t shared. This will be fixed in the next beta.
Edit: Fixed in public beta.
when it’s ready
10.6 is the only requirement.
Public Beta will be soon, that’s all we can say right now.
can duplicate. we’ll look into this, probably not immediately.