What about your package manager?

That's exactly what I was looking for, thanks!

Messing with ofelia's examples I'm trying to figure out how to send a string arriving via OSC in a Pd patch into ofelia's inlet and display that in its window.
The examples provided either have hard-coded strings or the stuff displayed are being created inside the Lua script.

[tabread4~] just reads an array, You feed it an index and it outputs the value at the given index. In more detail, [tabread4~] does a four point interpolation when receiving floats, because these values are in between indexes, since indexes are integers (you don't get an index 1.5). That's all. [phasor~] is multiplied by the size of the array, so it outputs a ramp from 0 to the size of the array, and that is an incrementing index for [tabread4~].

If you want to add randomness, you can modulate the frequency of [phasor~], or use another oscillator, possibly wihth FM or PM (phase modulation).

[tabread4~] is not ready made to playback audio. You need something to drive it, and most of the times that's [phasor~]. [phasor~] is a ramp going from 0 to 1 in the frequency specified either as an argument or through input in its left inlet. If you multiply its output by the number of elements of the array [tabread4~] is reading from, then you get whatever is stored in that array. In order to hear it at proper speed, you need to divide your sampling rate by the number of samples of your audio file (the number of elements of the array), and that will be the frequency of the [phasor~].

So, to answer your 2nd question, [phasor~] is not a sound signal, it's just a ramp which is used as a driving force. If you use another sound signal to drive your playback with [tabread4~], you're going to get a playback with variable speed that will go forward and backward.

Hi,
If you're using the default exaples from GitHub, and you're using [serial_print], then you're using a 9600 baud rate. You can change the baud rate to 57600 or 115200 to get better results.
Bear in mind though that using Serial.print() is significantly slower than Serial.write(), cause the later sends raw bytes, while the former translates everything to its ASCII values. So, if you want to sent the value 100 with Serial.write(), the Arduino will just send one byte, whereas with Serial.print() it will send three bytes, the values 49, 48, 48 (ASCII for 1, 0, 0).

Can't you just edit the crontab and open the patch from there with the appropriate flags?
Type crontab -e which will prompt you to choose an editor (nano will be the default, better use that one). Scroll to the end of the file and type this:
@reboot sleep 20 ; pd -nogui -audiodev 3 -open /path/to/patch.pd &
This will force the Pi to launch Pd without the GUI, choose the third audio device (first is Pi's default audio hardware, second is default audio plugin, third should be any sound card connected as hardware), and open your patch. The ampersand (&) tells the Pi to run Pd in the background so you can still do things with it in the terminal.

Once you type this, hit Ctl+O to save the file and hit return as you'll be asked to save the changed you made. I'm pretty sure this will work.

Thanks for making this, it's an amazing library!

What does Arduino's power supply have to do with the current the relay will let through or not? A relay is an electronic switch which receives power (usually of high voltage) and has three more pins, one for 5V, one for ground, and one to control the actual switch. These three pins are the ones you connect to the Arduino, and Arduino's 5V pin is more than enough to power the digital part of the relay. The high voltage the relay will let through or not has nothing to do with Arduino's power supply and digital control.

Don't know what you're trying to do, and can't really understand the conversation, but thought I post these couple of things I know about relays.

Why would you damage the boards? I don't think relays have changed in the way they work, since 2011. What is this that you find and don't trust?

Try this:

[phasor~ 1]
|
[threshold~ 0.1 10 0.1 10]
                         |
                        [o]

The bottom object is a bang

My suggestion was for when you boot up the Pi only. If you're opening Pd patches through Python, you should replace the command that launches Pd with a command that launches your Python script and open Pd from there. In that case you don't need to wait 30 seconds every time, only at boot time for the Python script to launch.
But why do you have to quit Pd and restart it? Can't you just close the patch and open a new one? There are internal messages in Pd that can do that.

Using controller names like 'Pure Data' instead of 20, is more consistent, since these numbers are subject to change, depending on when you plug in a device, so I suggest you go for the names of the controllers and not their values.
You can do the following in a file:

#!/usr/bin/sh

pd -nogui -alsamidi -otherflags &
sleep 3
aconnect 'Controller':0 'Pure Data':0
aconnect 'Pure Data':1 'Controller':0

This will automate the process of launching Pd and connecting it to your controller via ALSA MIDI.

Then you can run this script from crontab. Type crontab -e (if it's the first time you edit crontab you'll be asked to choose an editor and will be prompted to use nano - I suggest using that if you're not familiar with other editors like vim) and at the end of the file type:

@reboot sleep 30 ; sh /path/to/your/script/script_name.sh

This will launch your script 30 seconds after the system boots.

You can try this out:
launch Pd with -alsamidi
typing in a terminal aconnect -lio will give you a list of all MIDI devices
find your controller and Pd's MIDI input port and type
aconnect 'Your Controller Name':0 'Pure Data':0
Note that if your controller is not a single word, you need the single quotes, the same way 'Pure Data' is written. 0 is your MIDI controller's output port and Pd's input port. These depend on your system, so make sure you fill in the correct numbers there.

check in Pd that you get input from your controller, it should work.

Glad you found it useful!

@LiamG have you benchmark tested the CPU consumption of 50 sine waves? Cause [osc~] is a table look-up oscillator and it shouldn't consume too much CPU. If Pd can't handle 50 table look-up oscillators, then it's probably no good.
Haven't done this benchmark test, but I'm pretty sure it shouldn't be a problem.

What if one of the values you send with Serial.write() get the value 10 or 13? Your system will get confused. You need to work on this system a bit more. You can use the [serial_write] and [serial_print] abstractions I've made which you can find here. Mind that in some systems (mine, for example), [comport] reads a 10 when the Arduino sends a 13. I have made a fix for this for the [serial_print] abstraction, which is the [serial_print13] abstraction, haven't made a fix for [serial_write] yet. Still, it's very likely you won't have that problem. Read the README.md file.

For more in-depth information on how to build such a system, you can also read my "Arduino for Pd'ers" tutorial, which you can find here, under "Tutorials". Though this tutorial was written before I made the [serial_*] abstractions and it's a bit more technical on how the whole mechanism works.

You can also use Pd's native objects, [oscformat], [netsend -u -b], [netreceive], [oscparse], no need for external libraries.

This message should't be a problem, it's quite often there. As long as you hear your sound card OK, then it's OK. If using ALSA doen't seem to work, give Jack a try.
It's weird, but using Jack with the ALSA driver most of the time works smoothly, while Pd with ALSA alone could have issues. At least to my experience.

On the 1st of September, I'll be giving a workshop on Pd + Arduino at the electropixel#8 festival, in case you're interested.
http://electropixel.org/alexandros-drymonitis-pd-arduino/