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.

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.

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. :slight_smile:

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

@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("/")

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.

So this worked pretty well

https://twitter.com/twolivesleft/status/1081936384900816901

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

@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 :slight_smile:

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

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

very cool!