Final 2.0 release

[codeanticode]

@vade and @bangnoise: I just uploaded 1.0-RC2 through the releases section on the GitHub repo, and marked the RC1 on the googlecode page as deprecated.

After a final round of testing/debugging, the next release should be 1.0 final. A few things:

• I'm getting a lot of debug messages from syphon after updating the submodules, i.e.:

2014-06-07 12:47:41.524 java[10617:d07] SYPHON DEBUG: SyphonServer: Got Discovery Request 2014-06-07 12:47:41.541 java[10619:d07] SYPHON DEBUG: SyphonClientConnectionManager: Registering for info updates 2014-06-07 12:47:41.542 java[10617:d07] SYPHON DEBUG: SyphonServerConnectionManager: Add info client: info.v002.Syphon.FAE0FFEC-8775-40FE-825F-714AD1B8F700

• We need to figure how the packaging for the final release so it can be downloaded through the Library manager in the PDE
• The Processing_2_0 folder is not needed as there is no 1.x branch, and the master should work for future releases of Processing.

[bangnoise]

Those debug messages come from a debug build and won't be present in your distribution if you used Xcode's Archive command to create it.

I have no experience of Processing's Library Manager - is that something you know a bit about already?

Feel free to rearrange the repo if you want to get rid of the Processing_2_0 folder

[bangnoise]

also thanks for your work!

and I'm updating the link on the Syphon webpage to point to the releases page here

[codeanticode]

again forgot about the archive option, sorry about that!

Anyways, I will figure out the library packaging to make it work through the PDE's manager, and will let you know when 1.0 final is ready.

[codeanticode]

When I use the Archive command, I get the following error:

"Unable to run command 'PBXCp Syphon.framework' - this target might include its own product."

(build is fine though). Am I missing something?

[bangnoise]

Rings a bell as an annoying Xcode bug - I'll take a look later tonight

On 9 June 2014 16:52, codeanticode notifications@github.com wrote:

When I use the Archive command, I get the following error:

"Unable to run command 'PBXCp Syphon.framework' - this target might include its own product."

(build is fine though). Am I missing something?

— Reply to this email directly or view it on GitHub https://github.com/Syphon/Processing/issues/13#issuecomment-45506757.

[codeanticode]

Ok, thanks. I'm using Xcode 5.1.1 on OSX 10.9.3

[bangnoise]

Bit late, but archive builds of Syphon.framework work for me with current Xcode

[codeanticode]

No worries, I haven't been doing work with the Syphon library lately, but I tested it last week with the most recent alpha release of Processing 3.0 and it works :-)

I will try to get some time over the summer to package the final 1.0 release.

[codeanticode]

bumped the version number to 2.0 for version of the library compatible with Processing 3.

The last release compatible with 2 stays at 1.0-RC3 :-)

[knupel]

When we download the last release, the file is Processing-Master. I change the name for Syphon but that's don't work ! Plus the link from Processing 3.0b5 library manager is broken.

[codeanticode]

The new release is not yet ready, and haven't had time to update the download link. Please wait until beta6 is available.

Otherwise, you would need to compile the library yourself.

[djkayip]

Thank you very much for your work! I've been enjoying using it, and really appreciate it. I've got a few questions about the library. Seems like Syphon library is not working with Pixel flow by Thomas. I think that's something to do with PJOGL.profile = 1. Pixel flow works with other profile like 2 and 3, but doesn't work with 1.

could you let me know any clue to sort out this issue?

[vade]

Please see https://github.com/Syphon/Syphon-Framework/issues/13 and core profile branch.

[djkayip]

Thank you Vade! I'm a visual Artist who can do coding. So not quite familiar with this. Could you be more specific about what to do with core profile branch? just a little more clue. the https://github.com/insidMWM/Syphon-OpenGL-3.2-core/

That would be great help,as my performance is looming.

[vade]

Wait for someone to fix processing to use it :)

Sent from my iPhone

On Sep 3, 2017, at 9:37 PM, djkayip notifications@github.com wrote:

Thank you Vade! I'm a visual Artist who can do coding. So not quite familiar with this. Could you be more specific about what to do with core profile branch? just a little more clue. the https://github.com/insidMWM/Syphon-OpenGL-3.2-core/

That would be great help,as my performance is looming.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[codeanticode]

Oh cool! I wasn't following Syphon updates very closely, but am very happy to know that GL 3 and 4 are finally supported. This is a good reason to make a new release of the Processing library. Thanks for the heads up.

[codeanticode]

@vade I built a version of Syphon incorporating the changes and additions from the OpenGL-3.2 core repository, and bundled it with the Syphon library.

I got this error when try to run the Processing sketch with profile 2+ and the renderer loads the default shaders:

java.lang.RuntimeException: Cannot validate shader program:
Validation Failed: No vertex array object bound.

I manage to see the first frame of Processing in the simple client, so I'm hopeful this is close. Processing's shaders do not use VAOs since by default it uses the GL2 profile for backwards compatibility. However, I have been able to run geometry and tessellation shaders with GL3 and GL4 profiles, still w/out VAOs.

[vade]

Hey hey @codeanticode - This is great to see your interest! I know we've been slow to adopt GL 3/4 - no ones fault but ours (and the bills we have to pay too haha).

GL 3 / 4 branch is not quite final - it needs some eyes and testing but in theory its working. I imagine we have some gaps. Not to ask you to take on some additional work, but your eyes over the code and perhaps some thoughts on "do's and do nots' " would be really appreciated esp WRT to the Java code.

One major issue is state tracking - which the Core Profile branch does a bit differently, (and optionally with some defines for performance reasons) - we also made some changes to context ownership / share context creation - so there might be some nuance with the Java JNI interface that is now wrong, or has some GL 1.2/2.1 assumptions.

Its been a VERY long time since I've done any Java work so some eyes on it and pointers on what the modern path to developing these sorts of Processing plugins would be helpful too.

Thank you in advance!

[codeanticode]

When you talk about the GL 3/4 branch, are you referring to https://github.com/Syphon/Syphon-Framework/tree/core-profile? Should I be using that instead of the OpenGL-3.2 core repo?

[vade]

Correct! Our official branch. That other branch isn't ours, and theres some nagging bugs the recent Syphon Framework master and our GL branch take like shared context for resource management/disposal, slightly refactored API for clients etc.

[codeanticode]

ok, using the core-profile branch, I get the Processing library to work with any GL profile. But only for sending frames, when trying to use the client, I get this error:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fff92d7813b, pid=52598, tid=0x000000000000f403
#
# JRE version: Java(TM) SE Runtime Environment (8.0_144-b01) (build 1.8.0_144-b01)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.144-b01 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# C  [OpenGL+0xa13b]  GLCDescribePixelFormat+0x11
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

Full log

@djkayip if you just replace the Syphon binary inside the library folder in RC2 with the one here, you should be able to send frames using profile 2+. I tested with a PixelFlow sketch, and it works. But receiving frames will not, until the crash above is solved. I hope this helps as a temporary workaround.

[vade]

Thanks so much for looking into this @codeanticode - great that sending is working! Interesting. What OS Revision are you running on out of curiosity?

[codeanticode]

El Capitan, 10.11.6

[vade]

AH, sorry I was barking up the wrong tree - Im refreshing my memory on the JNI aspect of this, and I believe whats happening is a NULL context is being sent to the client creation - we changed the API in the core profile branch and the JSyphon code needs some love to reflect those updates.

I think all that needs to happen is a context needs to be passed during client creation, not during frame vending via the new NameBoundClient API updated to reflect the SyhonClient context changes:

- (id)initWithContext:(CGLContextObj)context;

Rather than

SyphonNameboundClient* client = [[SyphonNameboundClient alloc] init];

In https://github.com/Syphon/Java/blob/master/JSyphon/native_src/jsyphon_JSyphonClient.m#L20

I suspect thats the issue from a quick perusal. I don't have the Java build setup, so I'm reading code so forgive me If I'm missing something obvious or something totally devious :)

[vade]

Looking at the JNI / JSyphon code the calls to for vending images def need to be tweaked as well as the client creation too:

https://github.com/Syphon/Java/blob/master/JSyphon/native_src/jsyphon_JSyphonClient.m#L131

I'm happy to take a peek at this but it won't be for a day or two. Thank you again very much for looking into this @codeanticode - its very appreciated!

[codeanticode]

ok, thanks for the comments on the API changes. I should be able to give it a try, and will report back!

[vade]

No worries - thanks again for looking into it. You've been a huge help with Syphon!

[codeanticode]

Ok, the changes in the JSyphon client make the trick. I added a new download package, which should be available through the Contribs manager in the PDE shortly.

[vade]

@codeanticode Thank you so so much for taking the time to put that together. The can only imagine the community will be grateful! Much appreciated!

[codeanticode]

You are welcome. Once a few minor issues are figured out (#16, #21, #31, https://github.com/Syphon/Java/issues/4), I could push the final 2.0 release (which has been years in the making :-) )

[vade]

Woo! All the emoji comments! :)

[codeanticode]

After 3 years in the making: https://github.com/Syphon/Processing/releases/tag/2.0 !!

[vade]

Fuck yea!!!!!