Hi,

I’m new to raspberry pi and am trying to run Pure data on it to control a teensy 3.2 using Open Sound Control which in turn controls some stepper motors for a pump just like here https://github.com/DropletKitchen/pumpsn17 (using the teensy code and PD files provided at the end of the page). I’ve finally managed to install PD extended on my raspberry pi 3 (Raspbian Jessie). But I don’t think PD is able to use the USB to communicate with the teensy, since if I try to run the PD file, PD gives me the error “could not open device /dev/ttyS0: failure(13): Permission denied. Could someone help me please to get PD communicating with OSC through my USB?

Also when I open PD I get this message
“/dev/dsp (read/write): No such file or directory
(now will try write-only…)
/dev/dsp (writeonly): No such file or directory
/dev/dsp (read only): No such file or directory”
and
“Audio I/O stuck… closing audio”
Do I need to do some further configuration to get Pure Data running properly?
Like I mentioned I am very new to using the raspberry pi so any help would be appreciated and please do explain as if I were an idiot, that would be very helpful.
Thank you

Hello everyone,
I've been working lately with puredata and python together using python as the brain of the system and puredata as the audio engine. For the moment I've been successfully sending messages from python to puredata thanks to this tutorial:
Make Python and Pure Data communicate on the Raspberry Pi

Now I want to reverse the process sending float values from puredata's vumeters to python and then represent them in led vumeters that are connected to the raspberry gpios.

One question is, how do I package the different vumeters values to connect them separately to the netsend object in pd? (Like the following screenshot)

I made a python script with the pdreceive command but I don't know how to take the message from the string concatenation:

I need to take each vumeter value separately from puredata and be able to identificate them in python.

Does anyone knows how to solve this problem?

Thank you!

Hi everyone,

I've been learning and using pd lately cause I want to make with the raspberry pi a portable sampler and audio processor. The patch works pretty good manually triggered inside the patch but I want to make an external program for the raspberry pi with a nice user interface to be able to control the patch and make nice visual elements for it.

I've been reading about libpd and seems to be a good solution to make the program in c++ or python including the puredata in it as a library with libpd, but I didn't found specific tutorials aiming to the raspberry pi...

Has anyone made this on the raspberry pi? Any tips, tutorials or resources?

Thank you!

@whale-av yeah, being a portable effects processor for instruments, it needs to be very small and self-contained (in the sense that no peripherals should be sticking out like keyboards or audio interfaces) which is why I was wondering about implementing adc and dac with physical inputs and outputs into the actual thing instead of using peripherals.

@bmd the Axoloti core looks like pretty much exactly what I was going for with hardware! Although missing an extra input and output. That said, I plan on dealing with two mono signals so perhaps I could use the single stereo input and then separate left and right into input 1 and input 2... Having a quick look at this though http://www.axoloti.com/axoloti-patcher/ suggests that it isn't as versatile as Puredata with not many objects available but maybe I'm wrong again. Definitely going to research more into this. It also sounds like it has an easier solution to my problem of not knowing how to physically implement my patch onto some hardware. Thanks for showing me that.

Seeing as Raspberry Pi/Arduino/Puredata has a lot more support around it, plus the fact I wouldn't have to learn a whole new programming software for Axoloti, do you think I'd be able to make something very similar to the Axoloti Core using a Rasperry Pi? Or is this just overcomplicating things to the point where I might as well just learn how to use Axoloti? I'm struggling to find any appropiate ADC for the Raspberry Pi, but I'm sure there's got to be something high quality around, I mean, I find it hard to believe nobody has made a Raspberry Pi with at least 16 bit 44,1kHz audio input and output.

Also, @whale-av made me think... If I'm not having any peripherals sticking out of my signal processor, a touchscreen might be a reasonable idea for this to simplify things and not take up space. It looks a lot more difficult to do this on Axoloti than Raspberry Pi who have their own touchscreens conveniently available, or the Odroid @alexandros mentioned which has a HDMI port. A touchscreen might not be totally necessary but now I've considered it I kinda want it.

@Congarou Do you get sound in other circumstances? If not then this might help........
http://www.nodepond.com/blog/758-puredata-on-raspberry-pi-useful-hints-and-links as it might be sending to the hdmi audio out......
Otherwise......https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=19155
or you could try Miller's optimised Vanilla.......https://guitarextended.wordpress.com/2014/03/23/update-on-running-pd-on-the-raspberry-pi/
David.

We’d like to invite you to join our kickstarter campaign for the PiShield, which allows you to easily connect up to 8x analog 5V sensors and 4x digital I2C devices to the Raspberry Pi. See https://www.kickstarter.com/projects/infusion/pishield-sensor-interface-board-for-raspberry-pi

If you’re interested in this new way of working with sensors on the Raspberry Pi, please join in and help us make the PiShield a success !

Thanks for your support,

I-CubeX

So I'm working on a project right now and I'm interested in getting some input on the project as I'd like to open source it when I finish. Its a similar idea to the Nord modular but implemented in PD, Python and C. I will try to keep this up to date as the project continues and if there is interest I would be happy to upload some of the code to git

Parts:
Python GUI for building synthesizer utilizing pyata and tkinter
PD objects for each module(VCO, VCA, ENV, MIX, VCF, MIDI, OUTPUT)
Raspberry Pi Cluster(1 conductor and 4 voices) connected via an ethernet switch a d voices ran through a passive mixer
C program for converting midi to OSC messages and sending them to each voice for polyphony as well as uploading your patch of choice

The main idea is that you build a synthesizer patch in the GUI which runs on the conductor which is converted to a PD patch. This patch is then chosen on the conductor raspberry pi when in play mode and is distributed to the 4 voice raspberry pi. All pi's are connected through a switch. This signal for each voice is sent through a passive 4 channel stereo mixer which is sent to a speaker or headphones. A midi controller is plugged into the conductor via usb and its knobs/sliders can be mapped to slider objects within the patch

Adding Modules:
A module consists of a pd object and a python array that represents the inputs and outputs and generates the module object within the application. This will allow for the simple addition of new modules as long as they adhere to the input and output specifications. I hope to add substantially more modules once I get the minimal set needed to build a basic synthesizer.

Would people be interested in something like this at all?

@toddak Ah!......... so I am sorry toddak, but I have a lot of questions......

So you still want to use the touch screens, and as you have a few Pi's you have backup cards so you have managed to get back to where you were before the update disaster? I hope so as that would make me feel much better!

You do not really want to use netsend and netreceive but in fact OSC objects (so you don't need MrPeach....... and a later vanilla will be ok as Alexandros suggested)? However, extended has many useful objects!

You are using an extra Pi as a router and you want to use [netsend] and [netreceive] on that?
I would think you would be better off with a dedicated router. I just bought another wrt54 on ebay for 99 uk pence.

Are you planning to stream audio to these 4 Pi's (in which case you will need extended) or are you just sending osc messages from them, or just receiving osc messages so as to start/stop playback?
I have not managed to make audio streaming to a Pi work reliably yet without occasional dropouts, and the sound will not work well at all unless you give Pd root privileges............. so remember.... for later...
sudo chmod 4755 /usr/bin/pd-extended
For audio on a Pi it should be run headless, so you should drop your touch screens in that case.

If you are using the Pi's with touch screens just to send osc messages you would be better off with some £40 android 7" tablets running TouchOSC (one licence for all of the android devices you own).
If they are receiving Osc to control their local playback then why do they have touch screens. Is it the touch screens that would not work with Jessie, or some other screen?

Jessie is not very different from Wheezy (it is not a huge update) but it is exclusively armhf. If the touch screens are needed and will not work with Jessie then you are stuck with the current wheezy that you have installed.

If you need to stay with armel then on one of your working Pi,s (armel) you should try this http://puredata.info/downloads/pd-extended-rpi version of extended and install pulse audio and the fonts (manually or with an apt-get) first. A lot of information you can find from here http://puredata.info/docs/raspberry-pi/?searchterm=raspberry
But if you have Rpi B2 (or anything other that an A or a Zero) you should really be running an armhf distribution.

David.

Hi there,

I'm developing an audio device based on a cubieboard2(armf). I use potentiometers read by an adc that communicates through i²c protocol with my cubie. An i²c lcd display shows the desired parameters values.

I wrote externals in order to get data from the potentiometers (and other switches, and a rotary encoder), or send data to the display. Everything was working, but the i²c I/O functions calls were leading to clicks 'n pops in the audio, which was unacceptable. I use a rt patched debian with selected rt priorities for irqs and audio as I always did with success, and I am looking for a smart way to make my pd patches communicate with my physical interface, in a transparent way at audio level.

Then a opened this topic : http://forum.pdpatchrepo.info/topic/9489/external-i2c-data-reader-leads-to-clicks-standalone-version-works-better , and @Eeight proposed to implement threads, kindly giving a template in order to show me the way.

And now I'd need some advice. I'm not a real C programmer, just learning the empirical way, and I'm reaching my limits... I made a threaded version of the external that reads the potentiometers every x milliseconds, and it works perfectly, no audio pollution anymore. But when I made a threaded version of the external that handles the i²c display (thus receiving incoming messages such as "position x y", or "write message"), it lead to timing problems.

Some of the messages get uninterpreted because my writing function is threaded, and takes the form of an infinite while(1) loop containing a "usleep(10000)" instruction at the end of it in order to limit cpu load. The problem is that this leads to the "loss" of most of the incoming messages...

When reading potentiometers values, it's ok to get them merely one every 10ms, but when you have to send messages that can be interpreted merely one every 1oms, you have to send them to the external with delays, which works (That's my present situation), but is tiedious and inelegant.

Would someone have an idea of how this problem could be addressed in a more elegant manner ?

Here is how I implemented it :

• I create a thread for an infinite while (1) loop containing a call to a writing function whenever a flag equals 1, followed by a usleep(10000) instruction.
  This "thread" is running from the beginning and awaits for a nonzero value of the flag to enter in action. It reads the string to be displayed from the object's data structure, but only when the "clocking" allows it together with the flag
• a "write" method can receive a t_symbol : the string to display. When a "write blahblah" message is received by the object, the string "blahblah" is stored in the object's data structure, as the flag which is set to 1.
• Then the next time the threaded loop evaluates the flag, it displays "blahblah", resets the flag to 0 and sleeps for 10ms.
  But when you use incoming messages using 10 lines messages (allowing for cursor positioning and writing orders), they of course flow through the code in far less than 10ms, hence my problems... In other words the string to be displayed can be changed several times in the object's data structure without being actually displayed because of the relatively slow "clocking".

Please forget the incredible length of this message, together to the fact that I don't post the source yet because of a basic shame of my inelegant coding style. Maybe will I finally clean it and post it later.

Thank you,

Nau

hello,

Currently i am working on a project where i plan to place a potentiometer behind a clock face, so that turning the hands with control the playing of audio files.

Therefore i need the potentiometer to be able to turn 360degrees after this returning itself to 0vaule for another complete turn.

Does anyone know if this kind of potentiometer is available and where i would be able to get my hands on one.

Thanks