OSC controller map similar to targets map

[jarmitage]

let myCtl = Controller {oName     = "MyController",
                        oAddress  = "127.0.0.1",
                        oPort     = 5050,
                        oLatency  = 0.2,
                        oBuffer   = 128, -- input buffer size
                        oSchedule = Live -- needed?
                       }
    myCtlShape = [OSC "/mycpath" $ ArgList [("myp1", Just $ VF 0),
                                            ("myp2", Just $ VS "")]]
    mycp1 = cF "myp1"
    mycp2 = cS "myp2"
    controllers = [(myCtl, myCtlShape)]

stream <- startStream defaultConfig targets controllers

streamReplace stream 1 $ s mycp2 # gain mycp1

*input buffer so that you can do basic sensor processing, e.g. averaging, filtering, derivating

[jarmitage]

The current controller input options are quite simple compared to the target options, and people are currently hacking around it with encoding information into the path string: https://club.tidalcycles.org/t/open-stage-control-tidalcycles/1283 https://ghales.top/posts/open-stage-control-tidal/

Now that we have the OSC Targets figured out, wouldn't it be nice to reuse the same features for the controller inputs and make those into a map passed to stream?

[jarmitage]

An example controller input that would be fun to map onto: https://github.com/kylemcdonald/ofxFaceTracker#osc-information

[freeeco]

Yes this would be great, I'm trying to send OSC messages from Reaktor to Tidal, Reaktor sends OSC messages containing only floats, so I get 'Unhandled OSC' errors when using cF, as the 'key' OSC parameter for /ctrl needs to be an integer or a string. So having the ability to set up custom OSC inputs would be useful.

[yaxu]

I kind of think this is really an issue for Reaktor et al to solve. It feels like it should be a lot easier to configure a sender to meet the spec of the thing it's addressing, than make a listener fully configurable..

[freeeco]

I kind of think this is really an issue for Reaktor et al to solve. It feels like it should be a lot easier to configure a sender to meet the spec of the thing it's addressing, than make a listener fully configurable..

The thing is that Reaktor does not use strings at all (the 'Primary' layer in Reaktor, where it handles OSC, only works with floats) so they would have to fundamentally change the way Reaktor works internally to enable this feature, which I don't see them doing just for this! :)

[matthewkaney]

We're discussing this over in #982, but I thought I'd pick up the conversation about the specific interface here. Overall, I think there are a few ways to simplify the OSC shapes for both controllers and targets, but I need to think more on it. Regardless, it makes sense for this to use the same syntax as custom targets.

Two things: first, I don't think oSchedule is needed, so that could be dropped. Second, I'm kind of unsure how the input buffer would work. Your example doesn't have any place where the actual sensor processing functionality is described or implemented. Can you write up some pseudocode for how you imagine someone would define or use an averaged input?

[jarmitage]

The input buffer idea is perhaps a distraction at this point, at least it would be low priority.

But essentially the idea I believe was to make the 'last N values' of your OSC input patternable, e.g.:

streamReplace stream 1 $ s mycp2 # gain (striate 8 $ mycp1)