Syphon Server in Processing 3 not working

[slendro]

Hello:

I’m moving my work to the new Processing 3, and I’ve found that Syphon Server is not working correctly, at least on my system. I’m confident the issue is not my code, as this problem occurs also with the examples included with the most recent version of Syphon for Processing.

My code is using Syphon for Processing, v2.0-RC2 to read with Syphon Recorder (13), though I have also tried reading Syphon with Max 6, with the same problem happening.

Below you will find the messages pertaining to Syphon that I get on Console.

The image I receive in Syphon Recorder seems not to be from the sketch I’m running but a chopped version of the Processing coding window. The same thing happens both with my code and with the provided examples.

I will also attach a screen capture from Syphon Recorder so you can see what I’m getting.

Thanks for your help

Pablo Silva

Mac Pro 2008, NVIDIA GeForce GT 120 512 MB, MacOS 10.8.5, Processing 3.0, Syphon for Processing, v2.0-RC2, Syphon Recorder 13

===========Console Messages=========
2015-10-18 10:19:30.283 java[468:c913] SYPHON DEBUG: SyphonServerConnectionManager: Start Connection
2015-10-18 10:19:30.284 java[468:c913] SYPHON DEBUG: SyphonServerConnectionManager: Created connection with UUID: info.v002.Syphon.85CDCDEC-593D-4502-B393-BE0076AA6B7C
OpenGL error 1282 at top endDraw(): invalid operation
2015-10-18 10:19:33.743 java[468:1007] SYPHON DEBUG: SyphonServerConnectionManager: Add info client: info.v002.Syphon.FDBE3C9C-2333-46D4-A64C-AF495CC091C9
2015-10-18 10:19:33.744 java[468:d203] SYPHON DEBUG: SyphonServerConnectionManager: Adding frame client: info.v002.Syphon.FDBE3C9C-2333-46D4-A64C-AF495CC091C9
2015-10-18 10:19:38.831 java[468:1007] SYPHON DEBUG: SyphonServerConnectionManager: Removing frame client: info.v002.Syphon.FDBE3C9C-2333-46D4-A64C-AF495CC091C9
2015-10-18 10:19:38.832 java[468:1007] SYPHON DEBUG: SyphonServerConnectionManager: Remove info client: info.v002.Syphon.FDBE3C9C-2333-46D4-A64C-AF495CC091C9
2015-10-18 10:19:40.801 java[468:1007] SYPHON DEBUG: SyphonServerConnectionManager: Add info client: info.v002.Syphon.4F7EA8C4-B2EC-48A1-BEB9-0D3F3C23AEFE
2015-10-18 10:19:40.802 java[468:d303] SYPHON DEBUG: SyphonServerConnectionManager: Adding frame client: info.v002.Syphon.4F7EA8C4-B2EC-48A1-BEB9-0D3F3C23AEFE

[slendro]

Hmm… How can I upload an image to this? No luck with dragging or the ‘img’ button…

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

[vade]

Please use the search – there are recent threads on Processing 3.0 that have the info you need 🙂

[slendro]

Thanks vade:

I did use search before posting, but didn’t find anything directly related to my problem. I must have missed something, would you mind pointing me to the right threads?

Thanks

[timrolls]

Does anyone have a solution to Processing 3 + syphon?
This is the only thread related to Processing that’s newer than 2012.

Using syphon server (library ver. 2.0RC2) in Processing 3, my output over syphon is always a single, garbled frame.

Tested in Resolume and MadMapper.
The same sketches in Processing 2 work fine.

[kaosbeat]

I have the same problem
I’m trying to get Syphon Processing working with quil. Using the latest release from Syphon Server, knowing that the latest quil uses processing 3 and figuring this could be related, I downgraded to the latest processing syphon v2 release and downgraded quil to 2.1.0 and it magically works.

So upgrading to latest quil is impossible
upgrading to latest processing syphon as well

more specifically I think it has to be related to

OpenGL error 1282 at top endDraw(): invalid operation

could it be some dependency is not loaded?

[bangnoise]

There is example code as part of Syphon for Processing. You will see it selects the JOGL profile – Syphon doesn’t yet support OpenGL 3+.

void settings() {
  size(480, 340, P3D);
  PJOGL.profile = 1;
}

[Denis]

I try to send frames from processing to resolume, I have the same problem as guys above.

void settings() {
  size(480, 340, P3D);
  PJOGL.profile = 1;
}

Thats code solve problem, but … the resolution of generate image looks worst.

Without using PJOGL: https://drive.google.com/file/d/0B8ynmra1gIBNNGpsREhOdE9JQ2s/view

With using PJOGL:
https://drive.google.com/file/d/0B8ynmra1gIBNVTZ2VUdpWURBT2c/view

I don’t now why it’s happend ? Do you have any solution ?

This is source code:

ArrayList history = new ArrayList();
float dist = 80;
  
void setup() {
  size(1280, 720);
  background(0);
  stroke(255);
  strokeWeight(.1);
  noFill();

}
void draw() {
  

}
void mouseDragged() {
  
  PVector d = new PVector(mouseX, mouseY, 0);
  history.add(0, d);
  

  
  for (int p=0; p<history.size (); p++) {
    PVector v = (PVector) history.get(p);
    float join = p/history.size() + d.dist(v)/dist;
    if (join < random(2) ) {
  
      line(d.x, d.y, v.x, v.y);

    }

  }
}
  
void keyPressed() {
  if (key == 'x') {
    background(0);
    history.clear();
  }
  if (key == 's') {
    saveFrame( "######.tiff");
  }
}

• This reply was modified 4 years, 9 months ago by Denis.

[vade]

I’m unsure, but I suspect its the behavior of not constantly calling background – which calls glClear –

try calling clear every frame as a test to isolate? If that works, You might need to then draw into a frame buffer, then next draw, draw the frame buffer you’ve captured, then draw your new lines, and repeat.

Clearing behavior can change subtly depending the renderer settings, if one path clears the depth buffer or just the color, etc etc.

[Denis]

Thank you for reply, but I’m beginner processing user, and I think I don’t get it clearly. I try to search some information about “glClear”, but I think it’s to complicated to me. Can you write for me some example of using this function, that I can experiment with it ?

[Denis]

Also I noticed when I set hight value of “strokeWeight” it start working corectly, the lines are drawing (as line, not dots), but it still look much worse compared with code where I don’t use:

void settings() {
  size(480, 340, P3D);
  PJOGL.profile = 1;
}

maybe it is due to the fact than syphon still don’t support OpenGL3+ ? and there is no sense to fight with it ? I don’t really now …

[vade]

What Im saying is, PJOGL profile 1, versus the new, 2, or whatever it is, actually behind the scenes renders differently. This is what you are seeing.

Your code does not call background every frame That choice exhibits different behavior between PJOGL versions.

What this means in practice behind the scenes is don’t clear your color buffer, and or your depth buffer. The result of how PJOGL 1 vs 2’s compositing, blend modes, alpha blending handling and default state, and what buffers are erased when you *do* call clear are all completely 100% dependent on whatever processing’s implementation of background is behind the scenes, and that background call might actually change behavior between versions of PJOGL that you use.

in other words, you don’t have control.

You can lean on the processing forums for ways to draw into frame buffers or draw into image objects efficiently without clearing them that works across renderers’s and doesnt rely on ‘not clearing’ your main drawing target.

In essence, I’m pretty sure you are relying behavior not guaranteed by processing’s compositing setup.

I’d be very surprised if this has ANYTHING to do with Syphon.

• This reply was modified 4 years, 9 months ago by vade.
• This reply was modified 4 years, 9 months ago by vade.

[vade]

For the record, I’ve seen this happen in Jitter’s OpenGL path too.

[Denis]

OK. If PJOGL couse this problem, maybe is the other way to make it work (send frames from processing to syphon) without using PJOGL profile ?

[vade]

Try changing your drawing code like i suggested. draw to an offscreen buffer.

Maybe something like:

https://processing.org/discourse/beta/num_1168241817.html

[Author]

Posts