Forum Replies Created
-
Posts
-
Thanks for your feedback. For the time being I will just go ahead and post a new package of the library, accompanying the 2.0b7 release of Processing and using the current list method. I will improve the server detection for the next version.
The main reference I’m using is the capture functionality in the core video library. Basically, there you just have a static Capture.list() method that returns an array of strings containing the list of available capture devices. Clearly, this is what I’m using as a model here.
However, it seems to me that the way the server discovery works in Syphon is not conducing to this kind of approach. Correct me if I’m wrong, but what SyphonServerDirectory does is not to query the available devices at a given time, but instead it passively waits to be contacted by the servers and then adds them to its internal list of servers, right?
An alternative polling mechanism where an event handling method would be called with the appropriate object holding the names of the registered server it is certainly possible, but the list() method would be preferred. Although the code I mentioned earlier works, it seems to me like a “problematic hack” that goes against the way server discovery works.
I added this code to listServers():
ArrayList tempList = null;
int size0 = 0;
int count = 0;
for (int i = 0; i < 50; i++) {
try {
Thread.sleep(10);
} catch (InterruptedException e) {
e.printStackTrace();
}
tempList = JSyphonServerList.getList();
if (tempList.size() == size0) {
count++;
}
size0 = tempList.size();
if (10 < count) {
break;
}
}
it is not pretty, but works. However, the numbers (10ms, 50 tot attempts, etc) are basically arbitrary guesses. Also, if there are many servers, the 10 < count condition might not be enough. So I wonder if there is a better way to do this.
Hi, I opened an issue about this:
http://code.google.com/p/syphon-implementations/issues/detail?id=26
and did some coding. I started by adding the following native method to JSyphon:
JNIEXPORT jobject JNICALL Java_jsyphon_JSyphonServerList_getList(JNIEnv * env, jobject jobj)
{
jobject serverlist = nil;JNF_COCOA_ENTER(env);
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];NSLog(@”Getting list of servers”);
NSArray *servers = [[SyphonServerDirectory sharedDirectory] servers];
NSMutableArray *output = [NSMutableArray arrayWithCapacity:[servers count]];
NSLog(@”Number of servers %i”, [servers count]);for (NSDictionary *description in servers)
{
NSLog(@”Adding server = %@”, description);
NSDictionary *simple = [NSDictionary dictionaryWithObjectsAndKeys:[description objectForKey:SyphonServerDescriptionNameKey], @”Name”, [description objectForKey:SyphonServerDescriptionAppNameKey], @”App Name”, nil];
[output addObject:simple];
}JNFTypeCoercer* coecer = [JNFDefaultCoercions defaultCoercer];
[JNFDefaultCoercions addMapCoercionTo:coecer];serverlist = [coecer coerceNSObject:servers withEnv:env];
[pool drain];
JNF_COCOA_EXIT(env);return serverlist;
}I can run it from Java, but gives 0 as the server count, even though I have several servers running already, which I can connect to with the Client object.
What am I missing here? In the QC server list plugin I also see some additional initialization, in particular:
[[SyphonServerDirectory sharedDirectory] addObserver:self forKeyPath:@”servers” options:0 context:nil];
Do I need to do something similar, or there is it a way to query the SyphonServerDirectory only one time in order to get the list of available servers at the moment of the query?
yes, I actually had a difficult time to connect the Processing client to a Quartz server. I tried the names that appeared in the patch components, at the end I was able to setup the connection using “Quartz Composer”, not exactly sure why because the Simple Client listed another name for it… so this is something that definitely needs more work. I think it is just a matter of properly implementing the server directory query, as bangnoise mentions earlier in this thread ([[SyphonServerDirectory sharedDirectory] servers] , etc).
yeah, I was using an outdated version of the framework in the Processing library, thanks for the hint.
I just uploaded the 0.4 package to the downloads section.
Remaining issues to solve for future releases:
1) reorganize the project structure, to make sure that both JSyphon and the Processing library always use the latest version of the framework
2) use SyphonClient instead of SyphonNameboundClient. So the way this should work is by first getting the list of available servers and then letting the user choose one to create the client. Something like:
Dictionary[] servers = Syphon.listServers()
client = new SyphonClient(this, servers[0]);I was looking at the implementation of Simple Client, and the server selection appears to be done in the setSelectedServerDescriptions method. But things are not entirely clear to me. Where is setSelectedServerDescriptions called from? And how is the descriptions array computed?
3) The Processing client has two ways of getting a frame: one using the getGraphics(), which basically draws the frame texture to an FBO, and the second with the getImage() method, which copies the texture to the image pixels array using glGetTexImage. The first works fine, and it is the fastest because there are no CPU-GPU copies involved, however the second doesn’t. The glGetTexImage call just returns a buffer filled with zeros. Any ideas?
4) When I close a sketch with a running server, I get this error:
2012-02-21 17:49:19.952 java[3808:7703] *** __NSAutoreleaseNoPool(): Object 0x1020a5fb0 of class NSCFDictionary autoreleased with no pool in place – just leaking
I don’t create any dictionaries in the native code of the server class, so what could it be the reason for this error?
Thanks!
I’m testing on Lion now, where the new client functionality doesn’t seem to work, while it does on Snow Leopard. The Processing client does not connect to the running Syphon server, without giving any error messages.
Most likely this is a glitch in my code, but just to make sure, is there any issue I need to be aware on Lion?
It is working!
I will clean up the code and examples and upload a new version of the Processing lib.
Actually, I was making a very silly error: calling the newFrameDataForContext() method from a thread different from the animation thread (where Processing’s opengl context is created), which resulted in getting nil every time I called [client newFrameImageForContext:CGLGetCurrentContext()] in native code…
Doing all the calls from draw() results in valid id, width and height… I think we are close to having the client working 🙂
Once I get this part working, I will look at replacing SyphonNameboundClient, as you suggest.
I left the client application running for a while, say 20 minutes, and it always gave name=0, width = 0, height = 0. However, it knows that there is a server sending out frames, because the hasNewFrame method returns true (I tried the client without any syphon server running, and never got any new frame notification, meaning that at least the notifications are not bogus).
Will look at the SyphonImage issues later.
hey guys, I made some progress with the client side in JSyphon.
To avoid writing a JNFTypeCoercion protocol to convert the native SyphonImage class to the Java counterpart, I just return the texture id, width and height in a dictionary with (string, int) key-value pairs.
I managed to get a notification in Processing when a new frame is available in the client, so things look promising, but when I retrieve the dictionary, all the values are zero.
I committed all the changes to the repo. Just in case, here is the native code I added to return the dictionary with the image information:
JNIEXPORT jobject JNICALL Java_jsyphon_JSyphonClient_newFrameDataForContext(JNIEnv * env, jobject jobj)
{
jobject imgdata = nil;NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
JNF_COCOA_ENTER(env);[(SyphonNameboundClient*)mClient lockClient];
SyphonClient *client = [(SyphonNameboundClient*)mClient client];
SyphonImage* img = [client newFrameImageForContext:CGLGetCurrentContext()];NSSize texSize = [img textureSize];
NSNumber *name = [NSNumber numberWithInt:[img textureName]];
NSNumber *width = [NSNumber numberWithFloat:texSize.width];
NSNumber *height = [NSNumber numberWithFloat:texSize.height];
NSDictionary *dic = [[NSDictionary alloc] initWithObjectsAndKeys:
name, @”name”,
width, @”width”,
height, @”height”,
nil];JNFTypeCoercer* coecer = [JNFDefaultCoercions defaultCoercer];
[JNFDefaultCoercions addMapCoercionTo:coecer];imgdata = [coecer coerceNSObject:dic withEnv:env];
[(SyphonNameboundClient*)mClient unlockClient];
JNF_COCOA_EXIT(env);
[pool drain];return imgdata;
}The dictionary object is passed correctly to Java, but as I said, all the values are set as zero.
My experience with Objective-C and JNI is limited, let me know if you see anything obviously wrong.
ok, I see. I will start with this SyphonNameBoundClient class and try to make it work through JNI.
As a side comment, I just thought that another helper class, i.e: SyphonServerList, that uses the same server announce/update mechanism as in SyphonNameBoundClient but just to keep an list of up-to-date servers names, could be useful in order to implement in the Processing library a static method such as String[] SyphonClient.listServers().
Hey guys, I finally managed to return to the Syphon code. After inspecting the simple server/client apps, it seems to me that one missing binding in the JSyphon wrapper is for the SyphonServerDirectory functionality, so the list of available servers can be queried before creating the client. I will start with this, and see if I can add a working getAvailableServers method to JSyphonClient that returns a dictionary of the currently available servers.
Just to understand a little better how the client works, first thing it should do is to retrieve a list with the running servers, right? is this what JSyphonClient.serverDescription() is supposed to return?
yes, you can add me as a committer, I think is good idea. Perhaps the Processing library could be just hosted in the syphon repo?
I also agree about making the Processing library more specific. We will figure out the details of the API as we move along. So far, things look very good. Thanks for all your work!
Ok, I got everything running!
The Processing library is here:
http://interfaze.info/files/syphon/Syphon-0.0.1.zip
However, it only works with the latest revision from Processing trunk 🙂
I also would like to contribute a small ant build file that generates the jsyphon jar file, discarding the test files. You can include it in the syphon repo if you want.
Cheers!
