Syphon Server in Processing 3 not working

Home Forums Syphon Syphon Implementations – User Syphon Server in Processing 3 not working

Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
    Posts
  • #59080
    slendro
    Participant

    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

    #59081
    slendro
    Participant

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

    • This reply was modified 5 years, 1 month ago by slendro.
    #59083
    vade
    Keymaster

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

    #59085
    slendro
    Participant

    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

    #59159
    timrolls
    Participant

    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.
    Garbled output
    Tested in Resolume and MadMapper.
    The same sketches in Processing 2 work fine.

    #59163
    kaosbeat
    Participant

    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?

    #59165
    bangnoise
    Keymaster

    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;
    }
    #59170
    Denis
    Participant

    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, 5 months ago by Denis.
    #59172
    vade
    Keymaster

    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.

    #59173
    Denis
    Participant

    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 ?

    #59174
    Denis
    Participant

    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 …

    #59175
    vade
    Keymaster

    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, 5 months ago by vade.
    • This reply was modified 4 years, 5 months ago by vade.
    #59177
    vade
    Keymaster

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

    #59179
    Denis
    Participant

    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 ?

    #59180
    vade
    Keymaster

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

    Maybe something like:

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

Viewing 15 posts - 1 through 15 (of 15 total)
  • You must be logged in to reply to this topic.