orchetect / osckit

Open Sound Control (OSC) library written in Swift.

About Me

My name is Steffan Andrews and I hail from beautiful Vancouver, Canada.

I'm a professional composer for film and TV with over 16 years of experience specializing in animated series.

I'm also a life-long coder since 1995. I have helped build numerous commercial Mac applications including Audio Design Desk and Dipper. In my spare time I build and maintain open-source packages for Swift and SwiftUI.

Featured Swift Packages

	MIDIKit Modern multi-platform Swift CoreMIDI wrapper with MIDI 2.0 support.
	OSCKit Open Sound Control (OSC) library written in Swift.
	TimecodeKit A robust and precise Swift library for working with SMPTE timecode.
	SwiftRadix Translate integers to/from radix strings (binary, hex, etc.) using convenient syntax.

Featured SwiftUI Packages

	MacControlCenterUI SwiftUI menu builder DSL & controls that mimic macOS Control Center.
	MenuBarExtraAccess Show/hide SwiftUI MenuBarExtra menu using Bindings.
	SettingsAccess Open your macOS app's Settings scene programmatically without needing SettingsLink.

osckit's Issues

Can OSC support bluetooth?

Thank you for developing such a useful tool. I am wondering if the OSCKit can support Bluetooth communication besides wifi.

Add 3rd-party network layer sample project

Add a sample project that demonstrates integrating with a 3rd-party network library to send and receive OSC.

Ideal candidates:

• Apple's Network.framework
  • WWDC video shows in-depth example code and usage
• Swift-NIO

About local ip address

Hi, Thank you for the amazing toolkit!
My local ip is 10.0.4.10, another PC is 192.160.0.158
My ip 10.0.4.10 cannot be linked with OSCKit, but 192.160.0.158 can be linked.
Do you think it is possibly due to the OSCKit or it should have worked?

Cannot fetch

I suddenly cannot fetch the package from https://github.com/orchetect/OSCKit.
I saw there is a new file folder .github. is it the reason?

Screenshots

Error thrown for Sample project

I'm not sure this is useful, so please accept my apologies.

Loaded Sample project on Apple Silicon Mac, 11.5.1
Sample project seems to not be sending OSC messages, and throws error/s:

2021-08-03 06:11:50.448456+1000 OSCKitExample[19873:530770] [connection] nw_socket_service_writes_block_invoke [C1:1] sendmsg(fd 4, 24 bytes) [61: Connection refused]
2021-08-03 06:11:50.448653+1000 OSCKitExample[19873:530770] [] nw_flow_prepare_output_frames Failing the write requests [61: Connection refused]
2021-08-03 06:11:50.448692+1000 OSCKitExample[19873:530770] [connection] nw_write_request_report [C1] Send failed with error "Connection refused"
UDPClient send error: The operation couldn’t be completed. (Network.NWError error 0.)

Add OSC address pattern matching support

Future addition: OSC address pattern matching

Send Broadcast Messages

• Investigate allowing and sending broadcast UDP messages from OSCClient and OSCSocket
• Add class property to toggle allowing broadcast

No longer builds on Xcode 14 RC 1

Issue

Because of Xcode's pattern of removing beta macOS SDKs in RC releases of Xcode, OSCKit fails to build on Xcode 14 RC 1.

The following API usage fails to compile:

func foo(bar: some BidirectionalCollection<some StringProtocol>)

Resolution

Use older generics pattern.

func foo<S>(bar: S) where S: BidirectionalCollection, S.Element: StringProtocol

The functionality is identical, just expressed differently, and does not change any public API of OSCKit.

ETA

A patched OSCKit release will be out soon.

Add OSC-array type tag support

See OSC 1.0 spec for implementation details.

Send and receive on same port (socket)?

Transferred from Discussions

^{Originally posted by alexford April 6, 2023}
Hello! This is a great library. I have a question about how I would achieve something I'm trying to do:

For my use case, I need to send and receive OSC messages from the same port. I am integrating with a family of mixers (Behringer XR series, as an example), that "respond" to some OSC messages by sending a message back to the same port on the client that the original message was sent from.

So, I am trying to achieve this bidirectional communication by setting up both an OSCClient for sending and an OSCServer for receiving.

The issue I'm having is that when I set up an OSCClient from this library and send an OSC message, the outgoing port is randomly assigned by the OS. The mixer then responds back to that random port. I understand this is part of the behavior of GCDAsyncUdpSocket (and sockets in general), and a side effect of the two "sides" of this library each using their own socket.

I need an OSCServer to be listening on the same port that I send from, but I won't know that port until I send the first message. I have experimented a bit with trying to send an initial message, then interrogate the udpClient in the OSCClient to find the port, then start the OSCServer listening on that port. This required some minor modifications to OSCKit's source to attempt. However, OSCClient's use of GCDAsyncUdpSocket doesn't lend itself to the enableReusePort functionality (something about needing a delegate which the client does not use), so I couldn't get it to work cleanly and would have ended up making too many changes, so I came here for advice first.

Essentially, I'm looking for a hybrid of an OSCServer and an OSCClient that sends and receives OSC messages over the same socket. This is implemented in another library, also called OSCKit as something they call a "peer". However, I prefer the API, approach, and license of this library, so I'm hoping it can be done here as well.

---

Looking at the code, it seems like this could be made to work by basically copying the send function from OSCClient into OSCServer, so that it sends over the same socket the server has already established.

Would it be strange to have OSCServer basically implement OSCClient, though? I'm sure there's a better way to accomplish this without muddying the server/client dichotomy you've established here. Maybe a subclass of OSCServer that adds the send functionality? Looking for your feedback. I am happy to start a PR.

I'm very new to Swift and UDP, so maybe I've missed something obvious, too!

Passcode options not available

let oscMessage = OSCMessage(
"/test/play",
values: ["Test string", 123]
)
do {
try oscClient.send(
oscMessage,
to: "192.168.1.234", // IP address or hostname
port: 60088 // standard OSC port but can be changed
)
}catch {
print(error.localizedDescription)
}

There are no options for using a passcode also some ports are not working for send commands e.g. 60088.
And how we can send message type TCP or UDP?

Please guide me if you know the same.

Thanks in advance.

Add OSC 1.1 Xpath `//` address pattern operator

As per OSC 1.1 proposal, §3.4:

OSC 1.1 inherits the path multiple-level wildcard- matching operator // from XPath.

This overcomes the limitation of the OSC 1.0 * operator that only matches up to / boundaries. It also gives concrete semantics to the string // in an address—which was previously not explicitly forbidden but may have resulted in inconsistent address handling due to ambiguity (e.g., in UNIX style path operations // is a no-op equivalent to /).

Implement async/await

• Triage the codebase and look for candidates that could be refactored to use async/await.

Add Bonjour advertisement support in `OSCServer`

As per the OSC 1.1 proposal, §5.2:

Services available over IP networks can be located with DNS-SD (aka Zeroconf). These may be listed as protocol _osc._udp or _osc._tcp (with reservations, users may wish to register their own protocol that simply uses OSC). The attributes given in Table 4 are specified in the TXT field for DNS-SD, e.g. suppose we have a bidirectional endpoint over TCP at port 5000:

_osc._tcp.localhost:5000
    txtvers=1
    version=1.1
    framing=slip
    uri=http://myapp.com/
    types=ifsbhdu

Add timetag support

• Future feature: OSC timetag handling.

Temporal Semantics and OSC Time Tags

An OSC server must have access to a representation of the correct current absolute time. OSC does not provide any mechanism for clock synchronization.

When a received OSC Packet contains only a single OSC Message, the OSC Server should invoke the correponding OSC Methods immediately, i.e., as soon as possible after receipt of the packet. Otherwise a received OSC Packet contains an OSC Bundle, in which case the OSC Bundle's OSC Time Tag determines when the OSC Bundle's OSC Messages' corresponding OSC Methods should be invoked. If the time represented by the OSC Time Tag is before or equal to the current time, the OSC Server should invoke the methods immediately (unless the user has configured the OSC Server to discard messages that arrive too late). Otherwise the OSC Time Tag represents a time in the future, and the OSC server must store the OSC Bundle until the specified time and then invoke the appropriate OSC Methods.

Time tags are represented by a 64 bit fixed point number. The first 32 bits specify the number of seconds since midnight on January 1, 1900, and the last 32 bits specify fractional parts of a second to a precision of about 200 picoseconds. This is the representation used by Internet NTP timestamps. The time tag value consisting of 63 zero bits followed by a one in the least signifigant bit is a special case meaning "immediately."

• http://opensoundcontrol.org/spec-1_0

Add custom OSC-type tags

While discouraged by the OSC spec, custom (proprietary) OSC message type tags are possible.

Would be a nice feature to add to the library, but low priority.

Add example project using CocoaAsyncSocket

Add an additional example project demonstrating use of CocoaAsyncSocket.