[vade]

Sure. You can use a custom Core Image Kernel and set filtering to nearest, and then use a billboard set to ‘Native core image’

This is up to the drawing app to decide if the texture is drawn with filtering at bi-linear or nearest. This is not ‘anti-aliasing’, it more has to do with scaling the texture, and what algorithm is used (drawing a say, 320×240 image to a 1600×1200 output device, clearly, some pixels somewhere have to be duplicated, the filtering determines the method).

QC’s basic renderers assume you want linear. The Core Image workaround from above remedies that assumption.

[vade]

Thank you andres for your help and putting the library together.

I’ve added you as a committer in the http://code.google.com/p/syphon-implementations/

I’ve made a top level “Processing” folder along side the other implementations, so you can put the library there. Add a readme if you want and make sure to put yourself in the credits!

Happy hacking, and thanks again! Let me know if you end up needed to mess with the JSyphon JNI shit, just so we can communicate. You can ping me at v a d e [at] v a d e [dot] i n f o if you need to.

[vade]

Oh, one last thing, the JSyphon java library will eventually have objects for clients and servers, so I would suggest that the Processing library be more specific, so creating a SyphonServer object for sending, and a SyphonClient object for receiving, etc, would be helpful for keeping the API more readable and conceptually sound. We can totally hammer this out though once we get that functionality actually working 🙂

[vade]

Oh, and thanks for the zip too, btw. How do you suggest we roll this into the SVN, organizationally speaking? Do you want SVN access as a committer so you can help handle the processing library and Java side, if thats would be something of interest?

[vade]

Oh awesome. So you can send a PImage now, and the Syphon java class will handle sending that to Syphon as a texture? Very cool. I got it working in 1.2.1 using the PGraphics object to get a GL handle and manually read a texture from the screen, like so:

// OpenGL
import javax.media.opengl.*;
import processing.opengl.*;

// Syphon
import jsyphon.*;

PGraphicsOpenGL pgl;

float a;

JSyphonServer mySyphon;

void setup()
{
  size(800, 600, OPENGL);
  mySyphon = new JSyphonServer();
  mySyphon.test();
  mySyphon.initWithName("Syphon - Processing");

  // get an OpenGL handle
  pgl = (PGraphicsOpenGL) g;

  // add shutdown and close handlers
/*  Runtime.getRuntime().addShutdownHook(new Thread(new Runnable()
  {
    public void run()
    {
      ohGodStop();
    }
 }));
 */
}

void draw()
{
  background(255);

  GL gl = pgl.beginGL();

  gl.glColor4f(0.7, 0.7, 0.7, 0.8);
  gl.glTranslatef(width/2, height/2, 0);
  gl.glRotatef(a, 1, 0, 0);
  gl.glRotatef(a*2, 0, 1, 0);
  gl.glRectf(-200, -200, 200, 200);
  gl.glRotatef(90, 1, 0, 0);
  gl.glRectf(-200, -200, 200, 200);

  // copy to texture, to send to Syphon.
  int[] texID = new int[1];
  gl.glEnable(gl.GL_TEXTURE_RECTANGLE_EXT);
  gl.glGenTextures(1, texID, 0);
  gl.glBindTexture(gl.GL_TEXTURE_RECTANGLE_EXT, texID[0]);
  gl.glTexImage2D(gl.GL_TEXTURE_RECTANGLE_EXT, 0, gl.GL_RGBA8, width, height, 0, gl.GL_RGBA, gl.GL_UNSIGNED_BYTE, null);  

  gl.glCopyTexSubImage2D(gl.GL_TEXTURE_RECTANGLE_EXT, 0,0, 0, 0, 0, width, height); 

  mySyphon.publishFrameTexture(texID[0], gl.GL_TEXTURE_RECTANGLE_EXT, 0, 0, width, height, width, height, false); 

  gl.glDeleteTextures(1, texID, 0);   

  pgl.endGL();

  a += 0.5;
}

[vade]

Here is a screenshot. I need to get Processing talking to native OpenGL, so I can get Raw texture IDs.

View post on imgur.com

I will upload this to SVN later this evening, maybe tomorrow, as I have some pressing engagements shortly, however this is great news 🙂

[vade]

I have it working.

I had to remove the namespace codeanticode, and re-compile the class files which I exported as a jar from eclipse.

I then placed that jsyphon.jar (containing only the Syphon stuff, no test, or utils since they are unused for now) in to

/MySketch/libraries/jsyphon/library/:

[vade]

I think I see part of the issue.

1) I had a bug with the XCode script, that accidentally flattened out the Syphon.framework and resolved aliases (a bad flag)

2) Make sure you compile libJSyphon.dylib as release, so you get a universal library

3) I need to follow my own advice and remove PPC architectures from libJSyphon XCode build process.

Im in the process of updating SVN to fix these issues. Now that the build is semi-worked out, I do think its loading the dylib. Im not quite sure where to go from here, but i’ve found a few threads regarding this on Apples dev site (one specifically mentioning processing). Need to do some more debugging.

[vade]

You Syphon framework does not contain links, but multiple versions of the binary.

Yours:

Proper framework

This is the Processing library? Do I just make a new sketch and place these in the Libraries folder for Processing, and attempt to import it ?

[vade]

Edit: Oh, wait a second. Are you putting the Syphon.framework in to a set of folders called /libraries/Syphon.framework/Versions/A

Basically, the libJSyphon.dylib needs to be at the same level as the compiled out (from XCode) Syphon.framework, so you have 2 files like so :

Did you get the Syphon-Framework SVN project checked out and compiled, so you have the latest Syphon.framework, and you can if you have the paths set up properly, link the JSyphon XCode project to automatically build the Syphon-Framework project by enusing the paths are set up, so that your top level Syphon-Implementations check out is at the same folder as the top level Syphon-Framework check out, like so:

[vade]

Are you sure you are able to properly load with System.loadLibrary(“JSyphon”) the libJSyphon.dylib ? What are the Java class paths you have – do they match the path you quote above?

The ServerTest.java LWJGL test app has a print statement to help debug the library load issues, and I believe Eclipse manually adds the library paths when you edit the Project GUI (The other JSyphon dev, Skye Book helped me on that point, so I am admittedly a bit out of my element here).

Perhaps Eclipse is doing something overly intelligent, or coincidental, because of how it has paths set up? Perhaps @loader_path matches ones of the Java library paths (so that both @loader_path and Eclipse look in the same path – and perhaps Processing for some reason, has @loader_path pointing somewhere else – although, @loader_path realllyyy ought to be relative to the libJSyphon.dylib).

Isnt this fun?

Are you certain the libJSyphon.dylib is being loaded? Try editing the JSyphonServer class and attempt to log in the constructor, and see if it that works?

Im also new to JNI development, so bare with me 🙂

[vade]

http://forums.v002.info/topic.php?id=41&replies=12#post-383

[vade]

A very very early proof of concept Syphon <-> LWJGL JNI bridge is in the Syphon Implementations, under “JSyphon”. Heavy work in progress, but stay tuned.

[vade]

I think Open Frameworks has DMX support, have you searched the OF forums for native DMX solutions for OF?

[vade]

We have released a beta of a realtime Quicktime Recording app called “Syphon Recorder”, you can download the latest preview of it here:

http://bit.ly/h1cLS5

And follow the existing thread you may have missed:

http://forums.v002.info/topic.php?id=66

Additionally, if you have, or want commercial software support, Boinx TV just released a small article discussing implementing Syphon in Boinx TV here:

http://www.boinx.com/chronicles/2011/3/30/record-your-own-vj-session-with-boinxtv/

Hopefully one of the solutions suits your needs.

[vade]

Er, Yes. What part of Requires 10.6 is ambiguous? The 10.6 requirement is stated in the Readme by the way…

[vade]

First thing I notice is that you want to clear *after* you mScreenSyphon.bindToDrawFrameOfSize, since that call binds an FBO, and that FBO ought to be cleared.

Im not sure what I ought to be seeing as far as imagery is concerned though. You are setting the matrixWindow (not sure what that corresponds to in GL terms, the viewport?) to the window size of your app, but the FBO’s extent is the crop-rect. Could that be part of the issue?

Are you getting an image that is the same size as you are specifying in cropRect? The newest Simple Client / Simple Server in SVN gives you the image size, so you can debug easier. Are you using the latest public download of Syphon, or the SVN source of the framework and implementations?

[vade]

Awesome. Im glad its starting to sort itself out. Definitely let us know what you end up making with Syphon. Always curious to know what people are doing with it.

[vade]

Yes, Frameworks are an Obj-C/Cocoa-ism and are Mac Only. We provide Syphon as a framework because Syphon is Mac Only, and leverages many Obj-C and Mac-only technologies. Frameworks offer much improved linking over static libraries as they:

a) Provide versioning. If we put out a new Syphon framework with new features, your old calls will still work because the framework will include an older version of the library that you’ve linked against and used. Static .a libraries can’t do that to my knowledge.

b) Provide included headers and resources that the framework needs, such as nib file, images, etc that are used by the framework.

c) Syphon leverages Obj-C and existing Cocoa frameworks included on Mac OS X, so even if you get a .a out of it, your application will still need to link to other Obj-C frameworks.

I highly recommend finding a way to link against the frameworks (You can use GCC compiler flags on Mac OS X “-framework Syphon” for example)

Check out the first few pages here:

http://developer.apple.com/tools/gcc_overview.html

I am very hesitant to provide a .a, only because of the aforementioned issues and future proofing problems, and it seems to be not directly solving your issue. Also, im not even sure its possible considering we require linking against other frameworks, so its kind of moot, no?

Edit: that said, you might be able to download the Syphon-framework code and edit the XCode project to output a .dylib or .a for the target. Im honestly not super familiar. Check http://code.google.com/p/syphon-framework/ for the most up to date Syphon Framework source and project files.

[vade]

Im not familiar with Eclipse CDT at all, but it seems as though other people using Eclipse have had similar questions.

Does Eclipse also provide compilation, linker and target info? Ie, is it just a text editor with syntax highlighting, or does it allow you to specify compiler and linker options?

If the latter, you ought to be able to specify linker flags to link the the Syphon.Framework and also have search path setups for compilation so it finds the headers.

I have no idea about Eclipse, but any fully fledge Mac compatible IDE should let you use arbitrary frameworks and link to them.

A quick google search brought up someone with similar questions:

http://stackoverflow.com/questions/5085992/mac-os-x-eclipse-c-how-to-connect-frameworks-to-environment

With no answers. Any reason you are using Eclipse and *not* XCode?

[Author]

Posts