Arnaud Loonstra

We propose a combined visual and text-based programming environment based on the actor model suitable for novice to expert programmers. This model encompasses simple communicating entities which easily scale from utilizing threads inside the computer to massive distributed computer systems. Our proposal is very suitable for IOT scenarios, creative coding practices and rapid prototyping. The prototype utilizes zeromq transports and embeds python for easy creation of actors.

Sphactor is currently a research project for a framework for concurrent programming suitable for novice users while maintaining features needed by expert programmers. The library features an actor model at its core and features a GUI application to manage actor dependencies visually and also program individual actors using a classical text based approach.

One of the initial questions for Sphactor was the fact that when students want to access new technologies they often need to be experienced programmers. However this is hardly ever the case. As an example; students need to access motion capture sensors however only an SDK is provided. We can overcome this hurdle by adding some software to make this more accessible. We found that most tools used by students in our academy can utilize the OSC (Open Sound Control) out of the box. Therefore we started transmitting sensor data through OSC. This has proven to be very comfortable for students. We then ran into the situation that for every technology we needed to develop a piece of software to translate its features to OSC. To prevent creating a jungle of tools we started researching how we could create a general intermediate layer between technologies and use OSC as a transport. This is a common question in the IOT world.

Continued research showed us that students, using existing tools and frameworks were hardly ever utilizing all processors in their machines. This is due to the fact that tools they operate are only designed for single threaded situations. Tools utilizing all processors are very rare, especially for novice users. Message passing is one of the fundamental models for concurrent programming and is actually very similar to what we were already doing in our intermediate software layer and in common IOT scenarios when we are processing all our sensor data.

These situation are driving the development of Sphactor. We currently have a prototype ready for testing which we will demonstrate and talk about. Sphactor is being researched by the HKU University of the Arts Utrecht in the Netherlands for use in creative processes and as a educational environment for programming and interacting with new technologies. Libsphactor is developed in C using Zeromq's czmq framework. The gui is done is C++ using an Immediate Mode UI with minimal dependencies.

This research project is a continuation of research which was presented in the FOSDEM IOT devroom in 2015 and 2016.

When everything is connected we can question what programming approach is most suitable. Programming interconnected systems shows similarities to programming for multiple processors. However, programming for multiple processors is a challenging task. We propose and demonstrate an easy framework based on lessons learned from programming for IoT scenarios which shows potential for programming multiple processors as well.

Approaches to program concurrently require a thorough understanding of the computer. Not all people who program possess this. However, as processors are not getting faster, everybody will need to program concurrently eventually. One of the main challenges of programming for multiple processors is the fact that it is often approached from a sequential programming perspective. When dealing with IoT it is usual to send and receive messages thus this becomes the paradigm. This paradigm is one of interacting entities passing messages rather than parsing logic sequentially. Based on these hypothesis we have researched an easy framework to program for multiple processors as well as devices connected through the network. We have tested the proposed framework on a group of Creative Coders which showed it is regarded easier than classical programming.

The framework is based on the ZOCP protocol build upon ZeroMQ which was demonstrated last year.

Trying to control multiple computers in live performances is a challenging task. Often computers intercommunicate using fixed or manually configured parameters. However when projects expand across many devices this is hard to maintain, especially in situations where parameters are prone to change. ZOCP is a new protocol which solves this problem by facilitating flexibility and autonomous configurations in an orchestrated environment.

In this presentation we present the ZOCP protocol which overcomes the situations mentioned below. The ZOCP protocol is designed with the following in mind:

• KISS (Keep it simple and stupid): We want this protocol not be in our way and we want to be able to understand it easily.
• Zero Configuration: The protocol should be able to handle most, if not all configuration by itself. There is no need for setting up specific parameters unless requested, aka convention over configuration.
• Runs on anything TCP/IP: Since TCP/IP is the de facto standard for devices to communicate the technology should be able to run on any device that is able to talk TCP/IP
• Open Standards: All used technologies, software, protocols should be freely and openly available.
• Low latency, when needed
• Reliability, when needed
• Unintrusive debugging and monitoring

As artists embrace new technologies as an artistic medium, these technologies often provide artists with new methods for cooperation. Networking technologies are used frequently for these purposes. Internet has been a driving force behind the development of networking hardware and open standards for connecting any to device to any device. These technologies are now a commodity and thus available for anybody to use. However we see a rising need to be able to implement these technologies in a flexible adaptive manner without the explicit fixed configurations requiring manual configuration.

Open Sound Control (OSC) is a protocol developed for exchanging music performance data. OSC is often used as an alternative to MIDI, however, it has found its way to many use cases besides musical performances. We have found OSC to be an ideal de facto standard for connecting applications to each other in order to orchestrate them. However the flexibility of OSC tends to decrease exponentially when used in large configurations because of its hard-coded nature. This implies that many applications need to be instructed to use specific manual settings and agreements in order for applications to communicate. In large configurations containing multiple systems and multiple applications, this manual work is inflexible and error prone.

The current prototype is developed using the ZeroMQ framework. We will demonstrate the protocol in a setup with Blender, a game engine, an Urwid console monitor and a RaspberryPi.