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…
Bela ultra-low-latency embedded audio-sensor platform
Our lab has made a new high-performance embedded platform called Bela (http://bela.io) which is designed for creating digital musical instruments and interactive audio systems. We've been developing this for the past two years, and we just launched it on Kickstarter:
The most important unique feature of Bela is that it has extremely low latency of less than 1 millisecond between action and sound, which is a lot faster than anything else out there. There are also some useful features for profiling sensors and a built-in browser-based development environment. Basically it is the platform I have always wanted for my own audio projects and instrument building, and now we're excited to be launching it to a broader community of musicians and engineers.
The board doesn't run Pd directly, but patches can be compiled using Enzien Audio's Heavy compiler - so you can address all sensor IO's from the patch.
The project is open-source hardware and software, and the campaign is run through the university.
Bela tech details:
Audio: 16-bit stereo audio I/O at 44.1kHz
Audio power output: 2x 1W 8ohm speaker amplifiers (available when powered from DC jack)
Analogue In: 8x 16-bit analogue inputs at 22.05kHz
Analogue Out: 8x 16-bit analogue outputs at 22.05kHz
Digital channels: 16x digital GPIO at 44.1kHz or 88.2kHz
Analogue I/O is also software configurable to give 4 channels at 44.1kHz or 2 channels at 88.1kHz
Pd doesn´t run when connecting an external audio interface.
I have been using Pd for a while, and now I am working on some patches with an external audio interface to get audio input from a guitar. However, I am experiencing a problem with one of my audio interfaces.
I have the Alesis io4 audio card. I can connect it to my computer and use it with other software without any problems. However, when I try to launch Pd with this interface connected, Pd suddenly crashes without reporting any error. I have tried to use another interface (Scarlet 2i2) and Pd opens succesfully.
I would like to know if someone have experienced this problem with an external audio device, and if so, if you have any idea about how to solve it. Maybe is there any configuration i should do before the software can recognize the device?
Thanks for your attention,
Cubie pd pedal
I've been working on that for nearly two years and now it is done I find it soooo 2014 that the previous intentions to make a full wiki page seem now silly. Anyway this could give ideas to other people so here is an abstract.
This is basically a lame-electronics simple-aggregate-of-common-parts version of a guitar pedal that hosts pd extended patches as effects. It's based on a cubieboard 2, connected to an el-cheapo (this was intended as a proof of concept hardware) soundcard through usb, internally. It boots a rt-patched version of debian from microSD card (never managed to flash sdram) in ... 50seconds , with autologin so no keyboard is needed. After this time it behaves like a floor pedal, pd runs the stored patches responding to its hardware interface. Anyway a keyboard, a mouse and a display can be plugged in and it behaves like a linux desktop, it's easy to edit patches on the fly.
The interface consists of three footswitches, three leds, a button switch, a clickable rotary encoder, four clickable potentiometers and a 4x20 lcd display. The pots and the display communicate with the gpio pins (all of them digital) through i2c, the pots being read by a quadruple i2c adc.
I called it a pd pedal, but I have to confess it cannot be directly connected to a guitar amp, as the IO are two preamplified instrument inputs, two line in, two line out and a headphone stereo jack. This can be solved when you have a digital pedal in your pedalboard that have line inputs. Of course I knew it from the beginning, and could never work it around later as it would have taken more space and would have been tedious to implement for a beginner electronics fan like me .
I also wanted from the beginning to make a relatively small footprint on my pedalboard so it is rather tall (aluminium box is 160x125x76). What a challenge to stack these components in such a box it has been, especially when it came with holes positioning, elements fixture, internal aluminium rounded edges to mill and file down...
The 1 ghz dual-core with 1 gb ram allows for decent dsp patches.
The pedal automatically runs a predefined patch but interface allows for patch selection. (statically coded so far)
I initially wrote several externals that allow for interface i/o, but never got rid of audio artifacts when the interface was trigged. As a workaround I now make the readings from outside pd, with a well-choosen rt priority and send values to pd using pdsend. The workaround is only half of what it should be, as for outputting data (writing things on the display) I still rely on a homebrew pd external (too much work for me to take it out of pd). The result is uncorrupted audio only when lcd display is not used, which is unreasonable (every pot controls a patch parameter and I love to see the values updated on the lcd). But when the pedal is left untouched the audio is clean.
Here are two pics, one of the inside before the audio card is stacked and the other one showing it outside look.
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.
PD sending to two devices?
You can assign discreet inputs and outputs but not multiple outputs across different audio devices. Sound software has to access sound hardware through it's drivers and it can't handle 2 sets of calls to two different drivers (if someone has the proper tech jargon, please step in).
There are ways of cheating but they all stink in some way:
On windows: VAC/audio repeater combo
You can use 'Virtual Audio cables' to create virtual devices that you can use for input and output between software. You can piggy-back that audio to different hardware devices by using the audiorepeater utility. So you can set up VAC to make 2 cables (VAC1 and VAC2). PD will use VAC1 and VAC2 as outputs. (Since VAC1 or VAC2 aren't hooked up to real hardware, you don't hear anything.) Then you run 2 instances of audiorepeater. One instance routes VAC1 to 'Onboard speaker out' and the other instance will route VAC2 to 'USB audio device out'.
Downside: Latency, Latency, Latency
The sound is delayed through each step in the chain, and the audio repeater latency can only go but so low before you get scratchy static and dropouts.
On Linux: ALSA virtual device
You can make a virtual soundcard using ALSA that can combine the outputs of two audio cards into one
'virtual' one and then set JACK to output to that device (the setup of which is too complex to explain here).
Each soundcard has it's own timing, and there's no way to keep them in synch, so you can control the latency and you'll have clicks, pops, dropouts, and tons of underruns.
On Mac OSX:
I haven't tried it, but I believe you can also make an aggregate device
There is also a VAC/audiorepeater type program you can use called Soundflower, but like VAC it's really only for routing sound between apps, not between hardware.
Long story short, between the latency introduced by the software and the clock timing differences between soundcards, you can really get anything usable.
0mms delay time in pd is it a dream?
0ms will be impossible I suspect just due to the way that digital audio works.
Start by assuming that everything is dealing with 64 sample blocks of audio. This is a big assumption as I'm not sure how audio hardware is going to do what it does but it should be fine for some rough calculations.
We'll also just be dealing with one channel here.
Audio hardware needs to capture that 64 samples of data from one channel. It won't send that data down the USB/Firewire/PCI bus until it has the full 64 samples which means that there is already delay there, the first sample won't be sent until the last is captured.
(1 second / 44100 samples) * 64 = 0.00145 or about 1 and a half milliseconds
Even with the best audio hardware this limitation is still there.
On top of this you need to add on the time to process the audio, there will probably be some time wasted scheduling everything etc etc. ultimately you're always going to have a couple of milliseconds latency between audio coming into the computer and then going back out.
that said, how much of an issue would 5ms latency be? generally people can't notice anything less than 20ms of latency and I understand that Yamaha engineers aim for about 4 or 5 ms of latency with all their electronic midi controllers/instruments as that's the point that it sounds instantaneous to people.
Someone with more experience here please feel free to correct me if I'm wrong though
Getting started: Pd killing my sound when i open it?
Hi. earlier this week i got Puredata. ready to build, i checked computer audio and went to media>test audio and MIDI. But when I clicked on the test tones I got no sound. Stranger yet, this somehow also kills the audio for the ENTIRE computer until i reboot. I have tried opening other audio apps, like OpenMusic, and for whatever reason, this is killing audio, too. But youtube, Winamp, and the trackers I've been using do not shut down the audio.
please help. I really want to start working with this program. thanks!
External Autio Interface mic problem
I am looking for help, to solve my problem with pure data and my audio interface. I am using PD as life performing software, and I need to use my external audio interface for better quality and avoid sound delay.
Interface I am using, is zoom R24 recorder with interface and some other stuff. PD can find it easy and it use no problem as sound output device, but once I set up input to use mic, it cut the sound off, and mic have no sight of life... I was trying different drivers, and possibilities to turn mic on, but no luck...
Is there anyway how I could use it as audio input and output for life performing... Maybe I need some special drivers, or use special commands to turn it on?
My internal audio card works fine, and the setup as internal audio card as input, and output to external interface works also... But once I switch, no signals! What should I do?!