[bangnoise]

git submodule update --init after your initial clone to pull in v002-Utilities.

What Kinect model are you using?

[bangnoise]

With the listServers() are you suggesting I check the list to be more than 0 to determine of a feed is available?

yep

There’s documentation in libraries/Syphon/reference in your Processing folder.

[bangnoise]

Hi

The available() function is confusingly named – it indicates the availability of a new frame since you last retrieved one, not the availability of the server.

I’ve opened an issue to request a function to do what you want – until then I’m not sure quite what to suggest – you might have to parse the result of listServers().

Processing’s SyphonClient could use some work…

[bangnoise]

Sounds like you’re getting there – just as a note, an init method should always call it’s superclass’s init method, for example

- (id)initWithContext:(CGLContextObj)context {
    self = [super init]; // Assuming super is NSObject
    if (self) {
        cgl_ctx = CGLRetainContext(context);
    }
    return self;
}

[bangnoise]

If you don’t need the new features of OpenGl 3.2 then removing the kCGLPFAOpenGLProfile line should give you a legacy context which will work with stock Syphon.

[bangnoise]

Syphon isn’t involved in the capture, no. If you are sending the capture out via Syphon, then obviously you are using Syphon. File a bug report from within VDMX and you should get a reply.

[bangnoise]

Not knowing how VDMX does its window capture, it’s difficult to speculate. I’d ask the Vidvox guys – they’re usually super-fast at responding to queries.

[bangnoise]

Aren’t you both saying the same thing?

In a plugin the situation is complicated by the actions of the host app. Usually the plugin interface will define the behaviour in its documentation, and you needn’t worry about locking at all as long as you adhere to its policies. If it doesn’t, then it’s possible the host may be using some locking mechanism outside your control, and then you have a real problem. If it suits your purposes then you can create a new shared GL context and use that with your own protection to ensure serial access.

If this is the same problem as you were having in January, then it would definitely be worth producing a reduction which exhibits the behaviour which you can share with us. Also knowing a little more about the host app and its plugin interface might help us to help you.

[bangnoise]

Hi – it will never be higher than the rate the server is sending, and it may be lower if Simple Client can’t keep up because the machine is under load. It’s a rough average of the last second iirc.

[bangnoise]

Done, thanks.

[bangnoise]

Hi

If your main thread isn’t servicing a run-loop (as it may not be in a command-line tool), then the notifications for server discovery won’t get serviced.

For example, the following works:

    SyphonServerDirectory *sharedDirectory = [SyphonServerDirectory sharedDirectory]; // Accessing it causes Syphon to begin finding servers
    [[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:1]];
    serverMatches = [sharedDirectory servers];

• This reply was modified 5 years, 11 months ago by bangnoise.

[bangnoise]

Hi – it’s the right place to ask.

Recorder is intentionally limited to codecs which perform well for realtime capture. For mp4 you will have to transcode the recorded movie in another app (eg QuickTime Player 7 Pro, Adobe Media Encoder, ffmpeg, etc).

[bangnoise]

Hi – if you’re still reading, can you tell me precisely what MOTU hardware you’re encountering errors with?

[bangnoise]

Hi

Does anything get printed from Syphon Recorder to the console (in /Applications/Utilities/Console) when you start a recording with the Numark device? That might give me a clue to the problem.

[bangnoise]

The answer is really “when you see problems” – do you?

The complexity of operations you perform will cause problems before the number of Syphon steps does. Try running each stage in isolation and note resource usage. Computer vision in particular is resource-hungry.

For what it’s worth, Syphon’s main cost is a chunk of video memory for each server – but your problem probably isn’t Syphon, but what you’re doing at each step.

[bangnoise]

It may well be a problem with Syphon Recorder and this particular hardware. I’ll take a look when I get a moment, but without hardware to recreate it, it may be difficult to track down the source of the problem. Sorry!

[bangnoise]

I used Instruments (comes with Xcode) – but you can monitor memory usage just by using Activity Monitor in Applications > Utilities.

[bangnoise]

After 21 hours, the app is using over 1 GB of memory, having started at 330 MB.

An instance which doesn’t include Syphon exhibits the same behaviour.

The probable cause of your crashes is a gradual memory leak in Processing or its video library.

I suggest you try a development build of Processing, and if the problem persists, file a bug with the Processing team.

Best of luck.

[bangnoise]

There is a gradual increase in memory usage over time, which happens even without Syphon involved (≈ 30MB in 12 hours).

I’ll continue to leave the with-Syphon and without-Syphon versions running, and see if I can crash either of them.

It’s unlikely to be the cause, but you should delete the call to println() in draw() to eliminate it as a possible contributing factor.

As yet I see no reason to suspect Syphon is to blame.

[bangnoise]

Curious – unfortunately I don’t have hardware to try to reproduce the problem.

1. Do you mean that it worked with previous versions of Syphon Recorder, or previous OS versions?

2. Does it work if you record Linear PCM instead of AAC (set in the Preferences)?

[Author]

Posts