iipyper: send and receive lists

[jarmitage]

• Send python lists to clients that support OSC lists (SuperCollider)
• ...

[victor-shepardson]

we can break this down into send/receive, list/ndarray, iipyper/clients:

• send iterables from python as OSC lists
• receive OSC lists in python
• send ndarrays from python as blobs
• receive blobs as ndarrays in python
• send Lists from SuperCollider as OSC lists
• receive lists in SuperCollider
• send Arrays from SuperCollider as blobs
• receive blobs in SuperCollider as Arrays
• send (?) from Max as OSC lists
• receive blobs in Max (as ?)
• send (?) from Max as blobs
• receive blobs in Max as (?)

we also need to figure out a convention for type information. blobs representing ndarrays should be preceeded by dtype and dim annotations; how will this work with osc.kwargs ?

[victor-shepardson]

I see two options for serializing ndarrays:

1. just data, meaning the client can just treat the blob as a C array containing the data? but type and dimensions must be communicated separately. this could look like: 'ndarray', 'float32', 100, 32, <12800 byte blob> for a float array of size 100x32
2. in npy format: https://numpy.org/doc/stable/reference/generated/numpy.lib.format.html#module-numpy.lib.format meaning the type information is in the blob, which the client must parse to infer it. that could look like: 'npy', <blob which is a valid npy file>; or even a bare blob: "The first 6 bytes are a magic string: exactly \x93NUMPY."

option 1 is simpler for the client (unless the client has npy file support already). it glosses over issues like endianness and C/fortran order which could come back to bite us. option 2 is more dynamic, and simpler for python servers and clients.

[victor-shepardson]

it looks like parsing a npy file entails parsing a string representation of a python dict with specific keys. there is https://github.com/rogersce/cnpy for C++