OSC-route.maxhelp could show wildcards more.

[mzed]

OSC-route.maxhelp shows wildcards in incoming messages, but not in the object itself. Some example like: [OSC-route /thing/*/otherthing] might be helpful to the dimmer users I encounter in the world.

Or maybe, a separate tab with wildcards.

[adrianfreed]

I thought OSC-route didn’t understand wildcards

On Dec 29, 2017, at 07:06, Michael Zbyszyński notifications@github.com wrote:

OSC-route.maxhelp shows wildcards in incoming messages, but not in the object itself. Some example like: [OSC-route /thing/*/otherthing] might be helpful to the dimmer users I encounter in the world.

Or maybe, a separate tab with wildcards.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[mzed]

----------begin_max5_patcher----------
476.3ocyUEraiBCD8L7Ufr5oUzFLDCI859ArG1iqVUYRlj5JvFYaZSUU+2W7
XnMaBpk1l1cuLHOLddu4o2.ODFPJU6.CI5xneEED7PXP.lxkHn+b.oluaUE2
fkQLUh0flD6eUiFLfzxsBk7JMrx5aUZQxEIwQEtPReH5282QrFajp7lyW7Te
3ZdMXA8UfjWVAtJR5emrsVHq.KhO84jpV6gYM1682kLzXeQ16a.OyHjm3QC2
t5Zgb6w7l4BKwHMagi5ta7XXnKD+tDp8F5h+yFZJkdxF5ZvX3agAhXgcHHjY
kb8rsbgL5L5q4clu.4PN60bO4jwDqzOWGx.6vGEycwzzSsZsQoNTs1atY+Cl
6kE6O1YenwdSkpijiLXYu6MiMJcMGoZ9nxP5aPFhiHkb41WdmYAtyjwPSJK4
CoGR3tto+HWvO942OW2QOHZ12P2vHJFkL8uW7F0fWd9KP+PZ1RzVjvFU.vNP
pDxC+EC1QW9+VULpV8pANz++gnmW8WCFqPheuXuZx80LptOUbJl.NrS.N4S.
G5I.G1WDNzIfS1Q33sE7llaAsouXDht0haTZ2whX7nP5OlgG0vshg5YXFtty
XZ6bksZuidW9bh+ppte9JaE35PnC4GC+CDVfLjF
-----------end_max5_patcher-----------

[mzed]

I think it was v1.09. https://github.com/CNMAT/CNMAT-Externs/blob/fb19174b5f477cf89ff1280c6306348644ad3e17/src/OSC-route/OSC-route.c#L43

[adrianfreed]

Interesting. My brain hurts figuring out how that can work in general. Is it a feature of o.route?

On Dec 29, 2017, at 10:53, Michael Zbyszyński notifications@github.com wrote:

I think it was v1.09. https://github.com/CNMAT/CNMAT-Externs/blob/fb19174b5f477cf89ff1280c6306348644ad3e17/src/OSC-route/OSC-route.c#L43

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[equilet]

[equilet]

Actually I take that back. Michael's case is supported in [o.route], but wildcards within address strings in incoming bundles are not supported in [o.compose] nor [o.route] for example. The reason I bring this up is that support for wildcards – embedded in osc-style messages – is something that is featured in osc-route.maxhelp.

[maccallum]

The / pattern in an argument to o.route is allowed there for backwards compatibility with OSC-route and is special in the sense that it takes precedence over any patterns in the incoming bundle, it must be by itself in that level of the address hierarchy (/ain works as an incoming pattern, but not as an argument to OSC-route or o.route), and it’s the only wildcard that is allowable in an argument to the object.

Like Adrian wrote, it’s really tough to make any kind of sense out of how to interpret a pattern applied to another pattern, etc.

On Dec 29, 2017, at 7:21 PM, Jeffrey Lubow notifications@github.com wrote:

Actually I take that back. Michael's case is supported in [o.route], but wildcards within names of addresses within incoming bundles are not supported in [o.compose] nor [o.route] for example. The reason I bring this up is that support for wildcards – embedded in osc-style messages – is something that is featured in osc-route.maxhelp.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/CNMAT/CNMAT-Externs/issues/88#issuecomment-354524561, or mute the thread https://github.com/notifications/unsubscribe-auth/ABjjdRxCxnoDcVcH_TuWB8ISvPpsovHKks5tFawegaJpZM4RPLXd.

[mzed]

Although I created this issue, I'm not advocating for a design where both messages and routers can have wildcards.

Here's what happened. I saw somebody on facebook who was having a hard time with some difficult, incoming OSC namespace that I think was not under their control. It seemed like parts of the message hierarchy were difficult for this user to predict, and they were getting advice to use regexp to tear apart the message and find the part they needed. That seemed crazy, and I recommended using OSC-route with wildcards, which works. I noticed that this was not documented, and created an issue.

I agree that wildcards in route objects wouldn't exist in an ideal world. But in the real world, these objects might be used to parse OSC messages that are badly designed or not fit for purpose. It's brings up an interesting question about our role as developers. Do we create a potentially confusing tool that can help users work around other developers bad designs? Or, is that confusing tool just going to add misery to the world in the long run?

[mzed]

FWIW, here's the thread: https://www.facebook.com/groups/maxmspjitter/permalink/10156906302424392/

[maccallum]

Yeah, I can see the confusion, and what you’re saying makes sense—in fact, it’s a common source of confusion even for myself and people working with these objects for a long time. My preference would be for OSC-route and o.route to not support the /* pattern (although, it can’t be taken out now as many people including me rely on it), and to focus on the design of pattern, address, and string analysis and manipulation functions in o.expr

On Jan 1, 2018, at 2:05 AM, Michael Zbyszyński notifications@github.com wrote:

Although I created this issue, I'm not advocating for a design where both messages and routers can have wildcards.

Here's what happened. I saw somebody on facebook who was having a hard time with some difficult, incoming OSC namespace that I think was not under their control. It seemed like parts of the message hierarchy were difficult for this user to predict, and they were getting advice to use regexp to tear apart the message and find the part they needed. That seemed crazy, and I recommended using OSC-route with wildcards, which works. I noticed that this was not documented, and created an issue.

I agree that wildcards in route objects wouldn't exist in an ideal world. But in the real world, these objects might be used to parse OSC messages that are badly designed or not fit for purpose. It's brings up an interesting question about our role as developers. Do we create a potentially confusing tool that can help users work around other developers bad designs? Or, is that confusing tool just going to add misery to the world in the long run?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/CNMAT/CNMAT-Externs/issues/88#issuecomment-354645873, or mute the thread https://github.com/notifications/unsubscribe-auth/ABjjdVzohNH2m25eC50f3tV38aL0W17Lks5tGK3fgaJpZM4RPLXd.

[adrianfreed]

"I agree that wildcards in route objects wouldn't exist in an ideal world. But in the real world, these objects might be used to parse OSC messages that are badly designed or not fit for purpose. It's brings up an interesting question about our role as developers. Do we create a potentially confusing tool that can help users work around other developers bad designs? Or, is that confusing tool just going to add misery to the world in the long run?”

I have regretted every rushed, addition I have done to satisfy a small number of vocal users. We used to call those “hacks” and the long term misery isn’t worth it. I did this for resonators~ with an output gain feature somebody convinced me they badly needed. It complicates the code and we pay a high price. This is all the more unnecessary now that the source code is available.

On Dec 31, 2017, at 11:51, John MacCallum notifications@github.com wrote:

The / pattern in an argument to o.route is allowed there for backwards compatibility with OSC-route and is special in the sense that it takes precedence over any patterns in the incoming bundle, it must be by itself in that level of the address hierarchy (/ain works as an incoming pattern, but not as an argument to OSC-route or o.route), and it’s the only wildcard that is allowable in an argument to the object.

Like Adrian wrote, it’s really tough to make any kind of sense out of how to interpret a pattern applied to another pattern, etc.

On Dec 29, 2017, at 7:21 PM, Jeffrey Lubow notifications@github.com wrote:

Actually I take that back. Michael's case is supported in [o.route], but wildcards within names of addresses within incoming bundles are not supported in [o.compose] nor [o.route] for example. The reason I bring this up is that support for wildcards – embedded in osc-style messages – is something that is featured in osc-route.maxhelp.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/CNMAT/CNMAT-Externs/issues/88#issuecomment-354524561, or mute the thread https://github.com/notifications/unsubscribe-auth/ABjjdRxCxnoDcVcH_TuWB8ISvPpsovHKks5tFawegaJpZM4RPLXd.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[mzed]

Some of you know that I'm in my third (and final) year of an API design research project. So, I could blather on at length about this kind design problem. I'll try not do that here, though.

I suspect that "implemented but not documented" is something like "code smell" for API design. But, we often have to accept imperfect design decisions. My project invested heavily in user-centred design, including a PhD student doing nothing but that. Given enough user personas and use cases, there will eventually be conflicting design recommendations. And then you consider engineering overhead, maintainability, etc. I do spend a lot of effort pushing back against features suggested by small groups of vocal users, but that really has to be handled on a case-by-case basis. I'd rather listen to users too often than not often enough.

John properly notes that we're stuck with OSC-route's design. My instinct is that features should be documented, even if we don't like them.

[equilet]

Happy to make a separate tab for wildcards before the release. Curious - have you gotten into o.route (and friends) at all?

[mzed]

Yes. I've just had good luck redesigning a bad OSC namespace using o.expr. The IRCAM RiOT board sends a message like /raw and then a list of 20 values which includes all sensors, quaternions, euler angles, etc. I tend to prefer some more self-documentation in my namespace.

Unfortunately, it's hard to share this work with folks like Atau Tanaka who don't have o.dot objects yet. Getting this in the package manager would be really helpful.

[equilet]

I've attempted to clarify the use case, which will show up in a forthcoming release:

----------begin_max5_patcher----------
5457.3oc6ck1baiqr8yI+JP44U08MwVhD.bM2od2JdI1NwaxaI1SlxEWfjXL
EIMIkkUlZ9u+vBorjskEkMnhlaMNUjk4FPePiFGznQy+7suYE236HYq.dO32
Au4M+4aeya3Ghcf2T72uYkdN24E5jwurU5Qxxb5PVYMw4xI2kyOtRbpSTGhB
Y.QoSniuRfRV+jj3zbfmSpe1+o7Nh52KHJjjyebnhCF3yeHwteugg9XWYb+7
xKEVbzr7ggD9U6SZ6zOLu7xSbx85FD04pThWtPjLsaZP+Q2XM.FgapuF.ZiZ
ptF.Q+D7GE2nnPxGlPD20Jq.9C1Y9q29V1GqUQjIhLfV+eDvjjFDkCFDD5+j
H.7IP.smFATeAHfN1tIl9CDuFPW2jI65V2i.u.wbVJ.Ci6+JU.TqEE.jsAWA
vxbAq.b3IazHkVDDvCvkppOLkNDnWq5.RmCHZUAPV6kBJSUcgnzVoiRWfuSt
SkUMfUU034zIvZL4FILHXpUWpCgA2RZFFDQpb6r0y2u+IjEMSCd0WG2DgQHU
KZyJ6.F1MQFll1nWTMm0H41OOONZDLlFmGyPjHmdB.des8Z5GjkD5Lr7hb6D
G4EGFmJpap7tdFlqw9lskJ1l8MSnogF+X2C3OIvj3jRKqbR5UzB0UzrVhD8y
HSTXk2S63n7rfevuVHsDFU6IYjnbm7f3nw.OL6JJ9DohaZCssQH1XDMglT6D
5ipfL.YBISERECclTfsMTMs3RlNxVCRu8wjrQp6cyySxduhRmf7t8ca5E2SY
iC1+CmJ9rQre7ntsioQLRcmIXif9OjF3DBVO99QTXECswZNKH1Ckped83Hna
mWZK3XJr3o1cj1vwqq2RReTimPHFq3grFlI9XBbchGBqxhGUwLz0rUQruYyN
zCZTBIcb7FNQaJ7YLYpwYL.KrZ7r5IOscS5+oT.jq4y+82RoWGHzoejW2qbS
iGjQRAyQiOyvjWb+n7wavlk8WczKbn4tA99jnpgzhgkPHtgLMa4aXlBK8nlC
dDldPbN48f1wof7tDfW+zT5UAnZYYT6Ff31.NJBnimCnfAsZmARBINYDPFgv
umCo.LHLvM0Ic3Z.macBBYlt.N4zGeUGE.WU1eOyXbXiwzY0UEL9TegL9n0C
WR5JuTi04oAYdNEGqo8ikXj732XWvxWkK33JxrwkRbUxraZGGq35jB9efUka
CVdrdKQALumjgUsQ3slULzjmhgEctO2S56mnhgihqhmh+Ki9qDmXjkMWEAIL
T.w0kNxzL1JlQTOZsLnQH4VRHfxRqcvcjr2WUKklxaZxll7NI1HwLhzdc1Km
47.KTB.klIppDOkIHfeEJ.lheoqWwIAJ8IB5DFVbprp1OvVd8CvVbMeMjVSM
jkEizHEQVvdHB30kZngVwZ3j1oOq6xSCEpOwLDTkdm.cc0lZFZZPS1PHpOBL
32IIsPNKDT5rIBXci4bkFqw3Mq3jjL1geyX2BCc9tf+s4ZiNTPj3P3QGJkba
P48qM5nNoz5eNsx2OUHf2MxuYrGSrOIMpe.upHNHsc5skOvQyeFxGI.JHaZn
I9ko98hKaJQgwdWS7GCVoZDzoBGDM9DKm3zEf8USLgTTym77sc7HS8lmbRek
x2JcRC7iiXUhIvZ1gKKNpvw0rGWT3mOxI4It0BFsO8IynhX+LpgJVCQwn3nx
SlGGGN4oFcegj14EmNIHJ5AXXdbxzOYZPmtOy85FSOYum6YyOS1U8iDm8JZu
v7qxbtcRrNmZ9ona4jO96bhB54jSxCDM.H0QmTvjoalWZbX3Dxq3L29Dmwmp
C6QFD3m2UP2YrVa5kGjTpBsxn1X+.pIw7IOVtSmrIOxilN.8P8cK5idUNoWR
HUJl7Blvo+i2gbbCXSb7Y3ZqoN30in5Cevc7XSVS0RMcVLLFb1byybKUP1Da
DVheSo03hd5uPAaxAolzLcFIGfAcb50yYphM5oE6mQpGGnllw5oAIHjpXNxb
RbVOxT8yN10BBwP.WR9bCXn5AvfHqlXlKsrGgZF3kQTCBbBS5N2vFtdfMM9J
mTBX1+L.rInNMcd0.EWfh27ZURa5vl1qF1zw5BaUlUD2V6QLskDFN4TwlDDu
HtOvyIhp1kECBIzgIAzZF2oVz+xmJXfL5CpKHHhePZ6Avw2mx+IqXhafAcIQ
f9YrKkcEeioH+sU.Ep5uedaTzq1HEyaihvyXZFbWMpW57eIOLxygzLuLRAHm
bJBQu9.J2pHOBEn5m3SGoNCjGK7+XbJqVCt0IrO8nL2RRb75BD3Py4ENMpU3
DV7KyZANqXmelESpA.5vM.kmeX5ofQl0ic.AFgMES0vB9y1NvrI4n7hX4XUS
rbf3l1rEsV6d1e3kSpNJuDtN10OWmBXyvb4jqixKhryHWeHYfSzcs.xLw+WG
aGHrVMyoA+aDcGti2Dqc2CXyPeJwdAzAj8ACBx6N9XuhCHCNNPT8LprvcVHA
UcMS0ehiJ2NNFLlKtqNz7LykA+ZzRwEN2W3AALdNUSWXpn66Lzk.FRUTG3Dk
yXE1Oqf3XOBSuMHq2Z.WJIc10DQnJpb03ROHytC5YRANtY4oNdLGLwNVTbNc
J4cn734pwNBd8MAmRu4rDhGK1RJeHLEb1Yop3cIgIYkZ9AYSv+bhXI.MuMzZ
0Te.AcKwXdZlbqRrV6Eee.wDmXcDDe6kzaPul5MXLdmAKyelcFpDV9KPvuf.
+BdtAPi5bPOHpHFgzWlGzaihUY5w1IFguUBVmXQMLZpNED2bd6WOqNzhv0Sz
QVU3EJsE3D24FHG1yMNLioFl2khXc5B9EaNSB2oAobKqCA9wQ+qb5m.mng4L
ISX6lZMmEBQbOsLD3kRbxEzQ3q+APDgErXOp.8VCjEKFDf6tElo+fHlKDxYb
UtuT4Vpo13YtzYL6+BS9ipmA7.SODLHN85oaQGOu80rpSK5FEtZvRXWeAp.7
aMZ.H2zO3VmP1XiMZ7+M2VgrqIjovOV7XdE.qI2v7bXiS6bpdpWXf20EVX3j
URIjRxw.9pNsV4oFLVWjQgSmSJYLD98RiiARsl79ERXMRqvZDeEplJIi6WGV
lvLkEfiWJ7kV6IaPxnL57JGFov6AfIGswmjkGDMZMo+86m0Gnp5CyakvZYnR
fqXkPqFqCnkf5.yuH+7aMfuZjn3fkgswJr0t2+JgohqbxySCnCfJ5FMdbnLW
qmdmvXWmvhUKeTrV7bKt98q.+auu9Jq3.peD01RbmHJ4J+FAQI8yqbb.Akeb
.AsEbaw+WcH.oKB5GQTeoKBVVcq+IBf9mH.5ucQ.zCHsr.BDnmy29JuSApfT
vKKAKisJmclsV49JY4ZoPJiI7kjPkAgwiCWlKYKChXWUSK+Fz4SzfZcJsgnx
LuSICWOyL.pygOMqhMhCZx8b8BQeBLvIi6tWlS.Jly+7pcoUOZWlViobAK7B
4x7hrATdmDCfE8WMzooIbYKz9E3wwEpWGw+JX21SrNFYTp6If31s4N5hxA.H
1.HwhCv48Vtbbb+ETttDM7Xa1twVbBk28sUDdvxWDzLzmr20xyuA0TPyT3IS
gQAb4es.8VC5Wm1x8PuKJOgfHJt54zOijMlWZnMcBytT6Ijzz3zQt1oHnv12
4NZqQje7.PPalyEohLI3V5CgdGiO2FQar7ZmLqK2pwi33xfaZw2NcJ2AZCbF
xcobWmH+vh9GYBm.K7pbOVUWn+S6wyl4389388Rzk9VR1i9E65LN7pqhpEO5
OSNDQwQjFws47Hbbiuctio8ZxmtPCQfTTD1XiuzR+shAQcElNlEw3.7uMTHJ
sstrDvNEHnsXQCzsWliKQIoKVSSVRDkXPn9eWzEkYz3n85ANwFtcIOlwfBRS
b2R0KNKuXIYWC789Yrr9v0r3AiCyeiVwn+tXXZBf9DCRKI1NhyDmgjefOaDb
Z4JB3dmngk7fioejVttuueoOdaDK5nIeTbM8mObapkUBiNeK.tBq3.tFW0Cs
JtpG5KAqAUcVGX1KpTigccVIpJR.w+yxwMSkhkpki6gd5VFqJ2TSYGqpznpY
l.HRhYwEVjTaoxytXX5TkJ2S9HaQlLYwkqNNovOAL2u79w4ewFppvKLhPWhO
S+hnjVDpp71xL93Z7w+Z9jIfJTES.FPrDWlyhchigcS6QPqwjiaIsbiYDQIe
PrBOhXprxjl7TlrDo7lw0iV3IByx4ayC+sFrUJtAi2SVCga7CxlzE9yVYPWd
JCVhrhJ1pf6tZ8jiT4I9kJ29K078i9Ca+0T+oz9y89aBoxYCWnLSyOBTPSDt
tVutF4YmledWkkQK4koqJao0UKxnQ0XxccZCX7AdqbTGligytoOKr9bSc7tl
JVSLh.ayBGRX6BGV.pRmsSgijE28+FzcXBKJWCh7C7Dit.3IYX13NitorlUO
mF9TXus7zuzD61.rgXHZgwj6iQUYYE4cDk2E7N1VqoplRPRLmJirEBoJpogs
gts1Z.C3hN8g8A1Tl64zvmvZz4aSqv.5zvoJPd8SCG9z5ajPRIsE9NamdGuJ
5HHn70cvPttiveuuXlHSC291JLxZigI7AiqpcJDRhxq0iRcwPQ3z9hS7ZSuC
C6e.VTBT4NLXo2gAYZNhnodskSFmN0ijjPhRRv+AnAzAFUFHzjOPf3KgsM9m
B+CNNjDTccdIxxjsmrM0PrrLmAlGNRiuS1qgjw+26GFzOSwygj4jpjRYamV8
wLjH8yhAHzEIaPC7BW620Ih9OEWV5RV4Oge6aqgo+W+u.7T7YUQDS4OJJtXa
JpWWPxjIx8YpsaIwbqHk7Y4aeAcMt5NR69E4cZh4KOoqNmhpLSijzAuWhEUr
Do+g0VpaUwPIJpvk6VUjLMGsb2pJS5XK48UkIgqEce0pM96uiZnY7Gy0PuXc
4OzqQQpOV6mBOTACMAAsJqaXHw4eQ4eOR2vR7tQREUGdDaR4MvqxuPbvRz0e
EALqgXeCaaWyt9iKmfB92ygm.wSg+k1KWj0JZb0MliT7s7eeO8NAlnjQH9Yf
drXlvk6oOmfno3M3mxNfs7mN53dfn9dcPMyIlS.P.BfqJRnIQNcZEy9P+m37
xEiPjRR56FF3U09KZPYN6b06sHZv8QwDwWurk3djvbgT+pbBolDcJGTGM1V+
TDLOX8ZyJIDnf.JXfhFPQGnX.TLqbC+TXDZ8ZoIAUEumH0lSqkqICqmUwyUU
d3SMI9djjNFhkITERGAU2RBNtZ1B5bwTPShNoq3k.fkvXHrlIJTZvCnvLG.D
LjqrXaHO1Bia8SyRrHDpnEAkgJylhMFoxb35VMSIRlRnUnJdyJooub.L7dJf
hYWAJ756CCz7YiSVxFmzzPhIatP3b1NYNHLLCBjjdthMR9y7hpCJxR.PMwjl
DYYQqmSF+dP9U8bxSCnhQ4EweyOIRAA1XprmvlMLXkcW+5S1Vs85WF0j9yQa
ramMac7Gne8Gejcf814qrec6GiNYUB6aatWui1s0VquS6lqa1o4E6rdylq29
ni2bqMOCO3BC2sxB1Xi023y64s5pqdm6gC1M26lqOemCfwae9kWd7Ia7kKc2
qyAsOKQ8RU3Nmg+Lzq896cyoeZiUOvx+lC+zknq+dqL0MFZdx0na17FGR+yM
HYqu6Wxx9x0CMbyrObnwMGZ0YmlGm26CQ5GhtFcgq5Ie4DmvOed+sPetc6gW
LHc206ot5pa1q2mtLYy8tq4AIe7iqusEIIVa2yiu8yGa5S1wY2dGs09mdTV6
8Rtns+ls+7ksvvSu05i6t9f33vg2dxlYed3dc23v6tyqct+4ataTmcuLZiC1
630+503Vdc24vrKa05rOtyosNI6Rma9A4qg21h7oUa4OLv7xstX8KvcC6gbS
StYf+W8zOX+g3s277sZcX5ga05jNW5LDt8o67gSVuW3E3M9XDtWq02Y+VCuw
AtyM2D2lVAt6f82xuo1YMuoi10WfGryfzO29lO0NORqiiy22o8NsG5d2o+Xq
82DG2+GGd7NWdwMvOZr8EsVu0mO1E0Luqy9e3hMyNyyYaUeUurgMuXy82pS2
78Ft4I+3tyy1+7i9Tqg6Q1J+L2Okne2dN2Fd19NWnGAci7W+Pcxp2E2wMKua
R1Ns+D5ya6mbgIta6uGzxcaOi70MCCty96sCObGzlsfecOX2yWev4+33cl7K
Yq943up16nu9i96zTOKw6bs98Pm3co5kV89hef+AsHcu7H0Ua8QmCBL5rwgm
+oqOk1Z63FrWma15KGYdH7nUM5ug91p6d55eIvn2ccxi1dCZa4Fe3GGcNxMN
qU6ullr9ON+xP+7V8Mhu6iqFfcWciO16Hy8as5o6GtkaK7wayTsat6Ye+jM0
RNp8t6H2vG3gI7tm1rw34lim5ULK2WZO9E3npzdANV7FZFqVKwBvlAY7RtbK
IjMJm14DANLgDcBcpH9fMnRbZb3nDja2.RJKyqLTjM4nOhbRZjHlBliXIPWh
ybSfVFEusKecAQvLUY.AY.VtkIj3ChiXa50+U1867ihbYlH69EjC36gVdd+j
GqJ8BXgpx+6YGuWCt.9qSGnIYMAawx5vOLOoABnCuyCjE5iNNh.hn0lxPmpr
UJOkPdcwZqtlrafDud8zKB0Rr7afJUFaTpL9dfC3rnf6Zj0kDF1fuIcd30.x
FFk6bGvILLdf.PK2iN4wfNwrO4umBYTsn7p7nn9C.aZ+HJ+zQcLdk3tDmKCR
rG+JdK+ogpGCI6Ox9QLymd9E1UpdLdpKS+ZWjemESiW2rVLF7sU9OiEFULUl
QgiXkkYI5babo2JDNsp3UzirE5e62.mD2iLfEW+WG12uyP5.E9.e1bNn1mxX
aT86SR.hcyV4dei04bxdKOJmA7J60H+v3b7WJjHQfz9ntNb17StK1DP7C2fN
E.8ym+FmVNxy59ckyiZKqZAYUgBxfsMgfRnffyRhjf.YnunfNC0EVIUgBRFk
SUfNCYzHoUE0NleZjSIMS8NCYURnYTR3IE7dA9IwAQ4YkY.F8lVr2oMX16hJ
QF8Q7Fpl+Wu1JnYU.ccY.ElUAz0jUIMKPGIEYxnBkjFVVkzLQOjrJoYpQ.kQ
IgqPIg0jUIMKzCikUIMyN7HYUR3YURRqcRaVkjprJI8Y0y0VVkjwrJIYL9o1
BiQ.dgQPDWkg0zkUAMSSDlxpjloIBYvI.uvHihWPTDQlKJIBYrvJIsEVIgWX
kzByTDpJcakP4.qh8AnorJoYYe.JCadvpniCkQqDTagURnEVIUgBRexZS2.e
+Ixg4ObJX55vxMijgIzxj9cSyodHwRKnO5OdBm.8frbOSVdP1s+AY19GmU6m
dFs+gYydZI+Wu8+mV.4rB
-----------end_max5_patcher-----------