Pduino + Arduino Output to Pins
Experienced PD user, intermediate Arduino user here.
My goal is to send several different frequency square waves (to be used as "on" and "off" signals for a circuit) to various output pins on an Arduino.
I am up and running using the Pduino library, and have PD and Arduino talking to each other.
However, I am not able to output audio-rate signals to any Arduino pins. For example, sending a square~ into an appropriately timed snapshot~ to output 0's and 1's to Arduino pins yields random clicking/sputtering Arduino output, rather than the expected steady square wave tone at any freq.
My arduinos play a square wave out through the pins just fine when using the Arduino IDE...so, what am I missing in the communication between Arduino and PD/Pduino? A speed issue?
Thanks in advance for any advice!
Streaming audio file player? Timeline editor? Syncing multiple tracks?
@johnwbyrd I have never looked at the source code, but I run a live performance with Pd....... 30 input channels, 8 out..... with live mixing and using [readsf~] for up to 15 minute backing tracks, and I have never had Pd hang even momentarily.
I use extended for that although I doubt the [readsf~] implementation is different.
However, I use windows7....... and is it possible that Pd and the OS treat disk access slightly differently on other systems? I doubt that.
[readsf~] requires an "open" and a "start"...... so it is not forward looking as it might be in an audio editor. However if you program the "open" in advance.... or even at load, then the start is instantaneous (in ram) and you can emulate an instant player.
If Pd is stumbling during playback..... look elsewhere for the problem....... not in [readsf~]......
A multi-GHz processor with rapid disc access should not have problems with audio or Pd...... they use a paltry fraction of the resources available.
Yes..... Pd prioritises audio..... like all programs that use audio.... over video, screen drawing...... everything. So if your patch is struggling in any way you could see the Pd gui stumble.
Check thoroughly your audio and latency settings.... any mismatch with the capabilities of the soundcard could cause what you are seeing.
More here about setting up your computer for audio......... https://forum.pdpatchrepo.info/topic/10125/audio-and-video-why-do-i-have-problems ..... with a link to a good read for problem solving!
You often just need to tell your OS to do as instructed......"and I mean it!"........... Otherwise it prefers to go and peruse it's Facebook page for likes!
Maybe, otherwise, use FL studio or something similar.
Programs written specifically for audio application will have been written in assembly language and be more appropriate for your purposes.
Communication with Pd is usually facilitated through at least midi or OSC messaging.
ALSA output error (snd\_pcm\_open) Device or resource busy
Sorry to necro this thread, but I finally found out how to run PureData under Pulseaudio (which otherwise results with "ALSA output error (snd_pcm_open): Device or resource busy").
First of all, run:
pd -alsa -listdev
PD will start, and in the message window you'll see:
audio input devices: 1. HDA Intel PCH (hardware) 2. HDA Intel PCH (plug-in) audio output devices: 1. HDA Intel PCH (hardware) 2. HDA Intel PCH (plug-in) API number 1 no midi input devices found no midi output devices found
... or something similar.
Now, let's add the
pulse ALSA device, and run
pd -alsa -alsaadd pulse -listdev
The output is now:
audio input devices: 1. HDA Intel PCH (hardware) 2. HDA Intel PCH (plug-in) 3. pulse audio output devices: 1. HDA Intel PCH (hardware) 2. HDA Intel PCH (plug-in) 3. pulse API number 1 no midi input devices found no midi output devices found
Notice, how from the original two ALSA devices, now we got three - where the third one is
Now, the only thing we want to do, is that at startup (so, via the command line), we set
pd to run in ALSA mode, we add the
pulse ALSA device, and then we choose the third (3) device (which is to say,
pulse) as the audio output device - and the command line argument for that in
pd -alsa -alsaadd pulse -audiooutdev 3 ~/Desktop/mypatch.pd
Yup, now when you enable DSP, the patch
mypatch.pd should play through Pulseaudio, which means it will play (and mix) with other applications that may be playing sound at the time! You can confirm that the correct output device has been selected from the command line, if you open Media/Audio Settings... once
As the screenshot shows, now "Output device 1" is set to "pulse", which is what we needed.
Hope this helps someone!
EDIT: I had also done changes to
/etc/pulse/default.pa as per https://wiki.archlinux.org/index.php/PulseAudio#ALSA.2Fdmix_without_grabbing_hardware_device beforehand, not sure whether that makes a difference or not (in any case, trying to add
dmix as a PD device and playing through it, doesn't work on my Ubuntu 14.04)
sampling rate impacting sound
Not entirely sure about the math of the whole thing, but what I know is that when you use Jack as your audio server, you don't change your audio setting in Pd, but only in Jack.
Check this, start Jack (in the image you posted, the sampling rate is at 48KHz), then start Pd and open its audio settings. Most likely it will read a 44.1KHz sampling rate. Don't change that, open a new patch and put a [samplerate~] connected to a [print]. Bang it and see what it prints. It should print 48000 and NOT 44100. This is because Jack's sampling rate is at 48000 and that's the sampling rate Pd is using, even though its settings read 44100.
What happens, I guess, is that when you change Pd's audio settings you force a different sampling rate between the client (Pd) and the server (Jack), which causes this frequency difference, which probably occurs due to two different samplings of the same frequency.
The only thing you should probably set in Pd's audio settings (if I'm not mistaken), is the number of channels of your sound card.
Getting DHT-22 sensor data to PD/PD-l2Ork RPi3
Hello, first post here as a PD newbie (but Max veteran)
I have managed to get PD working on my RPi3 (well that was easy as it is included in the Rasbian repository!!) and I am currently installing PD-l2Ork. I hate to ask stuff without having had a good stab at it myself already but I just wanted to ask for tips on getting sensor information into PD.
I am going to take part in Tiree Tech Wave in a couple of weeks and I want to make some kind of reactive bio feedback sample player, trying to scrub local weather data looks like it might be quite hard so I thought of doing something a little more micro scale and use something like the DHT-22 to get local ambient data and to influence a generative system that plays back samples from file.
I am fairly competant with Arduino style C and have done a little work in Python (but Python does give me a headache!!) - I have managed to get DHT-22 collecting and feeding back data on the RPi with Python and on the Arduino individually. I have no idea right now how to go about getting that data into PD...
The DHT-22 has a basic microprocessor on it that sends the collected ambient readings as words on a single wire data line, People have made nice Arduino and Python libraries already to handle that painlessly...
I have installed pd-comport and I have the impression the PD-l2Ork has some good included GPIO handling, I think that what I could do quite easily right now is bring an Arduino along as well and get the Arduino to handle all the DHT-22 stuff, and also react to the data - this could result in something like triggers activating on several GPIO pins, all easy stuff. But it would be nicer and I would learn more if I could send the actual numbers based on temperature and humidity to PD and do stuff there... I have no idea how easy that would be, in Max/MSP I would use the serial object to get data from the Arduino, and it's pretty easy to filter what you see at either end.
I guess another possible benefit of serial is perhaps using Bluetooth and having the sensor located more remotely.
Of course, it's probably totally unnecessary to use an Arduino and it can all be handled by the RPi but using Python makes my blood pressure go up
Anyway, woops I have written an essay... any thoughts, tips or words of encouragement would be welcomed!
No sound from raspberry
I had the same difficulty. No sound cards were available according to
I found somewhere (I forget where) the suggestion to add to
and from then everything went swimmingly. I set up some (possibly pretty dangerous) values in
### realtime permission for audio @audio – rtprio 99 @audio – memlock unlimited @audio – nice -10 @audio - priority 8 # End of file
The audio priority of 8 seems to be necessary to stop annoying messages in the puredata console when it's started. I'm not an expert on these values, they might not be wise, safe or ideal but they worked for me.
And I made sure that my user is in the audio group:
usermod -a -G audio david
And I've had glitch free performance since out of the mini jack.
install pdl2ork on manjaro: fails to get flite installed..
Hi there, i also posted to the manjaro forum but i guess here i can find more expertise on that topic: i want to install pd-l2ork on manjaro (arch-based) linux and I get this error building flite:
Insert Co> Found flite1.patch ==> Validating source files with md5sums... flite-1.4-release.tar.bz2 ... Passed flite1.patch ... Passed ==> Extracting sources... -> Extracting flite-1.4-release.tar.bz2 with bsdtar ==> Starting prepare()... patching file config/common_make_rules ==> Starting build()... checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for ranlib... ranlib checking for a BSD-compatible install... /usr/bin/install -c checking for ar... ar checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking whether byte ordering is bigendian... no checking for mmap... yes checking sys/soundcard.h usability... yes checking sys/soundcard.h presence... yes checking for sys/soundcard.h... yes checking machine/soundcard.h usability... no checking machine/soundcard.h presence... no checking for machine/soundcard.h... no checking sys/audioio.h usability... no checking sys/audioio.h presence... no checking for sys/audioio.h... no checking mmsystem.h usability... no checking mmsystem.h presence... no checking for mmsystem.h... no configure: creating ./config.status config.status: creating config/config config.status: creating config/system.mak making in ... making in include ... making in src ... making in src/audio ... gcc -fPIC -D_FORTIFY_SOURCE=2 -I. -DCST_AUDIO_LINUX -I../../include -O3 -Wall -c auclient.c -o /tmp/yaourt-tmp-kalimerox/aur-flite1/obj/src/audio/auclient.os gcc -fPIC -D_FORTIFY_SOURCE=2 -I. -DCST_AUDIO_LINUX -I../../include -O3 -Wall -c auserver.c -o /tmp/yaourt-tmp-kalimerox/aur-flite1/obj/src/audio/auserver.os gcc -fPIC -D_FORTIFY_SOURCE=2 -I. -DCST_AUDIO_LINUX -I../../include -O3 -Wall -c audio.c -o /tmp/yaourt-tmp-kalimerox/aur-flite1/obj/src/audio/audio.os gcc -fPIC -D_FORTIFY_SOURCE=2 -I. -DCST_AUDIO_LINUX -I../../include -O3 -Wall -c au_streaming.c -o /tmp/yaourt-tmp-kalimerox/aur-flite1/obj/src/audio/au_streaming.os au_streaming.c: In function ‘audio_stream_chunk’: au_streaming.c:77:9: warning: variable ‘n’ set but not used [-Wunused-but-set-variable] int n; ^ gcc -fPIC -D_FORTIFY_SOURCE=2 -I. -DCST_AUDIO_LINUX -I../../include -O3 -Wall -c au_oss.c -o /tmp/yaourt-tmp-kalimerox/aur-flite1/obj/src/audio/au_oss.os au_oss.c: In function ‘audio_open_oss’: au_oss.c:86:25: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ad->platform_data = (void *)afd; ^ au_oss.c: In function ‘audio_close_oss’: au_oss.c:181:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] ioctl((int)ad->platform_data, SNDCTL_DSP_SYNC, NULL); ^ au_oss.c:182:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] rv = close((int)ad->platform_data); ^ au_oss.c: In function ‘audio_write_oss’: au_oss.c:189:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] return write((int)ad->platform_data,samples,num_bytes); ^ au_oss.c: In function ‘audio_flush_oss’: au_oss.c:194:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] return ioctl((int)ad->platform_data, SNDCTL_DSP_SYNC, NULL); ^ au_oss.c: In function ‘audio_drain_oss’: au_oss.c:199:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] return ioctl((int)ad->platform_data, SNDCTL_DSP_RESET, NULL); ^ ar: ../../..//tmp/yaourt-tmp-kalimerox/aur-flite1/lib/libflite.shared.a: No such file or directory make: *** [../../config/common_make_rules:116: /tmp/yaourt-tmp-kalimerox/aur-flite1/obj/src/audio/.build_so] Error 1 make: *** [../config/common_make_rules:133: /tmp/yaourt-tmp-kalimerox/aur-flite1/obj/src/.make_build_dirs] Error 2 make: *** [config/common_make_rules:133: /tmp/yaourt-tmp-kalimerox/aur-flite1/obj//.make_build_dirs] Error 2 ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Makepkg was unable to build flite1. de
anyone having the same issues or an advice=? ?
Multiple patches sending to the same Arduino / change block size?
I'm working on a project involving Pure Data and Arduino. The idea is to play an audio file while controlling a pump that breathes air into an aquarium, based on the envelope of the audio, so that the bubbles correspond to the voice that you hear in headphones.
My problem is, while it works perfectly with one aquarium (playing the audio file + controlling the pump), it's less precise, and sometimes completely off, when I'm adding the others.
The logic of one aquarium is inside an abstraction, [aquarium], with the file, threshold, audio output and Arduino pin as creation arguments. Every instance of the abstraction is playing its own file into a given audio output, and sending messages to the Arduino ("turn on pump X" or "turn off pump X"). It works quite well for most of the aquariums, so I guess (hope) the fix must be simple.
I tried different ideas to limit the message flow but didn't quite succeed (hence the mess below the [dac~] object, this stuff is not used anymore).
I only recently thought about increasing block size, thinking that would reduce the number of messages sent to the Arduino. However using the audio settings, it didn't seem to change anything, and I'm not sure how to use the [block~] object. Do I have to send the audio output through an [outlet~] object? I guess that would mean each of my 9 [aquarium…] blocks would need to have 9 outlets going into a [dac~] object in my main patch, and that would be a big spaghetti plate
I'd be curious to know if any of you has ever encountered this kind of issue, or has an idea to fix it, either with block size, pure data magic or anything else…
Pure Data / Raspberry Pi / Realtime Audio / Permissions
I want my Raspberry Pi 2 to automatically start up the Jack server with realtime scheduling, and subsequently start Pure Data with realtime scheduling, load a patch &c. without any user intervention from a login shell.
As a performance artist working primarily with psychodrama (the technology is definitely NOT the important part here), fiddling around at a terminal right before or during a performance is kind of... psychically inconvenient. I need a box that I can plug in, give the audio output to the sound guy, and be ready to go.
I use Raspbian with a Linux kernel compiled with realtime goodness. I have hand-compiled Jack2 and Pure Data with realtime support in order to take advantage of this. Running a process with realtime priority requires the proper PAM directives set in /etc/security/limits.conf and related places, but that is beyond the scope of this little write-up.
Also somewhat relevant: I use a M-Audio MobilePre USB soundcard (sounds pretty awful by today's standards, but it's an extremely USEFUL box and sounds good enough for the work I do). For full-duplex sound, this requires the RasPi's USB to be set to single speed. In this configuration, I can get just under 2.9ms latency with good CPU overhead for Pure Data to run a few of my 64-voice wavetable and delay line granulators. Yeah!
Purely by happenstance, I had given the jackd command in my startup script the option “-s” which allows the server to ignore overruns and so on. So things seemed to be working as expected, but I noticed a lot more glitches than when I manually started up Jack and Pd from the terminal without the “-s” option. Upon removing it from my startup script, everything failed! WAH.
So I started piping STDERR and STDOUT to text files so I could read what either Jack or Pd were complaining about. As it turns out, Jack was unable to start with realtime priority due to a permissions problem. (I assume this is one of the things the “-s” options allows jackd to ignore, and thus start up with non-realtime priority. Problem is that Pure Data can’t connect to a non-realtime Jack server when its “-rt” option specified.)
Now, I had already been through the whole rigamarole of setting proper memory and priority limits for the “audio” group, to which the user “pi” belongs. So I thought, okay, I have to execute these commands as “pi”, and while simulating a login shell because the security limits in question are only set during login.
So I did this:
su -l pi -c "/usr/local/bin/jackd -R -dalsa -dhw:1,0 -p128 -n3 -r44100 -S >> /home/pi/jackd.log 2>&1 &"
This says “login as user ‘pi’ and then run the jackd command with these options, piping the outputs to this log file and run it in the background”. Well, I still got all the same errors about not being able to set realtime priority. WHYYYYYYYYY?
I hunted and hunted and hunted on a Very Popular Search Engine til I decided to try searching “security limits not loaded with su -l” and found this.
(Makes me think of that Talking Heads lyric, “Isn’t it weird / Looks too obscure to me”.)
So by uncommenting the line
# session required pam_limits.so in
/etc/pam.d/su everything started working as expected.
I now know a LOT MORE about PAM and how important it is to keep in mind when and in what order scripts and other little subsystems are executed; but also that sometimes the problem is EXTREMELY OBSCURE and is to be found in some seemingly far-flung config file.
I hope this helps anybody out there working with Pure Data and the RasPi. The second generation board really packs quite a punch and can run several hundred audio grains (run by vline~ and enveloped by vline~ and cos~) simultaneously without a problem. And I'm pretty sure this is just using ONE of the 4 cores!
I'm by no means an expert Linux sysadmin, so if you have any other suggestions or corrections, please let me know! I wouldn't have been able to get this far without all the generous and helpful writeups everybody else has contributed, both within the RasPi and Pure Data communities. If you have any questions about anything I glossed over here, I'll do my best to answer them.
Noise filter for microphone (Live Audio)
Well, the forum crash seems to have eaten my last post.
I have made a noise filter to clean up audio signals live.
Other noise removal filters need to have a noise sample selected and try to remove that noise from the complete track - they only work offline.
This patch works online. It removes any stationary noise from the signal and doesn't need any user adjustment except that it does need to be told how much to reduce the noise.
"Stationary noise" is a signal whose frequency content and amplitude stay (more or less) constant for over 1 second. Fan hum is a good example, as well as the more or less "white" noise from the wind from the fan. Car motor sounds from a car travelling at constant speed is also a good example.
It will also kill feedback squeal cold, even at the lowest settings.
The patch is built in layers, and the lower layers can be used independently or combined and used to build different filters.
The attached zip file includes all the components from the lowest level up to a complete demonstation that takes in audio from a microphone and puts out filtered audio on line out. It also includes a set of help files that describe the function and use of the various modules.
NoiseLevelDetector.pd - estimates the amplitude of the stationary noise
NoiseFilter.pd - attenuates the signal based on the amplitude from
NoiseLevelDetector.pd Since it is more effective at high frequencies, it is best to feed it limited bandwidth signals and use multiple filters to cover the desired audio range.
BandLimitedNoiseFilter.pd - a Noisefilter that only works on the specified frequency range.
MultibandNoiseFilter.pd - a complete filter that covers the range from 40Hz upto 22000 hz to filter the complete audio spectrum.
Test.pd - demo program that demonstrates the use of MultibandNoiseFilter.pd
It works best for speaking voices. Singing tends to be more stationary. It could be adapted to singing voices by changing a single value in one of the lower level blocks.
The original idea was to create filter for removing car noises from microphone audio for two-way radios. When used to cover just the range from 300Hz to 3000Hz, it does a very good job.
The biggest disadvantage is that it will start making "musical noise" if there is a lot of noise and the attenuation is set high. It also adds a slight echoing quality to the filtered audio.
The project is hosted on GitHub: PureData NoiseFilter project.