iipyper: osc.send imperatively after OSC() constructor

[jarmitage]

In the following example we query a Faust patch for its OSC interface (https://faustdoc.grame.fr/manual/osc/#discovering-the-osc-interface-of-an-application):

from iipyper import OSC, run, repeat

def main(port=5511):
 osc = OSC(port=port)
 osc.create_client("faust", port=5510)
 osc("faust", "/*", "get")

 @osc.args("/*")
 def _(address, *args):
 print(f"{address} {args}")

if __name__=='__main__':
 run(main)

This example outputs:

OSC client created 127.0.0.1:5510
OSC message sent /*:('get',)
OSC server created 127.0.0.1:5511

And the response to the get request is not received.

What should the pattern be here?

[victor-shepardson]

hmm I see 3 issues here:

1. it's not clear to the user why this doesn't work. we need to communicate somehow that inbound communication doesn't start until after main runs.
2. there is actually no way to do this at all right now?
3. this example suggests the need for synchronous handling of some OSC. presumably, we want to complete this query from faust before doing whatever with the result. In general we might want to send some OSC, block until a specific response is received exactly one time, and then continue.

to fix 1, maybe we need a different conventional name for main here? main sounds like you should "do stuff" in it, whereas this function is supposed to be mostly declarative, with the action happening in handlers and repeated functions. maybe call it app?

instances of OSC could also check if inbound comm is initialized and print a warning if you use outbound beforehand.

to fix 2, we could add a decorator like repeat, but it runs once and doesn't repeat. call it init or setup maybe.

fixing 3 is maybe out of scope for iipyper? at that point you are basically writing an async web app type thing with promises or futures or something. I'm not necessarily against having that in iipyper as long as it stays out of the way for simpler cases.

maybe we should add special functionality for doing this setup dance with faust specifically, and which hides that complexity from the user.

[jarmitage]

Regarding 1, what is the actual order of execution? I was just assuming that it simply takes longer to setup the server than the client, is that right? I agree describing it as a declarative app sounds better, as long as we actually can stick to that paradigm/pattern.

Re 2, this is the pattern I have gone with for now which is not great: https://github.com/Intelligent-Instruments-Lab/iil-python-tools/blob/master/examples/faust/hello-osc/server.py. And yes I was wondering if there could be a once decorator. Could this have a parameter for running after a fixed delay after the program starts? I think that would pretty much solve this for now.

Re 3, I was also thinking that JavaScript-y affordances would be nice, but it still seems to early to tell if it's worth the additional complexity that would bring (it might be achievable more Pythonically through something like traitlets? https://traitlets.readthedocs.io/). Maybe let's see how painful the hackery actually is in practice before going further in this direction?

I'm not sure we should optimise around Faust just yet, but that's certainly doable if it becomes a runaway success for this library.

[victor-shepardson]

re 1: no, the whole main function runs before the server gets created, because server creation with python-osc is async and takes the event loop as an argument. when you call run it Fires the main function, then creates any osc servers and tasks inside asyncio.run. There is probably some way we could start the event loop first and have OSC await server creation when instantiated instead, I'll look at that when I get a chance.

re 2: I think we should add a schedule decorator which works like AppClock.schedule in supercollider: it runs the function once with a delay, and if the function returns a number, schedules it again with that delay.

[jarmitage]

Yeah, I think if we can have the model of execution closer to the code at least for the initial run, that would probably prevent user confusion.

schedule sounds great also