Forum Replies Created
-
Posts
-
I’m working my way up this thread backwards as I catch up – first of all thanks @ZeroStride for all your work. I haven’t looked at your changes yet but excited to get to that.
MadMapper uses a newer version of the framework – it’s on google code as a branch (public-beta-2-gc). Your version is probably failing due to missing symbols from that version. We need to integrate those changes back to trunk.
Almost certainly due to 3.2. We haven’t done anything to support 3.2 yet. Encouraging it even works a little! If you have the time and inclination to take a look at the framework code then patches would be most welcome.
Sounds like multiple versions is the problem.
If the user is happy compiling there have been a lot of recent changes to v002 Open Kinect – they could build from https://github.com/v002/v002-Open-Kinect
HI yea we are vaguely considering some sort of automation for the future.
There is a period after ending a recording when you can’t start a new one (it takes a few moments to finish writing the movie file). It’s usually very short, but if you’re sending the stop/start immediately after each other then the start will be ignored.
I’ll think about a more useful way to handle this…
Thanks for the report – if you have the know-how feel free to submit a fix. I’ve opened this as an issue on the implementations project:
http://code.google.com/p/syphon-implementations/issues/detail?id=19
a) correct – you were creating an extra FBO for drawing offscreen from the main context when you can just draw in the context you create – but in fact you never do any drawing at all (apart from what happens inside Syphon)
b) -update doesn’t do what you think it does, see the documentation. You could do a glFlush() but actually Syphon flushes to push updates to clients.
c&d) CGLMacro.h handles directing commands to the correct context instead of using the more expensive makeCurrentContext, etc (see documentation). As you have one context per device you do need to make sure each device directs its commands to the correct context, but CGLMacro.h takes care of that (by using the value of the specially named cgl_ctx ivar to identify the context).Cool. If you want help on anything give a shout. I haven’t used OF for a while but I’d be glad to help out.
If you’re currently doing all your work in a render loop, it’s quite likely it doesn’t get called when the window isn’t visible, because it expects to have nothing to do in that case. You would need a timer or some-such to call your publish routine regardless of window visibility.
There will also be a speed-up if you don’t draw the texture in the window at all, but only publish it to Syphon.
Hey good work – thanks for this. I’ve been playing with the Canon SDK a bit myself, but not got anything to the release-worthy stage, so well done.
A few points
– It does work with a 7D, yay!
– Could you use the Syphon icon and not Syphon Recorder’s icon in the app icon? The icon is available at http://syphon-framework.googlecode.com/svn/trunk/Syphon%20Icon.icns
– The app crashes when I quit it with a camera attached
– There’s nothing about Syphon that means you can’t hide or minimise an app and keep a server running. This is probably a limitation of OpenFrameworks – it should be something you can work around.I’ve committed some basic changes to SyphonCamera – the same sort of thing could probably happen in SyphonNetCamera. Nothing major.
You could consider letting the cameras choose the pixel format if you don’t mind having to handle a variety of pixel formats and potentially non-CVPixelBuffer-based output – it would save the buffer conversion and for cameras which output Y’CbCr frames would half the data-throughput to the GPU as well – if you fancy that much work 🙂
Cool – I’m just taking a look now – all good so far. I might add some minor GL optimisations if I get a moment later. Thanks for this!
Tap the effect menu as if it’s a button once Syphon Server is selected and it will turn green and the server will start. Weird UI…
yea I’m not convinced of vade’s plugin idea either 😉
We’d link to your project from the syphon-implementations one and generally do our best to make sure it got wide coverage. The main problem with adding endlessly to syphon-implementations is that most people only want one of the implementations but have to sync the whole repository to get the top level shared parts – and some of the projects are fairly large.
As I’m quite a fan of SCM I’d rather add any changes to your code once it’s up on google code or github or wherever – I find it’s safest to be able to track my mistakes 😉
Hey cool – I’ve downloaded the code but not taken a look yet. Maybe this could live as a separate project somewhere – either on google code or github – our syphon-implemenations repository is in danger of becoming unmanageably sprawling. Do you use either of those? If you wanted to put it up I’m sure one or both of us will get around to providing annoying code suggestions soon 😉
George, I haven’t opened your composition because the accompanying e-mail indicates it is not a reduction.
If you can produce a qtz…
1. which always reproduces the CPU-usage issue for you
2. with no external plugin, file or build requirements
3. which is clearly legible at a glance
4. which we can play in the QC Editor… I’ll take a look at it.
If you can come up with the simplest possible reduction in a .qtz and share that with us, it will save us all a lot of guess-work. Do that.
