Forums > MaxMSP + syphon server = slow

Sep 25 2012 | 11:01 am

Made a very simple patch where a white circle (created with is following a tracked user by use of a Kinect (output comes from OSCeleton). Tested everything and works flawlessly without any major hickups, slowdowns etcetera.

But the output needs to go to Millumin, VPT6 or a sort a like mapping program. So I tried to use Syphon for that. Now I used Syphon before but always with a matrix source and never in combination with an object. Got it working now through a and object but this majorly slows down my patch up to the point that it is consuming almost 50% of my mbp 2.4ghz i7, which is way to much for this patch. I’m pretty new to the side of max.

Anybody any ideas what goes wrong?

-- Pasted Max Patch, click to expand. --

Sep 25 2012 | 12:25 pm

Hi kleurbleur (Marc?),

I should set up syphon on my end to really test but one thing that ‘s wrong for sure is @dim on your This is the dimensions of your gridshape geometry, not the pixel resolution of the texture it outputs. 960×540 is very high. Actually if you look at the ‘dim’ attrui you see it caps at 256×256, which is the max Jitter allows apparently. Try lowering it till you reach the minimum that satisfies your esthetic preferences for the dot.

The pixel resolution of the rendered texture is set in the, which you set at 1920×1080. (Not entirely sure about this but you might have to set jit.window @size 1920 1080 to make the GL context render at that resolution.)

Greetz, Dieter

Sep 25 2012 | 12:50 pm

As dtr mentioned, your texture size is 1920 1010, which could be a bottleneck depending on your video card.

Additionally, you’re banging the object after sending the texture. No need to do that as you’ve got automatic on.

Sep 25 2012 | 12:51 pm

He Dieter! – Goed om je hier te zien, al veel posts van ‘dtr’ gelezen ivm Kinect dingentjes. Jij hebt geprobeerd om een degelijk Kinect object in Max te krijgen was ‘t niet? Goed om te zien dat jij het het bent! :)

Ah, that’s why… as I said, my knowlegde isn’t really what it should be. But as far as I know the jit.window @size has nothing to do with the final render. If I change the @dim in the in output it also changes in, for example, MadMapper.

How I handled it right now is to make a Quartz Composition with published inputs for VDMX, achieving the same effect but than actually controllable from within VDMX and easy OSC integration. Was done in 15min, including checking a tutorial how to integrate qc in vdmx. :)

Sep 25 2012 | 12:55 pm

Thanks Scott and dtr! This fixed the slowness of it all. CPU is now in activity monitor at 15% (Max is using 7 ~ 8% when doing nothing) which is totally doable. All of this btw still, on 1920 1080. :)

Sep 25 2012 | 1:07 pm

Ok, modified the patch after the new gained wisdom :)

-- Pasted Max Patch, click to expand. --

Sep 25 2012 | 10:03 pm

Good work. Your gridshape dim is still really high though. You should be able to get it down to dim 60 2 or so without loosing visual detail. It might not make a difference in this limited test but it can in large GL contexts with lots of objects to render.

Sep 25 2012 | 10:13 pm

Wow, it can be that low. Modified it 2.0!

For people interested, this is the VDMX input capable quartz patch (or is that against the guidelines of Cycling’74?).

Viewing 8 posts - 1 through 8 (of 8 total)

Forums > MaxMSP