Closed josiah-wolf-oberholtzer closed 4 years ago
Hey, thanks for suggestion! I would rather avoid breaking the spec with arrays. This might potentially make messages sent from aiosc incompatible with other implementations (liblo, etc.). Are you going to use this for directly controlling scsynth from Python?
Yup, I control scsynth directly from Python.
Ultimately I wanted to use your pymonome library and find a way to not have two implementations of the OSC spec in my codebase - e.g. I have standalone classes for messages and bundles because I need to support realtime SuperCollider and non-realtime SuperCollider - but it's simple enough to reimplement my old SuperCollider-specific OSC logic on top of asyncio, so I'll probably just do that.
Totally understand not wanting to support SC's OSC weirdness, which goes beyond arrays and doubles 😆.
I see, but yeah, you'll end up using a subset of aiosc that only serves scsynth, so a reimplementation seems a better idea to me. You can also run your original OSC client thread unchanged alongside asyncio main loop, if that's an issue. Are you fine with closing this?
Yeah, closing. I'll have to reimplement pymonome on top of my own async implementation, but c'est la vie.
Alternatively, you can have separate OSC endpoints for interacting with monome and scsynth respectively (using different protocol implementations, if necessary).
SuperCollider uses the typetag
d
for doubles, and[
and]
to delimit arrays. I won't claim that these are a standard part of OSC, but supporting them will make it easier to useaiosc
to interact with SC.I can provide a PR if you think this is worth adding.