OSCPy has been getting some feedback and contributions over the last few months, which is pleasing, and I was able to add a few improvements.
Unicode support, servers and clients can declare an encoding for strings.
It was previously required to only pass bytes strings as parameters, everything had to be encoded beforehand, and the callbacks would only get bytes strings. This design decision had been taken to simplify the design and make sure the handling of strings was coherent between python2 and 3. This addition allows code on client or server side to declare encodings at any level required, and if so, only unicode strings (`unicode` in python2, `str` in python3) will be accepted accepted at input, and delivered at output. Implementing the "unicode sandwitch" pattern.
Fix timeout bug after 15mn without any activity.
There was a nasty bug in the previous releases, that meant that if you only had one listener (most situations) didn't have *any* activity for over 15 minutes (not common for most usages, but definitly possible for some), then the listener would break, and you had to start it again. This blunter was fixed by always using `select`.
Allow answering to a specific port.
The magical function to answer to a message always sent to the receiving port, which for a not connected protocol on udp, might not always make sense, so we now allow overriding it.
Allow callbacks to get the addresses they were called with. Add default_handler option for a server, to get all messages that didn't match any known address.
These two allow using oscpy for some cases where it wasn't flexible before, like being a bridge, which means you don't always know which kind of messages you'll get, it also gives more power to callbacks bound to "smart" addresses (with parameters), so the callback know exactly why it was called.
Allow using default socket implicitly in OSCThreadServer.stop()
Since we can bind to the default socket implicitly, it's now possible to also close the default socket implicitely.
Add statistics collections (messages/bytes sent/received) Add default routes to probe the server about existing routes and usage statistics.
I decided it could be useful to have metrics of things happening to a live system, and so a few new default addresse/callbacks were defined to: - get the version of oscpy of the server - get the number of bytes/messages received by the server - introspect the exsting routes To do so, a statistics object was defined, which is updated by all the functions that send or receive messages.
Improve reliability of stopping server.
In some situations, stopping the server doesn't work well, it seems to be related to the fact that the server could be receiving data when we close the socket, so we now make sure to empty it after that, so it can be released properly, there are still cases that aren't well treated apparently, because some tests are flacky because of that (It's rare though).
Add support for Midi messages
A contribution that triggered important refactoring and improvements (although they weren't strictly necessary). We can now send and received the Midi type defined in the optional types of OSC. Since it's represented as a tuple, we decided to introduce a MidiTuple namedtuple for midi messages, it's necessary to use it to send a message, and receiving one will produce a MidiTuple.
Add support for True/False/Nil/Infinitum messages
These extended types were easy to add, so they were added just after the midi messages, that did change the parsing a bit, because we match against values and not types at encoding. But it wasn't a big change. These are mapped to True/False/None/float('inf') respectively.
Add support for Symbol messages (treated as strings)
This is another extended type that was easy to add, for now we only receive them, and dispatch them exactly like string messages, but a Symbol class could be created.
Test/Coverage of more python versions and OSs in CI
Tests and coverage mesurements were introduced in github using travis-ci after the last release, python2 and multiples versions of python3 are tested, as well as pypy3.5 on Linux, multiple versions are also tested on Windows and OSX.
It's nice to see multiple projects using this library already, It might not seem like much, but it's always good to have feedback and news about what people do with a project.