Forum Replies Created
-
Posts
-
In the framework itself, we have a separate object for server discovery, SyphonServerDirectory. Having that handled by a class method of JSyphonClient would be fine though I think.
I imagine JSyphonClient.serverDescription() is intended as an exact match for the framework’s SyphonClient.serverDescription, which returns the dictionary describing the remote server. I’m not sure how we want to handle instantiation of clients in JSyphon though – for OpenFrameworks and Cinder we do it using a server name/app-name string pairs to avoid having to pass the serverDescription NSDictionaries used by the framework around, which might make sense here too..? In that case JSyphonClient.serverDescription() would probably be replaced by serverName() and serverAppName() methods.
We need to encapsulate the SyphonImage which owns the texture, otherwise you’ll end up drawing with an invalid texture ID – the only way to do that without an extra object would be to have “lock” and “unlock” functions in the client which retain the current SyphonImage then release at unlock, but that greatly complicates multi-threaded use.
I’ve added an issue with a JSyphon TODO list. andres, I think you have more JNI experience than any of us if you’re interested in any of these…
http://code.google.com/p/syphon-implementations/issues/detail?id=8
Amazing software!
Cheers!
suggestion: it would be nice if the software could recognize syphon dimensions and used this as default for recording (1:1 scale)
Yep, this is something we have planned.
@gavspav if you’re still following – can you try the new beta 4 and let us know if you still hit that crash, cheers
Any improvement on frame drops?
Perhaps if you can post the simplest possible patch which you feel is giving inadequate output, and the exact settings you are using in Syphon Recorder’s preferences, we’ll have a bit more to work on. A general air of dissatisfaction isn’t enough 😉
Sorry, we posted simultaneously and I didn’t see your second message.
Without knowing what you’re doing to crop and warp the texture, it’s hard to know – but it sounds as if doing whatever you’re doing between calls to -bindToDrawFrameOfSize: (passing the size you’d like to SyphonServer to send images as) and -unbindAndPublish might work – otherwise perhaps if you share some more code we can give more precise pointers.
Heyhey, glad you seem to be getting there…
publishFrameTexture… does no scaling. imageRegion defines a sub-area of the texture to be published – useful if you are using a 2D texture with power-of-two dimensions beyond the size of your image. Internally Syphon draws your texture onto the shared surface, so any texture format is supported.
If you have a large texture you want to crop and warp, then either create an intermediate cropped-and-warped texture, and pass that to Syphon, or don’t use publishFrameTexture… at all, and instead -bindToDrawFrameOfSize: and -unbindAndPublish with code to scale/crop/warp and then draw your large texture between the calls.
The latter would be the fastest.
That make sense?
The current SVN has support two new features which might be of interest
1. The ability to indicate a preferred internal texture format, if you want to pass formats other than BGRA8 around. Support for this is working but not perfect.
2. The ability to inspect the current frame from the Server side, so you could use bindToDrawFrameOfSize: and then use the frame image elsewhere for your own drawing in the Server app, if that’s something you need to do.
There are a number of examples with the Rutt Etra download.
For general Quartz Composer advice you could try the Kineme forums. Google I’m sure will turn up any number of tutorials.
Good luck!
Because Syphon presents a single live video surface, and not a series of frames, eliminating duplicates is something of an imprecise science.
Can you try the following and let me know how you get on:
Set up your source patch to send frames at 30 fps
Set up Syphon Recorder to capture at 60 fpsThe fps setting in Recorder is a limit, so you should end up with a movie close to the rate of the source. Is it nicer than with Recorder set to 30 fps?
@gavspav can you e-mail contact@v002.info and I’ll (eventually) reply with an update for you to test, to see if we can eliminate the crash.
@hcjilje What sort of occasional glitches? Occasional dropped frames, or clusters of dropped frames, or something else entirely? What framerate is the source sending frames at?
A feature request: keyboard shortcuts for the snapshot and record buttons
See the File menu. Those will work from any app, as long as Recorder is running. The Help file mentions this, we should probably force people to read it at first launch…
Yea maybe OSC/MIDI, eventually…
Are you going to support more recording codecs, like apple prores LT?
We’ve just posted beta 2, which adds support for Apple ProRes 422, Apple ProRes 422 (HQ) and Apple ProRes 422 (LT).
as I wrote in my initial post, I did make a movie with numbered frames to check for drops and duplicate frames.
As I wrote in my initial reply, don’t do it like that. Generate numbered frames dynamically, not from a movie. You can’t be sure jitter will play every frame of a movie, or render frames only once.
I can’t give you jitter advice I’m afraid, because I can barely use it myself.
If you have real-world usage of Syphon Recorder with jitter that isn’t working as well as you’d like it to, please e-mail us
The simplest possible Max patch which reproduces the problem
A very short recorded movie and an explanation of what’s wrong with it
A screenshot of the Preferences window in Syphon Recorder with the settings you used to record the movie.where could I find the syphon recorder?
Hi, and thanks for the feedback
“non-realtime recording at full quality and no dropped frames” is not what Syphon Recorder is about. If that’s your aim, I’d flat-out suggest you try other methods.
This is a first beta, so forgive us if performance isn’t quite perfect yet…
In brief:
Jitter is a poor choice for movie playback – make a jitter patch that generates an image with a frame number in it, so you can be certain you’re serving one unique number per frame.Select “Syphon Recorder Help” from the Help menu: there is some advice on compressors. The short answer is, unless you need transparency, use AIC.
Any other disk activity will impair performance: quit applications you’re not using, turn off Time Machine.
The ProRes codecs seem to perform (very!) well, so yes, we probably will support them. Thanks for the suggestion.
Cheers, and let us know how you get on – Tom
If you’d like to talk about sponsoring work on network support, drop us an e-mail at contact@v002.info
cheers
