Author Topic: OSC  (Read 3429 times)

Offline azslow3

  • Administrator
  • Hero Member
  • *****
  • Posts: 1188
« on: May 31, 2014, 01:48:34 PM »
OSC (Open Sound Control) is a flexible protocol to transfer structured information. Interesting information as well as the standard itself can be found at

Using OSC instead of MIDI for communication with Control Surfaces has several major advantages:
  • No "MIDI bridge" an so less components in the chain
  • Unlike MIDI, OSC supports unlimited number of hi precision controls. MIDI in general is 7bit oriented, only 16 simple messages pro MIDI port have 14bit precision. 32 14bit controls can be implemented using 2 messages per value (CC14), for greater number of hi precision controls  4 messages per value are required (RPN/NRPN).
  • most important for me: arbitrary text can be transfered standard way. MIDI has no such standardization, different devices use proprietary SysEx messages for that
In current version, AZ Controller implements some part of 1.0 specification throw UDP/IP networking. While it should work with any OSC capable software controller, I have tested it with TouchOSC for Android and partially with SurfaceEditor on Linux. The only unsupported control is XY, all other controls can be used for bidirectional communications.

OSC activation and configuration in AZ Controller
OSC is Network based protocol. AZCtrl support UDP/IP OSC transport only. That means stable network (IPv4) should be pre-configured on both devices. Without blocking or NAT firewalls between them since UDP based OSC implementation in Apps I have seen can not traverse throw NAT, AZCtrl will "see" your controller but will not be able to reply to it.

The "Options" Tab of AZCtrl User Interface has OSC section. Initially any preset has OSC disabled, that you can recognize by "Not enabled" status in that section.

To activate and/or (re)configure OSC, press "Configure" button in the OSC section. There are 4 parameters:
  • Server port. The port number on which AZCtrl will listen for OSC messaged. On the OSC App side, it is referenced as "Outgoing"/"Peer"/"Server" port. This port should not be used by other application on this computer.
  • Clients port. AZCtrl will send messages to this port when communicating with Clients (OSC App). On App side, it is referenced as "Incoming"/"Listening"/"Own" port. It can be numerically equal to the Server port, but only in case OSC App is not running one the same computer.
  • Fixed client. Normally OSC Client initiate connection to AZ Controller and so its address will be known as soon as the first message arrive. But some "clients" was not thought to be clients (f.e. some Digital Mixers) and so AZ Controller should initiate the connection. In this case, enter IP address or (resolvable!) network name of such device. Note that in that case you normally have to implement some initiation protocol (device specific) within AZ Controller configuration. May be also regular "ping" is required to avoid communication interruption (see your device documentation)
  • Do not use bundles. OSC protocol support "packing" several messages into one network packet. That reduce the number of packets and reduce network and processing load. Unfortunately, not all OSC clients support that (especially hardware, like Digital Mixers). If your device/app f.e. not updating initially or when you move WAI (so when several parameters are sent at the same time), try to check this flag
8000/9000 default values should in general work in most cases, till you have some OSC to MIDI bridge working in parallel.
There is no client address configuration. AZCtrl is looking for incoming OSC messages and remember up to 16 client addresses. It is always sending to the specified Client port since from experience clients are not sending from the port they are listening on (AZCtrl does). That also means that all clients should have the same incoming port.

AZCtrl try to guess its own name/address and display the result in the "Host(guessed)" section. That is what should be copied to the OSC App configuration field referenced as "Host"/"Server"/"Peer".

Note that AZCtrl does not support ZeroConf(Bonjour) automatic service discovery at the moment, even in case it is installed on the computer. Please reference your OSC App documentation to find where and how configure it manually.

To enable OSC, check "Enabled" box. You can disable/re-enable it any time. I would recommend to disable it which your computer is connected to untrusted public network till you carefully tuned your Windows firewall.

The option "Do not show unknown messages" should NOT be checked initially. You will not see any OSC messages otherwise. See the explanation in the "Assigning OSC" section later.

The module support "MIDI via OSC" feature. Initially disabled, it supports OSC 1.0 defined MIDI transfer as well as alternative byte ordering in it. When the feature is enabled, all OSC clients will also receive a copy of "MIDI" messages normally sent to the MIDI output. SysEx messages are recognized/transfered by "/sysex" address and valid text representation of the message ("F0"..."F7"). Received messages are displayed as MIDI in the "Last MIDI Event" (not as OSC). If the client does not understand the format AZ Controller use, try to set another protocol. Note that the feature is implemented for MIDI based software surface emulators, not as general MIDI<->OSC bridge.

Press "Ok" button to apply any changes. Note that in case ports are specified incorrectly, this button is disables.

As soon as you activate OSC in AZCtrl, it tries to be a network server! You can(will) get warnings/questions from your firewall service. In case you reject the request during answering on such question(s), AZCtrl OSC will not work.

From system perspective, AZCtrl is a part of Sonar. So the warning/question will mention Sonar, not AZCtrl. That is expected.

Under no conditions AZCtrl, with or without OSC activated, tries to access anything in the Internet. It should just reply to incoming OSC messages. If you see such Sonar activity, it is NOT coming from AZCtrl (many other plug-ins and Sonar itself are regularly try to "call home").

Once OSC is enabled and the configuration dialog is closed, you should see "Active, 0 clients" as the status.

If you see "Port in use" that can have 2 meanings:
* if that happens right after you restarted Sonar (normal or crash) with AZCtrl/OSC activated before, wait up to 1 minute. The system can block port reactivation, AZCtrl will continue to try establish the service on its own.
* if after 1-2 minutes you still see that status, some other service is using the port. Open configuration dialog again and try to change it, for example to 8001. Do not forget to update OSC App configuration once you found working number

If you see "Failed", try to restart the computer, check your firewall settings, check that you have working IPv4 network. Feel free to contact me in case you can not solve that problem.

If you configured your OSC App correctly, once you move/press some control your should see "Active, 1 clients" in the status.

In case your are running Sonar continuously but your network gives different addresses to the same device you use for OSC App, the number of clients can increase up to 16. You can "clean up" clients but "Forget clients" button any time, that will not stop the service. But after such cleaning, touch/move something in your OSC App so AZCtrl remember it again (otherwise AZCtrl do not know where to send feedback information).

AZCtrl can work with up to 16 clients in parallel. All feedback messages are sent to all known clients. But that does not enforce the same view on all OSC Apps (not even the same kind of OSC App software). Ethernet/good WiFi has huge throughput compare to the information even big AZCtrl preset can send, also AZCtrl tries to send the feedback using minimum number of network packets  (using OSC "bundles"). In case you experience some delays/jitters on OSC App side that is probably due to bad WiFi conditions or some other parallel WiFi activity (like TV live streaming). For comparison, standard MIDI has 3,000 bytes per second throughput, speed below 100,000 bytes per second was normally reported as "not working at all" even with oldest WiFi (802.11b), Ethernet provides at least 1,000,000 bytes per second (modern - up to 1,000,000,000 bytes per second!). So, it is hard to saturate these channels by something happily working throw MIDI (most hardware surfaces).

Assigning OSC messages to controls
OSC messages can be assigned to Logical Controls the same way as MIDI messages. There are dedicated buttons for that in the Hardware Tap, which are enabled once (de)assignment is possible. You should see OSC message which is not yet assigned in the "Last MIDI event" frame to be able to assign it. You can also see current assignment there (unlike MIDI messages, it is not currently included into the Logical Control automatic name, so for orientation I suggest to use the same name for Hardware Control in case it is dedicated to OSC).

Multiple clients can send message with the same OSC address. AZCtrl will interpret them as coming from the same client. And since it broadcast outgoing OSC messages to all known clients, that should work as expected (several clients can work in parallel).

Sending OSC messages
See corresponding manual section for the OSC action.

All messages are sent to all known clients. To avoid extra traffic, use "Forget clients" button in the Options tab if you think there are too many clients which no longer exist (for example, when you see "Active, 2 clients" while you know you have only one). But as explained before, that should not be a big problem if your WiFi network is stable.
« Last Edit: January 27, 2018, 05:36:42 PM by azslow3 »

Offline azslow3

  • Administrator
  • Hero Member
  • *****
  • Posts: 1188
« Reply #1 on: May 31, 2014, 01:48:35 PM »
About networking
The following is not OSC nor AZCtrl specific, but can greatly influence your experience with that technologies.

I strongly recommend separate WiFi router even in case your computer (notebook) has own WiFi adapters. Most such adapters have hi latency drivers and can distort Sonar audio operations. Ethernet drivers are normally much better in that respect.

In the WiFi router I recommend assign fixed addresses to all your devices, especially for the computer running Sonar. Even in case you use DHCP. Otherwise your devices will periodically get different addresses. Otherwise current communications can be interrupted (sometimes with strange side effects) and you will be forced to reconfigure OSC client (in case Sonar network address is changed).

If you follow previous recommendation, statically set the address (and other network parameters) for your Sonar PC. That will avoid periodic address validation and so unnecessary system background activity. Unfortunately, you probably will be forced to use IP address in the configuration of your OSC client since routers normally "forget" the name association in case address revalidation is not happening (if you no longer can "find" your Sonar PC by name, check OSC "Configure..." dialog in AZCtrl. Probably you will see IP address instead of name, with the meaning your router is no longer resolving the name).

At least with my phone I have small problem... 50% of the time inbound packets are delayed but 0.5 - 2 seconds (while outbound packets are sent instantly). Making my telephone sleep and then wakeup magically solve the problem (till the phone put into sleep again, after that the effect can reappear). I am not sure either that is my phone or OSC App related, but I think that was worse to mention (I have seen at least one report in the Internet about the same problem, with the same OSC App but probably with different phone). Note that even when "bugged", the communication is still usable, just not perfect...
« Last Edit: April 25, 2016, 05:09:24 PM by azslow3 »