SC on a microcomputer with sensors

Questions
1

Dear lists,

I want to ask the best devices for my current project before I buy some products:

  • Primary Machine: MacBook Pro.
  • Secondary Machines: Multiple Microcomputers Such as Bela, Raspberry Pi. There should be at least eight secondary machines. The maximum number of secondary machines is open.
  • All machines should be connected via one or more network devices by using Ethernet cable and Wi-Fi. The primary machine should be able to send OSC to each secondary machine and vice versa; The primary machine should receive OSC from each secondary machine and vice versa.
  • Each secondary machine should have at least mono-channel analogue audio output (more robust than 2 Watt. The louder output, the better result!)
  • Each of the secondary devices should attach at least one distance sensor, and the values from the sensor should be read in SuperCollider (or puredata).
  • Each secondary device measures the distance between the sensor connected to itself and a visitor (or some visitors) in an exhibition space. The measured values should be read in real-time within SuperCollider (or puredata locally) on each device. SuperCollider or puredata will use the values from the sensor to locally control the sound, and some values should be able to send to the primary machine. The SuperCollider, puredata or Max should be able to control each SuperCollider (or puredata) on secondary machines to produce sound using the received values from the distances between each sensor on each secondary machine and visitors.

If you suggest one from Bela or Raspberry Pi or something else for my current project, I would like to know the following thing:

  • Recommended product lists of proximity sensors that work without issues when using it with Bela or Raspberry Pi.

I could set up the same feature with a computer, an audio interface, and many Arduino boards. However, the USB cable lengths among the laptop and Arduino boards could be very long as well as the lengths of the wires from an Arduino board to a sensor could be relatively long. Thus, I am thinking about using RP or Bela to reduce time in installing devices.

I really appreciate any help you can provide. Sharing your own experience will help me very much!

Best regards,

2

Perhaps consider wifi shields on the Arduinos, etc? I’ve done this a number of times and it is very effective and easy to set up a simple server.

3

Thanks!

Arduino with WiFi is a possibility.
However, I think WiFi is not reliable on stage or in an exhibition hall.

I have this-regarded several experiences:

  1. I sent some messages using OSC over WiFi in my recent project.
    The messages are from MIDI messages as follows:
    – note-on velocity MIDI pitch number
    – note-off velocity MIDI pitch number
    Regretfully, some messages were often not delivered from the sender to the receiver in an exhibition hall, even though it worked perfectly at my home.
    I could resolve the problem by connecting the two computers using an Ethernet cable.

  2. I made an automatic page-turning score (from png files) using SuperCollider on five laptops.
    They had wirelessly to run; regretfully, page-turning moments were often and irregularly not delivered.
    If I remember correctly, I resolved the problem by sending the actual page number multiple times per second to other computers.

Using WiFi for the project in my question might be reliable to measure the distance between a sensor and a human because the value is frequently sent to the main computer. I will consider it.

4

Yes I’ve had similar issues - without a better way to describe it, the OSC messages would sporadically get “clogged” for 30-60 seconds, and then all arrive at once.

Teensy can send MIDI messages, and you can attach it to a raspberry pi, or your laptop. I’m not sure about what sensors you would use, but this project looks like it might help: https://prynth.github.io/create/framework.html

5

What was your wifi setup? I have frequently sent OSC over wifi using an old & fairly cheap TP-Link wireless router connected to main computer by Ethernet, set up as a private network so audience can’t get on. It has been reliable from ~60-80 feet away, across 200-300 audience members, even from behind some curtains. (I’m not an expert at all just some anecdotal success)

6

I’ve used ESP8266 controllers (programmed with Arduino environment) which have WiFi built-in and I’ve run them for hours at a time, with data rate of 100-200Hz. Occasionally I’d get data dropouts (counted in ms, not seconds), so I wouldn’t depend on a single message to do something, but in general this worked reasonably well for continuous data. Note: I’ve tested this over hours, not days.

Setting up your own WiFi network is the key. To minimize the packet loss I had my router connected over WiFi to my computer, and sensors connected over WiFi to the router. I also would scan the environment for the wifi channels with least networks on them. Channels 1, 6, and 11 are the non-overlapping ones, and thus possibly the cleanest (if there’s no other network on them).

I know this doesn’t meet the original criteria of “process sensor data and make sound on the device” but I thought I’d pitch in on the networking aspect of it. YMMV but I wanted to share my experiences.

8

We had a similar setup with a dozen Pi 3B wired up through ethernet, even sending audio via ethernet in addition to OSC. This worked basically fine, but the Pi 3B is really at the lower limit for this kind of stuff; prepare for some frustration with freezes and such, especially during development. The Pi 4 is a lot more capable, I think also the 1 GB RAM of the Pi 3B is a problem, so I think the sweet spot is Pi 4 with at least 2 GB RAM, perhaps go for 4 GB and you won’t curse in future projects. Beware that the prices are quite up at the moment, and many large distributors ran out of Pis, seems Element 14 has issues satisfying demand, so may need to look around to find stores that have them in stock.

Cannot really say anything about high power audio output, only that the C-media chip based “USB stick” stereo interfaces at 5 EUR or so are quite capable. I think the Bela only makes sense when you need low latency, so it will depend on whether you need quick feedback’ish or live electronic processing. Otherwise stock Pi is fine, and the big plus is you have a regular linux OS.

Getting distance sensors might be the most difficult part, especially if they need to work at different angles etc. Threshold based motion detection is a lot easier and cheap with PIRs. Analog sensors on the Pi have the disadvantage against Arduino that you need to add an A/D converter as well, and possibly a Logic Level Converter between 3.3V and 5V.

9

I’ve had similar experiences. UDP over WiFi does drop packets. If it’s your own private network, it will probably drop fewer of them, but there aren’t any guarantees.

It can be good enough for a lot of applications (e.g. streams of data in multiple messages) but there’s no magic bullet to make UDP+WiFi never drop messages.

hjh

10

@MarcinP and @Eric_Sluyter were you using UTP instead of UDP to improve the wifi dropout rate ?

@prko if you have already finished the project, can you share the details of the solution that you have adopted ?

11

In a scenario of a main laptop computer connected with several satellites raspberries pi, is it possible to precisely set the grid moment were the execution will occurs (taking the amount of latency that is necessary) ? Is a external master clock or something like this needed?

i.e. guarantee that both these synths will be played precisely tied to a main master clock?


~pi1= Server(\pi1, NetAddr("192.168.0.21", 57110)).makeWindow 
~pi2= Server(\pi2, NetAddr("192.168.0.22", 57110)).makeWindow 

Ndef(\noise -> \pi1, { WhiteNoise.ar(0.2) }).play;
Ndef(\sin   -> \pi2, { SinOsc.ar()*0.2 }).play;

Is Ableton Link the way to go?

12

Do you mean TCP instead of UDP?

I was using UDP since TCP would introduce more timing jitter and possibly higher latency, is more likely for packets to arrive out of order etc. That’s the “price” for TCP’s reliability. Also, sclang doesn’t provide a TCP server.
I used it for streaming continuous data of motion sensors at up to 200Hz so a few dropped packets here and there were not a big issue. But sending a single message, like button press, might get lost. And if you need to transmit an accurate signal e.g. for frequency analysis, the “few dropped packets” might indeed be a problem.

1 Like
13

I have also used UDP. Maybe once in a rare while a button press would be lost but I used the “off” message as added security, and for continuous data never a problem.

1 Like
14

hahaha yes, sorry for the human typing protocol

15

I once heard a joke about UDP, but you might not get it.

3 Likes
16

Thank you very much for your kind answers.
I am still configuring the setup environment.

For getting strong sound, I currently use TPA3116 mono amplifier: https://www.aliexpress.com/i/33035844633.html
It can receive unbalanced signals as well as balanced signals.
In SuperCollider, I can send a balanced mono signal as follows from stereo output of Bela, Raspberry PI and stick PC:
play{SinOsc.ar*[1,-1]}

Raspberry Pi, Bela and Windows-based Stick PC seem to be appropriate for my project because one or two distance sensors to detect the audience, a microphone, and a loudspeaker have to be connected to each microcomputer.

There are also possibilities using devices with batteries. However, I excluded them because batteries are not ideal for long-running installations. Moreover, I would like not to use too many cables to reduce the installation time.

In this regard, the advantage of Bela is excellent. Each Bela unit can be controlled on the PC connected solely via USB when connecting multiple Bela units simultaneously without an Ethernet connection. A USB connection provides power and networking!

On Raspberry 4B, it is not clear. It would be great if each Raspberry PI 4B could be controlled on the PC connected via USB when connecting multiple Raspberry PI 4B simultaneously without an Ethernet connection. However, I could not find a clear answer related to it.

The problem is the length of the USB Cable. According to my own experiences, a USB extender does not always work, even though I use the same cables with one USB device. The order of cables affects as well. It is bizarre.

The disadvantage of Bela is that there is no case for it. Bela Mini does not have any holes to adhere itself…

In South Korea, there are currently no distributors for Bela units, so getting Bela units requires a long time. Buying Raspberry Pi is limited by some point in the next year. Stick PC might be a solution, but finding USB-distance-sensor working on it is not easy. I have contacted <maxbotix.com>.

Like this, there are some advantages and disadvantages…
Perhaps, I should use all of these devices partly.

I will upload a documentary video onto YouTube this December.