Using Pixelbone with Pure Data

giuliomoro

But there is no response/feedback, is that correct?

Yes. That makes it run as a service in the background, so you can see its output with:

journalctl --boot -fu O2L

(do it in a proper terminal, not in the console at the bottom of the IDE).

Once that's running, you forget about that project and just send OSC to port 7562 from any project.

For instance, you could run a project with local.pd in it, just renamed to _main.pd, then when running that project, anything you send into the board's audio inputs should make the same visualisation you've seen so far when running it remotely.

Knallberto

Thanks, it's working now.

giuliomoro

great, sorry it took a while. I should have just tested it to start with.

Knallberto

I have a Pure Data patch working now to control multiple pixels simultaneously, but I encounter the problem that some updates don’t seem to get through — some pixels are not set on the first try, but after re-triggering (rebanging) a few times they all eventually update.

Here’s the setup:
I want to control several pixels at once (not necessarily consecutive).
In an abstraction I generate a list of messages, one for each pixel.

Example:

0 255 1 1 0;
1 255 1 1 0;
5 255 1 1 0;
...

Each message goes into [oscformat leds setRaw rgb] and then to [netsend -u -b].
The receiving side is a Bela board running PixelBone (O2L).

The issue:
When sending around 10 messages at once, some LEDs don’t react. If I resend the same set of messages a few times, they eventually all update. I want to be able to control a total of 100 LEDs.

My questions:
Are these too many OSC messages to handle at once when using UDP?
Is Pure Data (or Bela) dropping packets when I send such a burst?
Is there a way to make this more reliable?

giuliomoro

try the updated pixelbone branch, see if that works?

Knallberto

I downloaded the pixelbone branch and uploaded it on Bela. When I run it, I get:

Building project ...
Build finished
Running project ...
pru_init: PRU 0: data 0xb6c22000 @ 8192 bytes, DMA 0xb6ba2000 / 9f6c0000 @ 262144 bytes
OscReceiver: Unable to initialise UDP socket: 98 Address already in use

Not sure if this means that the old version is still running? Like this the problem persists.

giuliomoro

You need to do:

systemctl restart O2L

Knallberto

Thanks, it seems like nothing changed with the problem. I attatched my PD file that generates the messages.

constellation-ctrl.pd

3kB

constellation-ctrl-help.pd

1kB

neopixel-constellations.pd

3kB

The main file is neopixel-constellations.pd

giuliomoro

Please grab the latest pixelbone branch and try again.

The fastest way to work with this is to have it run in the foreground as part of the IDE:

systemctl stop O2L

and then build and run from the IDE. When you are happy with the results, do:

systemctl restart O2L

and it will run in the background again.

Now, if running it in the IDE you still think you have dropped messages, see the message counter that is printed and create a similar counter on the Pd patch and compare the two.

When I test your patch, if I send 200 messages at once, they seem to be all received, and processed within a couple of seconds. When moving a slider connected to a 20-item constellation_ctrl, I get some 140 messages, all properly received (even if slowly: I don't think what you are seeing is the result of dropped messages.

Still, you are doing it in a very inefficient way. Each message you send has a cost on both sides and you may be pushing it by sending 20 with a single click. A more efficient way would be to populate an array with all the values you need and then send that over as a single message, even at a constant rate of 20 or 30 or even 50 times per second.

Knallberto

Thanks for the reply.

When I use this and I send 10 messages (one "burst" of the first constellation abstraction) I get:
Message 0 from 192.168.6.1:23766; /leds/setRaw/rgb Message 1 from 192.168.6.1:23766; /leds/setRaw/rgb Message 2 from 192.168.6.1:23766; /leds/setRaw/rgb Message 3 from 192.168.6.1:23766; /leds/setRaw/rgb Message 4 from 192.168.6.1:23766; /leds/setRaw/rgb Message 5 from 192.168.6.1:23766; /leds/setRaw/rgb Message 6 from 192.168.6.1:23766; /leds/setRaw/rgb Message 7 from 192.168.6.1:23766; /leds/setRaw/rgb Message 8 from 192.168.6.1:23766; /leds/setRaw/rgb Message 9 from 192.168.6.1:23766; /leds/setRaw/rgb
in the console. This seems to be correct. But when I try this with a gain value of 255, the first time only some LEDs light up and when I resend the same message more LEDs light up. As long as I sent those single "bursts" of messages my count in PD and in the console correspond. But, when I move the slider, the counter in PD gets higher than the counter in the console. For example, when I move a 20-item slider, I get 120 in the console but 500 in PD. When I set the color (sending every pixel one time - 100 messages), the Bela console gets 80.
This seems to be a problem, but even the messages that seem to get send correctly do not control the neopixels as intended. Any idea what might be the cause?
Edit: In my setup I tried to use a "level converter" https://www.reichelt.com/de/en/shop/product/developer_boards_-_ttl_logic_level_converter_3_3v_5v-282702 - when I stop using it and send the Pin output directly (with a 220Ohm resistor) to the Neopixel it seems to work better (is this not a good device for this?). This means maybe the problem is only sending too many messages.

A more efficient way would be to populate an array with all the values you need and then send that over as a single message

Do you know how to create such an array in PD?

giuliomoro

Knallberto Do you know how to create such an array in PD?

Create an array and store your values there with [array set], then get the values with [array get]. In the array you would have to store the values with the desired gain. E.g.: if you have a color [1 1 0( that you want to have with gain 100, you'd have to store [100 100 0(. This way you can read from the array and send all with a single /led/setRaw/rgb message, with gain 1.

giuliomoro

Knallberto Edit: In my setup I tried to use a "level converter" https://www.reichelt.com/de/en/shop/product/developer_boards_-_ttl_logic_level_converter_3_3v_5v-282702 - when I stop using it and send the Pin output directly (with a 220Ohm resistor) to the Neopixel it seems to work better (is this not a good device for this?).

I am not sure why this wouldn't work, but if it works without, then you are probably fine without.

Knallberto For example, when I move a 20-item slider, I get 120 in the console but 500 in PD. When I set the color (sending every pixel one time - 100 messages), the Bela console gets 80.

Going above 100 messages at once is likely to cause trouble. I also noticed that by sending more while the queue is still processing on the board will inevitably lead to lost messages. But sending a message with over 100 elements 30 times per second seems pretty reliable, so try that.

Knallberto

giuliomoro
Thanks, just to confirm I get this right: I would keep an array with the values for all 100 LEDs, update only the entries that change, and then use [array get] to send the complete array at a constant rate (e.g. driven by a [metro] object)?

giuliomoro

yes, exactly

Knallberto

Thanks, this is working now. I had to Start the Array with 0, 1 and then add the RGB values for all 100 LEDs.

Knallberto

Thanks again for the amazing help. I got it working now really nice.
Next, I wanted to implement the same volume controle for headphones and speakers as in my other project https://forum.bela.io/d/6968-using-arduino-with-bela-pure-data/19.
I tried to implement it exactly the same way, but when I try to change the Line Out Level, I get a lot of crackling noises on the speaker and a lot of those messages:
Underrun detected: 13 blocks dropped Underrun detected: 13 blocks dropped Underrun detected: 13 blocks dropped Underrun detected: 10 blocks dropped Underrun detected: 13 blocks dropped Underrun detected: 13 blocks dropped Underrun detected: 13 blocks dropped
I do not get this problem controlling the headphone volume. Any idea what might cause this?

giuliomoro

Controlling both volumes is not a real-time safe operation, so those underruns are expected. I am surprised you only get them in one case and not in the other.

If you are doing these adjustments only occasionally, you may be able to avoid any noise by setting your output to 0 (via a [*~] just before the [dac~] for a few ms before you attempt the change. If you need to be able to do these smoothly and often, then some more work is needed on the C++ side.

Knallberto

Thanks for the quick reply.
Ok, I will try this. The difference also was that the headphone control worked (in controlling the actual volume) and the amp control did not work.
In my guitar patch I had no problems, but there I did a lot less controlling. This is why I thought maybe it’s connected to controlling all the neopixel?
But I will recheck if I did anything different here accidentally when I get back to the project after the weekend.

giuliomoro

So you mean that sending to bela_setLineOutLevel causes the underruns but has no effect on the speaker level?

it's weird that the one working (headphones) does not cause underruns but the one that doesn't work (line) does cause underruns.

Knallberto

Hey, yes but I had some problems because I had the PD patch open on my laptop and at the same time on the bela and my laptop seemed to send neopixel data as well to the Bela. Now the volume control is working and with turning off the volume in PD before changing the amp volume is working, not perfect, but ok. Thanks!