Unfortunately, snapshot~ doesn't seem to send data at a rate which enables clean signaling of arduino pins. When it comes to audio anything, I find that outputting signal is necessary, as outputting control values just cannot keep up with audio. If you are looking to make a square wave generator that is controllable from puredata, the best way that I have found to do this is by using a combination of arduino, a DAC chip and an op-amp chip. Also, you'll want to use at least a 12 bit DAC, such as mcp4921 or mcp4725, as 8 bit DAC lacks the ability to tune the output fine enough to stay in tune with standard tuning. For opamp choices, you can pretty much take your pick. They all do pretty much the same thing, though you will find that every opamp has it's own unique sound quality. I really love the gritty sound of the CA313. A very good and popular sound for opamp VCO is the tl072 or tl075. There are tons of schematics out there for how to configure a square wave vco with opamps. You would just modify the components to fit the output of your DAC.

Next, you would send your controller values from PD to the arduino and have some code in the ar'dweener to handle communicating with the DAC. You can then add all sorts of fun stuff to your board like digipots, opamp buffers, VCAs and so on to make envelopes, LFOs etc.

If you don't want to track down additional chips (usually ordered from china being the only way to find them, cheap though they tend to be,) but want to have square waves being output directly from the arduino, then you would still be better off having pd send control values to the arduino and then let the arduino handle the signal generation to it's pins. For this purpose, you may want to look at the tone library or the mozzi library. Teensy boards have some expanded audio capabilities as well, but teensy boards are a bit expensive for my taste, as you can get a freakin raspberry pi with a full linux operating system on it for a fraction of what it costs. Still, teensies are great and extremely handy for these types of applications if you dont mind dropping some extra money. I try to build everything to work on cheap arduino clones just for financial and practicality sake.

I have code and patches that I have written to control these types of circuits for many DACs and digipots with SPI and I2C protocalls... let me know if you'd like to check them out for some guidance.

Dear Forum,

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!

Dynamic Effect Plugin Loader esp. For Rapsberry PI (DIY2 and Stamp Album effects/plugins)

DynamicEffectPluginLoaderForPI.zip

Background:

In the last couple of days I finally built something I have needed and wanted for a while (which later on I will discuss in more detail under a separate thread): an Arduino electric guitar.

In other words, I took the connections off the 5-way and knobs (internally connected to the pickups and line out) and rerouted the switch and knobs to an arduino. The reasoning being I can control Way more with pd and those knobs than what they were originally intended to do if I capture their output using Arduino.

However, the patch I had built for it was clocking in at about 275-300% of the pi's cpu. And while I could have gone back and added switches (which I took out a while back, to replace with fade-mixers for when I change an effect) throughout, the thought of doing that was more daunting than (considering how elaborate the patch is) I wanted to undertake.

Enter: Dynamic Patching.

I found that with just 3 straight-chained effects the pi ran at only about 10%.

So...here's what I built and am sharing now (before tying it into the arduino guitar, because I think others might want to go ahead and learn from it, extend it, expand upon it, use it, etc. etc.).

The patch(es, there are two, one laid out for the DIY2 plugins and one laid out for the Stamp Album ones, will probably consolidate them later, but other things are demanding my attention) is pretty straight forward:

(Dependency on the tof/menubutton, tof can be found via deken)

Click on the menus at the top to select an effect for each of the 5 slots or select the "unchanged" effect to leave that slot open.

Then click the BUILD bang or the CLEAR bang (to start over).

The selected effects will load into the PALLETTE subpatch already connected to adc~ and dac~.

That's really about all there is to it. Very straight-forward, clean, and very cpu light-weight. The racks of all 5 slots I tested ran at about 10-12% on my PI 3r2.

Hope you can make use of it. And would love to hear feedback.

For the future:

Add a hid-stomp controller to load preset racks (which you can send in via the tof/menubotton) to load racks on the fly;

Add a meta-level to send either hid, osc, or arduino commands to each of the loaded effects.

Merry Music to us, one and all.

Peace,
Scott

p.s. Oh! The arduino guitar: though it has no connected pickups it gets its audio signal from an (about) 1" piezo mic fun-tacked to the knob-well inside the guitar. Sounds great. Just pure guitar. The tone, texture, etc. come after the fact via the pd-side.

Ciao for now.

Wanna say: the real genius lies not in what I cobbled together, but the strength of will and purpose it took for the two original developers to make abstractions so completely consistent and thoroughly aligned. My highest regards to you both. Thank you, both, so very much, for helping to make my "job" so easy.

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!

This is quite common with this sensor and Pduino. In the code one can find for this sensor you can see that it uses the Arduino native pulseIn() function, which is called when the echo pin sends a signal to the Arduino. In order to use this sensor with Pduino you need to translate the workings of this function to a Pd patch.
Instead you can just tweak the printing functions of the code and use the [serial_print] abstraction that I've made, especially for situations like this. You can find it here https://github.com/alexdrymonitis/Arduino_Pd
All you need to do is make sure you first print some sort of tag with Serial.print() (like "sensVal" for example), and the print the value with Serial.println(). Make sure you print a space in between the two. So you can do the following:

Serial.print("sensVal ");
Serial.println(sensVal);

In the example above the sensor values are being stored in a variable called sensVal. I first print the string "sensVal " (note the white space before the closing quote) and then I print the variable (no quotes this time) with Serial.println().
Then in Pd follow the example of the help patch of [serial_print] and use a [r sensVal] to receive the values.
This should do it.

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.

Files : main.pd, aquarium.pd, arduino.pd

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…

Thanks!

Hi @alexandros

code is below, if you can figure anything out that would be great !

/* GroveI2CTouchTest.pde - Sample code for the SeeedStudio Grove I2C Touch Sensor
http://seeedstudio.com/wiki/index.php?title=Twig_-_I2C_Touch_Sensor_v0.93b  
Prerequisite: A modification of the Grove I2C Touch sensor is needed Solder a pin to
the INT terminal in the I2C sensor to connect it to one pin in Arduino  Created by
Wendell A. Capili, August 27, 2011. http://wendellinfinity.wordpress.com  
Released into the public domain.*/

#include <Wire.h> // include I2C library
#include <i2c_touch_sensor.h>
#include <MPR121.h>
// include our Grove I2C touch sensor library
// initialize the Grove I2C touch sensor
// IMPORTANT: in this case, INT pin was connected to pin7 of the Arduino 
// (this is the interrupt pin)
i2ctouchsensor touchsensor; // keep track of 4 pads' states
//boolean padTouched[4];
long previousMillis = 0;
long interval = 100;
void setup() 
  {    
    Serial.begin(9600); // for debugging   
    Serial.print("begin to init");  
    Wire.begin(); // needed by the GroveMultiTouch lib     
    touchsensor.initialize(); // initialize the feelers     // initialize the containers     
    //for(int i=0; i<=3; i++) 
    //{          
   // padTouched[i]=false;     
    //}
    
  }
void loop()
{     
   unsigned char MPR_Query=0;
   unsigned long currentMillis = millis();
 if(currentMillis - previousMillis > interval)
  {
    previousMillis = currentMillis;
    touchsensor.getTouchState();
  }
 for (int i=0;i<12;i++)
 {
 if (touchsensor.touched&(1<<i))
    {
    Serial.print("pin ");
        Serial.print(i);
        Serial.println(" was  touched");
         }
 }
}  

/*

  touchsensor.readTouchInputs(); // test read the touch sensors     
// loop through our touch sensors 1 to 4    
  for(int i=0; i<=3; i++)
  {          
// get the touch state based on pin #         
    if(feelers.getTouchState(i)) 
    {              
      if(!padTouched[i]) 
        {                    // print in serial that it was touched             
        Serial.print("Pad ");                   
        Serial.print(i);                               
        Serial.println(" was touched");             
        }              
// flag the touch sensor state              
    padTouched[i]=true;         
     }          
    else 
    {             
    if(padTouched[i]) 
    {                    
      // print in serial that it was released                                      
      Serial.print("Pad ");                  
      Serial.print(i);                               
      Serial.println(" was released");            
    }               // reset the touch sensor state                      
    padTouched[i]=false;        
    }    
  }*/

Saw your TED video, so maybe you've already solved this problem.

In my limited work with getting arduino and pd to play nice, I've found that things like pduino and firmata work great but can be restrictive. I had to multiplex inputs on my arduino, which doesn't play nice with something like firmata that automatically reads all the pin values.

It might be better to have each arduino on it's own [comport], and differentiate the arduinos that way. Dump pin values over each comport and keep reading it.

Here's the thread explaining what I did:
http://puredata.hurleur.com/sujet-5832-reading-multiplexed-input-streams-arduino

I'm a fan of your work.

Hello,
Although there seems to be endless information on the internet on using an Arduino board with Pure-Data, I haven't found any info that will make it work for me... So, I'm seeking for some help.

So I'm trying to use my Arduino board to read galvanic skin response. I've got that nearly working. Where I'm having trouble is getting the data into PD in the correct format.
Here is the code I have for my Arduino:
// Arduino Code
int sensorPin = A0;
int sensorValue = 0;

void setup() {
Serial.begin(9600);
}

void loop() {
float conductance = getVoltage(sensorPin);
Serial.println(conductance);
Serial.write(conductance);
delay(1000);
}

float getVoltage(int pin){
return (analogRead(pin));
}
// End Arduino Code.

I'm using the comport object in PD. And I am receiving Data which is analogous to what I'm doing on the board. But I can't understand exactly what it is reading. Here is the link to my PD patch: http://www.sendspace.com/file/n81jlj
So Firstly, the Numbers keep jumping around, and secondly I'm not sure what those numbers are. What I'd like them to be is the individual analog inputs of my Arduino. But they clearly aren't as they all change when I play around with my arduino board. Also they seem to range between 0 and 255, whereas my Arduino reads the data as 10bits...

Any sugestions!?
Thank you,
Niko.

hi there

I am trying to get video tracking info form vvvv to pd to arduino.
I want to control dc motors in an angle that is determined by the video tracking

so I managed to get the angle-info from vvvv to PD, now I want pd to transport it to my arduino but I cant get
clear how to do that. I am using the hansrudolfsteiner ( http://www.arduino.cc/playground/Interfacing/PD ) stuff but have a few questions.

-- i sent the data from vvvv to pd with the netsend/receive stuff, where do i connect that to a digital pin so the changing value gets transported to my arduino mega
--how can I read that digital pin so I can use it in my arduino program, do I really need to use the whole firmata patch? or can this be done easier? because I only need to read 1 pin... and I need my other pins for output

if somebody knows something about this, thanx in advance..

art