#1

hello dears,
right after receiving help as for the 1.4 serialosc download, i’m back with trouble about it (:

i’ve been working on a patch on my very decent iMac (yosemite & el capitan both went well) for the better part of the past month and everything had been good. now i’ve ported the patch to my macbook pro (running 10.8.5) and i get massive lagging in OSC communication. i can verify that my patch-performance doesn’t seem to be the bottleneck: did an [uzi] test, setting all 256 pads of my monome in an isolated patch and while the max-internal execution takes roughly 2ms, the pads only slowly and sequentially light up within no less than ~1 seconds.

any clue what this is?
video showing LEDS light up

#2

(soft bump here: bump bump)

#3

i haven’t seen this, but i can imagine how apple could’ve introduced something that clogs it up.

just to be sure it’s not on our end, can you install reserialosc 1.2 and see if the problem persists? 1.4 will easily reinstall back over the top.

#4

hello tehn,
thanks as always for helping out! – the problem persists under serialosc 1.2

…just to check that i did everything right:

  1. uninstalled serialosc 1.4 by deleting library/application
    support/monome & library/launchagents/org.monome.serialosc.plist
    because i found no uninstaller and neither did “rm
    /usr/local/bin/serialosc” nor “rm /usr/local/bin/serialoscd” find
    any files
  2. restarted
  3. reinstalled serialosc 1.2 via https://github.com/monome/install/releases/tag/v1.1
  4. restarted
  5. ran the test-patch posted above
  6. edit: 3 instances of serialoscd are running in activity monitor (…recalling that this is normal)
#5

maybe js is causing bottleneck? u may want to try the ‘serialosc-old.maxpat’, which doesn’t use js, and see if that helps.

#6

thanks @elquinto… unfortunately not working, either. mhmh

#7

just to point this out (though obviously the bottleneck is still a problem)

it’s incredibly inefficient to update a full display of LEDs with 256 OSC messages. it’s much better to use a /map message, which reduces the total payload substantially, plus reduces the negotiation of the system with individual packets vs. a couple large packets.

i’ll try to dig up some old optimization tutorials, but let me know if this makes sense at first glance. do your patches use any optimization? also, the /all OSC commands are also helpful.

but clearly we need to figure out what’s changed in the OS to create this lag.

#8

thanks for the reminder – i am getting behind optimization step by step (being a relatively new user). i’ve read up on it and i’m aware, at least (…and the patch above was solely for testing purpose, not the way i’d figure to do it elegantly :)).

how ever, yes, just as you’re pointing out – it does appear to be some OS issue as everything is working flawless on my other mac. hope we can pin it down.

thanks again for your help, guys.

#9

hei folks,

is there any update on my problem? any place i could research to solve it? i’d be gracious!

#10

this may be difficult to pin down quickly. what’s the OS version of your other mac that works fine?

besides the test case presented above, what is your patch doing that requires so many messages? i can suggest a more efficient method likely, to sidestep the OS level issue.