Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

OSC support would be wonderful

Codea is great for building rich interactions. I would love to build applications that run simultaneously on multiple iPads. AR definitely wants this. OSC is a standard that has been around for quite a time and has been used in countless creative applications and frameworks. A standard has a lot of advantages over a Codea specific solution for transmitting state changes between multiple devices. OSC would warrant tight integration akin to touch.

Comments

  • SimeonSimeon Admin Mod
    Posts: 5,054

    Can you tell me more about OSC?

    Is something like this what you'd like to see implemented as a Codea API? https://github.com/devinroth/SwiftOSC

    I really like adding new APIs to Codea, but sometimes if I've never used the systems it can be really hard to design a nice API. So I'd like to get a deeper understanding of what this is.

  • Posts: 30

    Open Sound Control (OSC) grew out of the electronic music community when local area networks became good and the early 1980s standard MIDI was starting to look long in the tooth. Musicians wanted to control networked synthesizers at high speed with precision. OSC was a good answer and there was rapid uptake. OSC’s generality allowed other creative artists to adopt it as well. Early on the performance Stage Lighting and multi-media crowd adopted it because it allowed a delightful loose coupling with high performance and precision. The by the age of the early tangible computing crowed (TUIO for example ) they just used it “because it was there”.

    We shouldn’t let the “sound” in the name make us think it is just for sound. The basic idea is to send quickly send a uri path with value(s) using UDP. For the full story the Wikipedia entry is a good start:

    https://en.m.wikipedia.org/wiki/Open_Sound_Control
    

    Something like SwiftOSC would probable be a good start. I don’t know what the Codea API should be but I could imagine it could be made hook into the parameter system for incoming messages. We might want a standard entry point like touched(touch) such as sharedStateChange(path). Maybe just a callback per path. .For outgoing you would just write to a channel like object.

    Some kind of shared state change mechanism deserves first class integration. :-)

  • SimeonSimeon Admin Mod
    Posts: 5,054

    Thanks for the details! I'll look into an API design and propose it here

  • SimeonSimeon Admin Mod
    Posts: 5,054

    @DavidLeibs

    What are your thoughts on these two designs:

    Design 1

    -- Listening for events
    
    -- start osc server on port 9000
    osc.start(9000)
    
    -- listen for values on "/"
    osc.listen("/", function(value) 
        -- Do something with value
    
        -- Value can be nil if we received an impulse
    end)
    
    -- stop server
    osc.stop()
    
    
    -- Sending events
    
    osc.host = "localhost"
    osc.port = 9000
    
    osc.send("/", value)
    osc.pulse("/")
    

    Design 2

    -- Adds special parameters to the sidebar which send and receive values to a configured osc client / server
    
    -- Set us up as client
    osc.client("localhost", 9000)
    
    -- Or
    
    -- Set us up as a server 
    osc.server(9000)
    
    parameter.oscFloat("/", function(value) 
        -- Do something with value
    end)
    
    parameter.oscString("/", function(value) 
        -- Do something with value
    end)
    
    parameter.oscInt("/", function(value) 
        -- Do something with value
    end)
    
    parameter.oscPulse("/")
    
  • SimeonSimeon Admin Mod
    Posts: 5,054

    I think if we have the first then we can just write the second directly in Codea and use it as a dependency where needed.

  • SimeonSimeon Admin Mod
    Posts: 5,054

    So this worked pretty well

    OSC could have been built directly in Codea because we have support for sockets. But having a high level API is nice too.

    The code for the server here was:

    function setup()
        osc.start(50000) 
    
        print(osc.host)   
    
        parameter.number("Value", 0, 100)
    end
    
    function draw()
    end
    
    function osc.listen(address, ...)
        if address == "/Value" then
            Value = ({...})[1]
        end
    end
    

    And the client code was

    function setup()
        osc.host = "<local ip>"
        osc.port = 50000
    
        parameter.number("Value", 0, 100, function(v)
            osc.send("/Value", v)
        end)
    end
    
    function draw()
    end
    
  • Posts: 30

    @Simeon
    I like the first api the most as I see how to use it as a building block for my own rich interactions. I think having the api be built in even though one could do it with raw sockets will help in the long run when experience accumulates and timing issues start to surface. I also believe that if it is built in the uptake will be faster.

    Of course something this cool will add more weight to wanting an iPhone version of Codea :-)

    I am very impressed with the turnaround speed on a proposal made just yesterday.

  • dave1707dave1707 Mod
    Posts: 7,809

    Here’s a link to some code that I wrote in May 2017. I used it to transfer projects from one of my iPads to the other using sockets. OSC probably would have made this code smaller and easier to use. I don’t use it anymore because of Files and the iCloud.

    https://codea.io/talk/discussion/8392/project-transfer-ipad-to-ipad#latest
    
  • Posts: 407

    very cool!

Sign In or Register to comment.