monome

Get your LED states onscreen, either as a text message or in something more graphical. Then try to repeat the problem. When an LED gets stuck, you need to know whether the packet got lost over udp, or if there's a timing issue in your app somewhere causing those triggers to fall out of sequence. Those are very different problems with very different solutions.

Also create the smallest patch that replicates the bug and post it here.

Haven't had time to work on this yet, but I'll try and report back this weekend.

----------begin_max5_patcher----------
1196.3oc4ZEziiZCE9bxuBTTOljwOaiMTUUodnG6sdqsphP7jkcSfHfnN6tZ
+uWv1jgLa.LINtLpZzLdrg.euO+8d98ryWmOawlrWDEK79Qu+va1ruNe1L4P
0CLS2e1hCQuDuOpPdaKNHJJh1IVrTcsRwKkxweJJO9Wyyyx+cQQ4S4Io6dpP
T5g79AvC7at8zSGRR2KJkOK7qClcprYTPO5wnx3OT8X96bQboBgXe1ZzROJH
avXdcCDrF48W5OTxVIXx17wUbVyK84rzxznCB4k9kzsQ6Ed+VVZVy0Uu7xOe
TndMKVb94U+QKR9h7B.dMpdzuMed8eVZHgkJ9mJ37c70wjiBO.YGhgfqYBR.
stgAR1A0As3OsokJkS4UIE3pjBpaRATzAkFHa38xJDSYkGmoW5kLBCeP0f1Y
Q2oC6lRuY0P87jMED2RfEq59zDVAB6KrBM.MocfJ7tjvRRsi2jliTNS.E0mp
BnbG5N0kvYU0BO1QenMZU7DeTexCLLsCuF8IqRILjNFieOpA1+OnDfRMmSlH
qB2kuCxVgVaHEkuCInOeGfLwir1Nv5pbgcBrp8jPJdhP5MvJi8eedJ4U1knZ
8WvC6QFAG3OnJAqVAVyEcQBA7aWlr7M+5.YyCftz4zYFa4+NjstLEFQZ7SaE
6Kitx3eR74Qvojg3T.K8FI7fd4T58yotfKMKUPzMVsI1fLAwSiH5ajVgHu20
zxd94pBKTu9UJAvJFtkcMRsDSsjGvUMcDQuWkxlnzcmaeEGM7XgHOIZeVQ75
JqsBGMOqn7c58z4xpmpdD1rbUjcJWEHpBUIFTuJAOYpWsSZArCsDfLmUPScV
oPreTEigGjW.7v6pCN7l4kFOu2YjSiujQrC+cA67S1pTDkvAGDXP4YgScGpe
1ZEnoTLlQK7I+tE5aoiZ.7UI4nJlu+SZfPwS5BWiyNkVJxqpAA4wtdIH9Wke
nClCnhd.n2ibfP7uKcSqRPbj2UzlBatU75vwCrHNgM0C5b5KIiv6ZvDj041P
Y8SK2+xTMs1llhyNbP75wUclm9yz9+o4CrOIUHcNkXfYmS8Rwl5C8JT4XVSz
WsPVzstcR5g2rKNaeVt5UiVG3GDfoKu5+IK.pEIKwijBdy4OKMp5wuj4KxNk
G2Ly1b.uduZVaqJvIIMpLIKs0MIOJhV20GR1tUj1lCOjr8XVkxPihNJQxTPI
OdnIGpp2vBOX.PELRLgw5n975bF.ehJ0gpd1.sCQg06qkCYPvDHQ6.RviAR9
lnzHWLy+vEZbCDZRfOBLAb5Zds1Re7AjPUPs18.eUJZL94d1vTPlXJiPE13k
XfkntSaXIfIAJqO3RWJT7MQnvFGlX3KzIWPtgsNaNJ466nXcNXM4iQdmrwIe
nv56y9741RTYj8QoNMHsLWwAAkrbDmhJlQnh6XTYxDnrz1w3BpTnD0ds.prP
eSO02KIfEJuSe18GeKzj3agtMeASThX2NkiMgmHH2hIi7Xwt00.abTD2sfIA
MAAE0jL0AGWAlQXJb5go2tNwzXE.taWrzDWOv4U9MbhptcpiaTxWAnond5lR
4kDnNXBl+4dNYiZp+dg6x4U1iFSUc917+ETshr8O
-----------end_max5_patcher-----------


Here's as good a place to start as any. Very simple. This is using the serialosc.maxpatch found in the demo arc files, so save the file you paste this into to somewhere with access to said patch. This doesn't exhibit the previously described "bank" behavior, but still has missed messages. It does happen consistently. I've had it happen on small and large deltas. The Max window shows all of the messages as going out. Pipe is not the problem. The behavior occurs with or without it. It's just there to make it easier to track.

----------begin_max5_patcher----------
3166.3oc6ctzaiajEEds8uBBstmf5cQN6xlY27KXPPCZIZaNQhxPhtSmDj+6
CeH5VxQt84lGSNUPAjX2lhh7xOVrN26gEK9y2dyp61+4liqJ9mE+mhat4mu8
lalVz3Bt4zeeypc0ed815iSq1p062sqoqe0Gl+r9lO2Os79GaOVL7e0cEMe9
olCsiqUQ+9h6ZJN97glhcMGOV+PyvZL7G20z18PwgliiqTWSylsCe51ebYq1
87t1tsM8S6R8oEd+9t9is+TyzxLei5Kq69m6WV4kk9Tc+5GG1Ge7Py594iOc
nb3KU3JUi+xqpF+kY3OJ9tSeo1MSGJ6u6+9OzU5Umse6p2MseW8scap21T7u
22se03G+K2d63O9.H85Z9ggs9uBdOUr9w5tGZ9Wsa6aN7agBOMyx5918cmcL
asSGxgwUrPc5Gub7dI5V1CyKp+GepYdarZ0KegqPUq4Lnp05uJTKiuKTOeOM
fhYTdhkCes1sMep4vwgixyB4aV8k3Q8xQZvodIzVhlgyOOrc+5uuYyYMVtY0
ll6w2B6epo6Zq8qw67Z11c9olWuWqeda+Gu9ozK+76qW27le4u.xCs0aWsrJ
Obncy.RGBhK9liKdY2MbUge5Dm+73dZM5pe5Je49862dW8gO0dr8tsMWbNXn
kecW6t59l9143wnd460t6oCsc8WrsZ5pG1FOdb8g8a2dwlZ9S9zU9jMMepcc
yOzto+wos0Wn0E8jcValKtl7hk+0t17UWeV+8EAag57O7hqNMm8Auwoy27Bt
24ht2r6Lsct0YLL0Vs70W48qt5KbQ7+U6V6lkt1l+Ge3OIjZHCoJeoPjpYCo
ZtPZUYPHQMrQTEYDU6DRTKYD0WwEQKcFgD0wFQK4hnwnToIOaDMxEQCURUlh
rQz.YD0HUYpjMh54hnduTkoJ1HpiKh5JEpLEYKEeOYUM4zBUlhrkgumrhlrV
gJSQ1xv2SVMSlfPkoHcY3SVMS5JgJSQ1xv2QVMSZiTkI1xv2QVMSdoBSA1.Z
jSCRsAGHRsrUyjKvoAoBPJaEM47TZPp.hxVQSNGkFjhSTGaEM4rTZPp.hxVQ
SNCkFjJfnrUzjSSoAoBHJaEM4TTZPp.hxVQS1JJMHU.QYqnIaIkFjJfnrU0j
MRoAoBHJaY3aCTZPp.hxVF9VOkFjhSTOaY3acTZPp.hxVF9VKkFjJfnrkgu0
vnAoB.JaI3a0bZPpIn.Qpgtq5UbZPp.jx1k8lJJMHU.QY65dSIkFjJfnrUXu
IRoAoBHJaE1aBTZPp.hxVg8FOkFjJfnrc2PMNJMHU.QYypDikRCREPT1rJwX
nzfTbhZYypDilRCREPT1JZxnnzfTADksZlzUTZPp.hxVMS5RJMHU.QYqlIcj
RCREPT1pYRGXzfTA.ksRlzdNMHU6QGTtF1xdR63zfTbjpYKEeskRCREPT1JC
UanzfTADkMqRzZJMHU.QoSaRQoAoBHJaoOUQo+nK.U+9.ksL7KozdTA.kshP
iT5Np.fR2boCkliJ.nz8vfSo2nB.JcO5MTZMJNPUzM1QozYTA.kt6YGkFiJ.
nzUqDk9hJ.nrUpjhQaQOwSe06ySlJTZddA9Mwo92BNseUb9ghUiSTqm9E7rP
papafS2+9uBdK0Y5hS2kIjTX5ZyzEltKyMovvMjgKNbOMMkBC2xLbgg6xLVJ
LbqxvEFtKSdonvsRkgKLbWlGSggaNcAAv0HSPqxjgKLbWlcSggaNULb3tLQm
BCWWFt3vUKTPKW.LNbWl9SggatHBb3tLSnBC2XFt3lKTITPKWgl.3ZDJnwTE
ZGFN5aFmfTcUiSkud83jNs2NN8n68iSj+933qbBe03KGkfd783ykujQ98etP
GeuSF+t9evIiU8rU75HfK74p.EjKsrDRzpbUfxsj2N+1q68waHSW4VxiS2bQ
1hsjGGt4hrEaIONbyEYK1Rdb3lKxVrk73vMWjsXK4wgatHawVxiC2bQ1hsjG
Gt4aCpXK4ggaLW.rXK4wgatDMwVxiC2bEZhsjGGt4hHDaIONby44J1Rdb3Fo
yRdqYbdN15FmQtsgw4Nda43a4.mZ78wgyL9liw4FeGG4BEt3eCsj2pJQsjOl
SkVpi73WajyjVtg7Fa.ittbBIxMjGmtYOiEaHONby1ZJ1Pdb3lS2Srg73vMa
qoXC4wgaNWLwFxiC2bxXhMjGFt9rslhMjGGtYaMEaHONbyUQH1Pdb3lKhPrg
73vM6YrXC4wgatBMwFxiC2bEZhMjGGt7YHuNLNuZqKGmA3Mpw2UAFy3aUCia
78+hIL9lJxTN9N0xpJt7EAveSLj2nbnFx6yEAJ0Pd7qMx0.J2Pds0fQWatkq
bC4woatsqXC4ggqK6egXC4wga1+BwFxi2sPtJPwFxiC2bUfhMjGGt4p.EaHO
Nby2mNwFxCCWStkqXC4wgatJBwFxi2sPNULwFxiC27c6Prg73cKjSESrg73v
MWDgXC4wgqkNC4UE5BSgsvU3KBEwhxhpwWcSZ83KYLsc78g2kuHj9ahM7ZkB
0FdSdbAH0Fd7qH9+taaSr5M42etyo9yOs.F+xOey4umKmz2Wue2tlt4y++Qh
h4CCn1RWxB06bvVNcD5meCBfb3Zjb39xlY011tliy6yWSfovZ7yuNGNt+4Cq
WN6MECggVhEWFhaZN121U22tu670bLZe0Z9X6lMMcuFM6Z27z9gKZNEhEeGz
4NwQ9XA9oYjazIajmrsVBIKyGuohIZqESpF4iuLgSz14IKysIKyGquIQammr
8sDRVl6RVMzQSRRz14Iathgjk4tzMKWex1NOjrsySVl6R1LtLIaqEcx1ZIjr
JQtjMiKSxxbcxp9GR1JKbIKyMIKy0IaeKgj00BWxpgZRVlqS1bEiIqqEtjMK
WaxxbcxV6eLYibWxp9aSVlqS1qPiIqRjKYU+sIKyUIKyiIakE9zcj4jrLWkr
Znwj00Be5NxbRVlqRVGQiIqqE9zcj4jrLWkr09GS1H2mrp+1jk4pj8JzRT0e
CWAdIbq7oQdrlm.GtQ9zPIkn.GN27owFHQANbwySC1KdB7J3JPmF8NDE3vkT
LMbLHJvgyQb59qSTfi2cXEWANbMbS2ALhBbXI+HWBPUvBPQxDfv6UgrlJvU6
G4R4rBVxORlxIrjejKkSsBtQ9TEp7D43OfeVtz7wehsrbo4i+H3X4RyG+Ypv
wUG43CRdGWZ9AXMeGWZ93CWaGWRm3i+VGWRm3CnRGWRm3iPNGWJm3C4IGWBP
3igEGWBP32rVOWBP32UBOWBPQ39w8bI.Eg6Nzyk.D9iEmgqlJ3OmSFtZpfOf
9Mj0TAtWECW4p3f6UwvUtJ3iUXCW4pfOn3LbkqB9nV0vk8D3COKCWIYgOdar
bkjE9.nvxkxoGNsVKWJmdXkSKWJmdXkSKWJmdXkSKWJmd39wsbobhOMxY3p6
P74ELMWBP3SzSZxxUAVxWyUtJ3CHaMYWbBK.o4p6P7gLolKAH7YOVMWR93SZ
OZtRxBe1oPyUZs3OdpZxTNgKjPwkxI9DvlhKkS7YHQEWJm3SgoJtTNwmQpUj
c6BmZ4FfhbEUC8cObjGKoJvm8qGIv8kj87cf2JWSXjqAh7qLj49qOvMHANis
UrHAdjv.2gD3ABCbORf6ILvQ5O7JiR9+5C7HRfaILvKQBbCgAdERfSo.Dh1Y
khwHGQ6rjQsSMh3YIihmZD0yRFEgzHxmkL1mnFQ+rjq9VhnNZEq3KtQ5WIF4
KtQ5UIF3KtQ5SI53KtQ5QIZ3KtQ5OIRX+IP9pn3KtQxFOPX+fHIiGJ4KtQxE
OPX+2PohGHrCbnLwCdBCbDIy.gROP4gGrDF3HhlABEMgxBOn461Qfzohuhva
iBRbG4KtQ5RwG3KtQ5Qw64KtQ5Pw63KtQ5Owa4KtgtIgF9hajrv8D1+MRV3d
BuM3HYg6XT2AQvzURXfinX5HTwDJKbGgRlPYg6HTyDJKbGghOPYg6L7M1Zfl
GOUDNlfPhaKewMRWJFGewMROJFOewMRGJVBamfzehUyWbijEtgvwXHRV3l.e
wMRV31HewMRV3VB4MTV3VB6HDJKbKgJOXYgSXWgXYgyXtUPhlUDF3Ppl+Qp9
bZgCGA2NGW0epYyGG1MMq6+Xce+g16dtu43xAwoifUOrc+c0amNFaNzUua5H
Y0pS67g.+95m21+w6220ee87w4Rjs5MW3w1eZZgZy2nt1V5k8y2dnsd6U2YW
aSbku5segBS+bhC+xs+O.jLvA+C
-----------end_max5_patcher-----------


I also added this to make sure no redundant messages were being sent during fast movements.

So to clarify what the goal is... I'm trying to prevent dangling messages, on or off. When I send a pair of ons and offs, I want them both to happen. If that means controlling the rate at which messages send, that's fine. I just want to find a consistent, responsive, and reliable solution to this.

Don't link the output of [t i] to two integers. use [t i i] for that. create as many outlets as you need, and only use one connection for each of them.

That's not a casual nitpicky complaint. It's what [t] is for, and you're circumventing the very point of it.

...which is to prevent the sort of timing problems that you're fighting.

http://www.youtube.com/watch?v=S92ljjQtsfo


This is working for me. You?


----------begin_max5_patcher----------
1255.3oc0Z9ziahCE.+bpT+Nfh1iYxvyFiMUUUpG1i8Vusa0JBwSJaSfHfnc
Zq1u6KXCYHoPhIyCSVMZpqMdHO+i2+I+7suY17UoOKym67Nm+vY1reVtxL0Z
UqLqYgYy2E9bz1vb0FmmH+mzU+87E0WqP9bgZ8Bm3peNdgmRSJRB2IUW7iYw
gaOdojC6hS1JKT2PnY030psVdyef1dqoGJZ1Ks8MOO9GpaNPV51rtduEeeuT
enlGmTLewICNeoYy6CKh9Zbxl+JSFUn2uGq7d434pG7q9Wh6RWmun9S9229l
pwxgEFiqcx77vMxekWOFlE86YYoYeVlW7XVob7Xtrvw042.Gf0CFSVGtU57o
zjztgIoCXx86glvfo4kgGg6pvlPMPH7pAP7pvWeZa6i2Kc.WLwDyRXpVGion
jOffNVuPJSo2eSHpKyRde1ktWCQcos3o..CzJM7QjCEWvwzsvAOud3.403e5
xJMZ9vUpKTxR1z3XBSCtR+D10hq1uDDLh9kxcNEewIHp2AdbDM.0To19CzVi
ikNkmiGhZNDvRJN9TEaBTZLZG1iU7rvugHf.e6BHNCM2RVBP1JXOvBvlP8Zj
4hp6YfZYDosxnhQ06bamyOjIwz4ruOhNmqMrpiUQoiX1QYkhprL7N3PbnHBD
QeAqXCWAZwY+ZhBEgpRVBb89+H7XSD7pSzzdr6z7kjIQOtVtsHri0+l76XRX
OzZxvPHK3orkobwXRVrxB0sqrurUV67WJLDmzSWo9TjYCHH30zQ5TWXUXxli
iubFSe5oxBoz66A8y+G7IUmnieHMOXxkUMLKMOZY4AnTpmeUNw0QOAtdn8cM
LaScO9Ns1t4iRo1tHZiRwSW6pUXCLcs0rlRrGy9Q.XBIW6Ao.lsXTtb6MSoN
qYL.sd1zXdaDpH7Qu8VniJtkQUiomEX06wsFo.qa54RG8Rs+.tLhaee3HBo9
aoEEQHQ8rUVUfuNCAcCIF02QST5gjBYVY0Qtk0ydizh0Esn8Ucj2s1.9leMr
Q703Cfw702DtJGyzDn91yPrlRD9nmmvgeDiocHkiVUgmTEv.Tsz9vP4kOGkt
amr0q.7H09yDS943e213DoxZVcnCdkJkq1DktMMSencWJXBAwaQm+uSpiocw
6tH1qMcuNH5Vt4oeI1D+fNHuVVT337u0Dp6a0EN64Qd5grnFUhiNubZcrVWV
JVbRXQbZR6sc5l9Z750xjSNg6hWuOsTopVRtjZh4BW4mJ4phVUvJGXHBm.pB
E6UGtolzmLipe0lfvqZmpYnchtJr4rIi1vUkM+gJa9pVK3Qopze3AJzWMCEg
t5keecotJquIfnBirsTGA6Kbm+w1C4BtiENURDSfzctQPOlJSiSS0Wjg6Voi
alIw4mAKIcfQNS7mFsNhQ1qSSnCWyLWYCMRMNRG4dV5HbijNxznyEXjvMQVq
FQNxzD6GLhbjoI75uD3rOSB9DIdbysXuWSqCFbTBluJEYltBD865t8j5u1NL
QGSTM0fqZwnZBdGTvnC5f7ax4K4utSpv+3DbrVMxdf.SRDBgQVCvfMFfxRyd
4w.vZ+bndVMtq2IhZVbizrFbDYPDzV05hmIAAYcHybKPmDcHvDYSzaknvnpe
aTwdhIxYuQMXPL3.kDptkpDsO6ZSwpY1rJP02g661JnwP5pVnb3+.AXx8KB
-----------end_max5_patcher-----------

Also, your uzi/counter thing is another point where timing is less predictable. You don't know how long it will take those instructions to process in relation to the commands surrounding it, so you should probably account for that by storing the output of your counter, and using the bang from your uzi's second outlet to send it when ready.

...or use an [accum] instead, and maybe have serialOSC update a range of LEDs concurrently rather than setting one at a time in such rapid succession.



Also, try changing your [pipe 10] to a [pipe 250]. Not for troubleshooting, but because it's fun and inspiring to play with. =)

First off, there should be no problem with [ t i ]. As max processes top right to bottom left, [ t i i ] and [ t i ] are effectively identical in this patch. I'm just using [ t i ] to repeat the input. That's not a problem, it just something I do sometimes for organization.

And yes, even with that change I get the same problem: quick movements often leave on lights. If you read the max output, every message is sent. Ergo, counter also seems not to be the problem.

The issue with accum is that it ends up skipping values on large deltas. This is why I have experimented with counter and uzi as it always outputs the correct number of messages. And there really isn't an issue with the counter in this case, because the only thing affecting it, is the test for positive or negative which merely changes counters direction. This doesn't effect the continuity of counter.

I might be mistaken, but the issue appears to be an OSC/UDP problem. Again, all of the messages are being sent, so it seems to be that some are being ignored. But I'm less clear on how to troubleshoot that? I'm posting a video of the problem here for clarity:

http://vimeo.com/23174228

Concrete Example of Max Output:

print: /arcErrorTest/ring/set 0 34 15
print: /arcErrorTest/ring/set 0 35 15
print: /arcErrorTest/ring/set 0 36 15
print: /arcErrorTest/ring/set 0 37 15
print: /arcErrorTest/ring/set 0 38 15
print: /arcErrorTest/ring/set 0 39 15
print: /arcErrorTest/ring/set 0 40 15
print: /arcErrorTest/ring/set 0 41 15
print: /arcErrorTest/ring/set 0 42 15
print: /arcErrorTest/ring/set 0 34 0
print: /arcErrorTest/ring/set 0 35 0
print: /arcErrorTest/ring/set 0 36 0
print: /arcErrorTest/ring/set 0 37 0
print: /arcErrorTest/ring/set 0 38 0
print: /arcErrorTest/ring/set 0 39 0
print: /arcErrorTest/ring/set 0 40 0
print: /arcErrorTest/ring/set 0 41 0
print: /arcErrorTest/ring/set 0 42 0

LED 40 remained on.

I saw the problem when I tested your version, and no longer saw the problem after making the [t i] change. This came up twice in your patch, and I recall thinking that the bottom instance looked to be the culprit.

Regardless, once everything has its own outlet and the multi-cycle commands are accounted for, you are left with OSC/UDP issues. Specifically, sending too many commands in a short span of time doesn't work. the UDP protocol doesn't error-check, or verify that packets are actually received. And sometimes they aren't.

I think you may have had both problems. I think my change fixed the patching one, but that I'm not seeing the UDP one because ...the Windows version of SerialOSC had to implement a more aggressive buffering scheme than we've had in the past. So it's fixed for me but still broken for you. That's going to make troubleshooting a chore.


Anyway... I suggested using one "range" message in place of multiple "set" messages. That probably got lost in the indignation of [accum] vs [uzi]/[counter], but it's the important part of what I was saying. If you're setting more than one or two adjacent LEDs to the same brightness level, one "range" message is way more efficient (and less likely to get lost) than five or six "set" messages. "set" is great for some things, but I think you've outgrown it.


I actually use "map" for everything now. It sends bigger messages, but requires fewer of them, and of course every message sets every LED, so it's all or nothing on the packet loss.

You can see that in use here:
http://vimeo.com/22548640
http://vimeo.com/22645870

Yeah... I got scared off the bulk mapping style commands when I owned a 256. I realize that it depends on what you're doing... I guess I assumed map wasn't going to be fast enough? Still, tough call. I'll do some experimenting though. The movements in your videos still remain quite slow... neat though!!!

Range is tricky though... because they AREN'T happening at the exact same time... I quick dial spin doesn't turn them all on at the same time... it turns them on in order... and then off in order... Which is definitely a different effect.

I'm really just working on utility patches to make various arc visual feedback modules. For passing pairs on single on's and off's, map does feel like overkill.

For your needs, two "range" messages per frame ought to do it. (they wrap around, so one range is all 15 and the other is all 0.

I'm still not quite sure I follow... sending a range of...

15 15 15 15...

then

0 0 0 0...

would still result in everything flashing on and then off? Or do you mean sending the state of all of the values at once using two ranges? Or wait... :\

For your arc patches you linked to... I assume your just dumping all the values from the two multisliders and sending highest values with map then?

range...

"15 15 15 15" would require an arc16, which doesn't exist.

pasting from the docs...

/ring/range n x1 x2 l

set leds on encoder n (0-1 or 0-3) between (inclusive) x1 and x3 to level l (0-15). direction of set is always clockwise, with wrapping.



You've got a starting position, and one or more LEDs that you're setting to 15 with your uzi/counter/set stuff.

"range" has a starting position, an ending position, and a variable representing LED brightness. so, "one or more LEDs" can be represented by a single message, and set to 15.

That doesn't account for the LEDs that you need to turn off, though. A second message needs to be sent, setting the other LEDs to 0.

Thanks to the wraparound functionality, you don't have to do things like "I need eight 0s, four 15s, and eight more 0s on ring #1" That same thought would just be "/ring range 1 7 11 15" and "/ring range 1 12 6 0". That's the best compromise in terms of sending fewer messages that are also short messages.


You'd have to maybe rethink the logic of how you're currently turning off LEDs, but that would address your problem.


----------------

how I'm using map...


I wrote something up for bar|none about how it works in this thread:
http://post.monome.org/comments.php?DiscussionID=11690

You can also download the patches there, but they're sort of a mess. =)


----------------


An interesting experiment...

This isn't used in that video, but I was playing with it the other day. Not 100% sure it works, to be honest.



----------begin_max5_patcher----------
1923.3oc6c87iiZCE9bVo9+.EM8TytC1fwPOToUp8Vu0da0pQjDuYbWBDAdl
c5tp+uWv.I7KCl.gX5NJJvHaC1uumeum4imy7se3Mqz2D9BIVW6Wz9f1pUeK
ojU7xRKYUQAqzO38xVeuXdC0OPhi81SzWmWIi7BiWgglso1cfSU7ov.VL8qj
zJAv2YTT9QO11GoA6eHhrkk02VPij50r4GQfzi.m2Yn8whqI3oCz.eBiODfk
JM7IVQwfxcbf2AdGq+9Hpm+owTVyY+yQRVGqqetOn63WP3l+9s.nqNuz+8Gd
S54jSqkFfBHeI4dzDeNpE4Erm7Wg+IgcIfjYF73xO5j1VsTXS.HAlAPBqWY3
RhxgkBbIoWn9jmIQwzvfx89J8yhEWbxT+V7SVNkkpD3due31OS3crwoR2Q9z
.tGgGIAs07hC0ZJM3XDIlDv7X4i7Jcr2S9rGDn4p1fO4skH9xaG+WouOhtKL
HcfT8ZSKunK+fF.wsSPUF87lD3crsKmEF5uwK5YZLciOop9HYNsW.8fGivnY
CJnw4qjd3XDMfU81QB7RtMOFuMJz2u5cKqpmaqpcjmoaIegti8H+1UB3p3Lp
7znJ1bUqnSaup1e+TxjiJ0HRCJv9Cwmr.M4vtoSC6OwNp5vNrGaw1sG4phJc
aEyRK8S0j6+J+OWeUv0ida+7DfqN7Sl12PbsKPENyfZQvh2mHcArwiu.yrSF
HI.XvsYhKPugnbNlRMnTbrkZwWLMSEXLRbzAwQYZFoQx6l7wajIliTwc5O1i
rwe5JFjjwg5KVTewi5Oljv3R8Dapm3S8Dip83T0mZ1vEPyFzqqfptC9YMPiJ
6Zhf.WA14tZyBgAeGpEOAc6tsGOBR3UPROCM7NnWotR9fq4G95qL9w2VakDW
p5.jG5CkoOZ2yrppO.lpiFgNgFGvknwAvPkLOlDaiLJAxMQVXpCC2+mYaT3o
ZQZbX3nNZiow1vFsfsMPpi1fo4m9Y5hdj60xxVxP4ftUIlSgJQec92dzKVpi
dIl3qYLkK4E3nd5kMIOfepdo3b25G2YzroFE+M0O2AztCNcZmLJssZx6+syO
VOJCExV4WmPqjkX.EW37oK3httz3oU1Szc5XOvow.gyANoE.baLz2Fd3.Ii.
E84CFyF3xiillFCBH6w6sQWfDzXTfTMJv7oA8RUDWrSaXOPXb3SQaKT0mTnZ
s.F6HwLZvIdD+vImVs15Go610B8bbsFc2wvDKvbQP6iW9TjKVJSruGhPhVjB
Y5puFhTBWlpRzPDxTRMVl5R2gKlfE5TVfzhoHTQ4EygMo0vYQpM4llfgIkKU
2rP4EykYzDWqgMkcYtv.gwGDHlKSgbPhHbgFwDX9cflTjOSQKKv7pKlkaPpT
WJ4Kh8dlr6gjARxih8fGiEQ27DK6QYZOYL5JqD16GtwyOOeNNQ.f9UJyEjJQ
I56lTYXTAkl0z.ZaZx+PhlfzqJKuevlRj8OHwY+i0Xy9m0m4it6jAB3LuIb0
SAo4wVhAWxmw.2frWled5VgcGW1VYNA3coSc.23YFt+JcBxosr7vxZj4L3n.
45r32CLaOuvLq9q2Zn.c9aZznKhgkd1LbTIm45NSPS.Z5Q1Fz8JFgr5hgRwz
71UxUNnzSEUYX1NikSErzj9Vwln4aZAo.lNl4XHTvsGrfWJa4aPOaIvnsE5U
FRZYUrMeFZgKtC2XwcBVXWGKpqW84EJBFRIBPfZJBsMtDoErUTsfs7hfihJB
3FDsHbhDroYixHBCPK.UPaAK4MmgJ5DIG4EAKE0ij7NUay+qRHBP40BSuS0h
JNyQQe7SbdCHJZW50CmDSvt3q2MJXWWbK7OTfIS6dR8f2wKdGoBwFm2MLXzM
eGohcmhMjZ+awGY1RpRbWdcSo98wlRskzoqiTo6B42C0UNzcq29jX6E4VREp
xaIUro9xjJZPV5dtXnhFCmeN6Ll.XVQ3rqarEL2X6Fsof3Y6aO1JEgyXi4Ee
+puFMwIQ0T2eTaXcK2w488Jx4rM9FQ4bdr9aJkyXrpx3Lz4Zx3L1QYHb1VZB
pvFJIsBXoop0VM4KuMbUfF.ptZ.fzBfo5I.RSLE1TcmBAjV.TOdxaCWEH.p4
qaAKuaT07Udgk90Egcdka1ED2rGiHG+ie+2hGA2r4aHYr0LRNqOMl0NAsH6W
In8UBZWT+pAlxXvnxfJnoxPGS66z7JFnWARE6j968DVT3WFYJW5TNkKQXkjB
bK2YFYuCjDoebuZAnUEfUMe2BlWAJDS7nEQeYKKp5nJYlZSIYan+SGB3kaaM
D1CQE+zTLI9B3+bQxu.6NARdv400CRWGTgt2Hpsx8Vda41BYodba4Bx90m8p
RtEBoLjaYJM2PPWk7oxrbW3B.xTVlILApq.HkFvRQ0.Rm9dH0jbK9LaolBgP
uxLwhgYhnjPIDs6O3cT69XBS6d9hOzt2y2eDTUjuXSK7kQUA5hxir0091JsE
Pm5+2fHqYUi3kio0MRJP1lFGojwYctCEkOkU8M0hUg.KhV03CazY1+nCe6Fc
f9FcH6a2fynuAG91nWaLeRsTrM5WkRyhcmoAWZAIm9OvHocHv
-----------end_max5_patcher-----------




That takes messages that are more or less formatted for /set, /range, /all and /map, it applies those transfomations to a 1x64 matrixctrl object, and it dumps the entire state of that matrixctrl object as a 64 value list suitable for /map output.

I have two applications in mind for it:

* echoing the ring feedback onscreen in a multislider, and
* making swappable ring "pages"

...but it might be a decent bridge to transform your ton of "set" messages into fewer "map" messages.

Maybe.

I haven't tested it. But it's a nice theory, right?

I havn't gone through everything here... btu might it be best practice to clear the arc and reprint everything on every pass... you could in theory keep track of which led's should be on, and which should be off... and refresh based on a frame rate.

Clear the Frame... Reprint Frame.

Clearing everything is a single message.

The big problem is the use of UDP... where you can't know for sure what messages have been dropped

@thealphanerd,


Right now, he's sending a ton of /set messages, both for on and off states, and some of the off states aren't going through. There's no frames to reprint, no state to keep track of.

My code sample in the last message was intended to address that as painlessly as possible. He can transform his /set messages through there into /map messages that do remember their state. Assuming my code works.


but, yeah. /map already clears the arc and rewrites every LED. I've never lost a partial /map message, so if your system behaves as mine does, losing packets will only impact your framerate without showing any wrong LEDs. ('cause, the next message that goes through will still clear the arc and rewrite every LED)

...and then, a [zl change] at the end of the chain to eliminate wasteful messages seems to optimize things enough for my needs.

side note:

I mentioned this thread to visinin on IRC a few days ago, 'cause the PC version of SerialOSC seems to handle packet bottlenecks better than the Mac one. He said the dropped packets are probably more a function of the mac's FTDI drivers than any other factor. We've got requests in with them to clean up some problems, but that's largely not in our hands.