[PD] Sensors GPIO Raspberry Pi Pd
Martin Peach
martin.peach at sympatico.ca
Sat Apr 20 23:59:12 CEST 2013
So I tested the 4X4 sensor and it actually works!
Here is the code for a reader that sends to [netreceive 33333], and a
receiver patch.
You need to set the IP to that of the machine running Pd, and maybe
other settings before compiling, as with the previous version.
Martin
On 2013-04-20 17:17, Martin Peach wrote:
> Oh sorry, it segfaults if you don't pass an argument at startup. (1 if
> it's already initialized, 0 if not)
> The line begining "if (argc > 0)" should say "if (argc > 1)".
>
> Martin
>
>
> On 2013-04-20 13:30, Martin Peach wrote:
>> Well that looks a total mess...
>>
>> I did "sudo apt-get install i2c-dev" before all this, as well as all the
>> things in http://www.instructables.com/id/Raspberry-Pi-I2C-Python/#step1
>> except I didn't use any python.
>> The segfaults might be because you are asking for more than 32 bytes in
>> a read, or something wrong in the code, the listing below looks like it
>> goes wrong right at the beginning.
>>
>>
>> Martin
>>
>> On 2013-04-19 17:37, Julian Brooks wrote:
>>> As I'm new to all this C stuff I just had a look inside the 'hello' file
>>> and there's a few bits in there which may be of interest:
>>> ^@D6T_checkPEC says 0x%02X
>>> (which I think is ok from looking at the code?)
>>> then it all goes wrong
>>> ^@^@^@Unable to create socket (%d)
>>> ^@^@^@>> %s <<
>>> ^@^@^@127.0.0.1 <http://127.0.0.1>^@^@^@Unable to make address from %s
>>> ^@%s: initialized:%d
>>> ^@/dev/i2c-0^@^@Failed to open the bus. (%d)
>>> ^@^@^@Failed to acquire bus access and/or talk to slave. (%d)
>>> ^@^@^@^@Write failed (%d)
>>> ^@^@Read failed (%d)
>>> ^@^@^@%d ^@<0x%02X>
>>> ^@^@^@d6t8l^@^@^@ %d^@
>>> ^@^@^@sendto error (%d)
>>>
>>> BTW - I've removed libi2c-dev again and will leave it that way for now.
>>>
>>> Going to stop now but will be back tomorrow.
>>>
>>> Cheers,
>>>
>>> Julian
>>>
>>>
>>>
>>>
>>>
>>> On 19 April 2013 22:07, Julian Brooks <jbeezez at gmail.com
>>> <mailto:jbeezez at gmail.com>> wrote:
>>>
>>> Edited your original file and all I changed was the ip address to
>>> 127.0.0.1 and still seg fault (double checked /etc/hosts too).
>>>
>>> Also tried reinstalling libi2c-dev and then running 'hello' - same.
>>>
>>>
>>> On 19 April 2013 21:54, Julian Brooks <jbeezez at gmail.com
>>> <mailto:jbeezez at gmail.com>> wrote:
>>>
>>> hmmm - both files:
>>> ./hello-2
>>> Segmentation fault
>>>
>>> Try again...
>>>
>>>
>>>
>>> On 19 April 2013 21:51, Julian Brooks <jbeezez at gmail.com
>>> <mailto:jbeezez at gmail.com>> wrote:
>>>
>>> Ok -found I had to remove 'libi2c-dev'.
>>>
>>> Then builds.
>>>
>>> More soon...
>>>
>>>
>>> On 19 April 2013 21:28, Julian Brooks <jbeezez at gmail.com
>>> <mailto:jbeezez at gmail.com>> wrote:
>>>
>>> Hey Martin,
>>>
>>> When I try to compile hello.c I get:
>>> gcc -o hello hello.c
>>> In file included from hello.c:8:0:
>>> /usr/include/linux/i2c-dev.h:38:8: error: redefinition
>>> of 'struct i2c_msg'
>>> /usr/include/linux/i2c.h:67:8: note: originally
>>> defined here
>>> /usr/include/linux/i2c-dev.h:90:7: error: redefinition
>>> of 'union i2c_smbus_data'
>>> /usr/include/linux/i2c.h:125:7: note: originally defined
>>> here
>>>
>>> Dunno if this is at all relevant but maybe this is a
>>> good time to say I have a rev1 RPi so I'm on i2c 0
>>> not 1.
>>> The Pi install is very up to date though, including
>>> recent runs of hexxeh's 'rpi-update' tool so all the
>>> system's fresh.
>>>
>>> I did attempt to change the number of bytes to be read
>>> which perhaps would explain why the .h file's are
>>> complaining but I don't understand it for your version
>>> which is 'as-is'?
>>>
>>> In fact why don't I attach the notes I've made of the
>>> changes to the c file you sent. Was vaguely hoping I
>>> might be able to say 'ta da' but have fallen at the 1st
>>> fence:( bugger.
>>>
>>> Julian
>>>
>>>
>>>
>>>
>>>
>>> On 19 April 2013 19:51, Julian Brooks <jbeezez at gmail.com
>>> <mailto:jbeezez at gmail.com>> wrote:
>>>
>>> Hi Martin,
>>>
>>> Meant to add re setting baud rate:
>>> I've been making use of the gpio utility that comes
>>> with wiringPi
>>>
>>> https://projects.drogon.net/raspberry-pi/wiringpi/the-gpio-utility/
>>> Very handy for getting a quick visualisation of the
>>> current state of all the pins and also easy-access
>>> to setting the baud rate too (amongst other stuff).
>>>
>>> Julian
>>>
>>>
>>> On 19 April 2013 14:36, Martin Peach
>>> <martin.peach at sympatico.ca
>>> <mailto:martin.peach at sympatico.ca>> wrote:
>>>
>>> Hi Julian,
>>> Yes I've been messing with coding it in c on the
>>> pi and sending the data to a [netreceive] in a
>>> Pd patch on another machine. I'm attaching the
>>> source code for the pi part and the Pd patch.
>>> The code can be compiled on the pi with
>>> gcc -o hello hello.c
>>> You need to set the IP address of the receiving
>>> machine in the code (I have 192.168.2.15, it
>>> could be 127.0.0.1 for the same machine).
>>> I tried changing the baud rate with
>>> sudo modprobe -r i2c_bcm2708
>>> sudo modprobe i2c)bcn2708 baudrate=90000
>>> but it works fine at the default 100000.
>>> It seems that you only need to write the command
>>> once, after that simply reading gets you another
>>> packet. Using a combined write/read operation
>>> only works half the time, as I also found on the
>>> Arduino. All you need to do is write the 0x4C
>>> command once, wait a millisecond or so and then
>>> read it.
>>> Another issue is that I tried this with the 8X1
>>> sensor, not the 4X4 one, so the code reads 19
>>> bytes (need to change the expected read size in
>>> the code). The 4X4 sensor sends 35 bytes which
>>> is 3 more than the i2c driver maximum, so you
>>> may not get the last part of a packet.
>>> I'll try it later with a 4X4 sensor to see what
>>> happens.
>>>
>>> Martin
>>>
>>>
>>> On 2013-04-19 07:01, Julian Brooks wrote:
>>>
>>> Hi Martin,
>>>
>>> Did you manage to make any progress with the
>>> sensor on the Pi?
>>> I also wanted to ask whether the output
>>> we're receiving from i2cdump
>>> makes any sense to you as it doesn't to us
>>> currently? Tried searching
>>> around for possible info on the 'XX' & 'ff'
>>> but drawing a blank here.
>>>
>>> Cheers,
>>>
>>> Julian
>>>
>>>
>>> On 13 April 2013 01:11, Julian Brooks
>>> <jbeezez at gmail.com
>>> <mailto:jbeezez at gmail.com>
>>> <mailto:jbeezez at gmail.com
>>> <mailto:jbeezez at gmail.com>>> wrote:
>>>
>>> Hey all,
>>>
>>> Some success finally:
>>>
>>> Hurrah!!
>>>
>>> The scl breakout pin on the pi proto
>>> plate wasn't working properly.
>>>
>>> When unscrewed halfway it works, when
>>> fully screwed in it doesn't.
>>>
>>> So - now got this:
>>>
>>> i2cdetect -y 0
>>>
>>> 0 1 2 3 4 5 6 7 8 9 a b c d e f
>>>
>>> 00: -- -- -- -- -- -- -- 0a -- -- --
>>> -- --
>>>
>>> 10: -- -- -- -- -- -- -- -- -- -- -- --
>>> -- -- -- --
>>>
>>> 20: -- -- -- -- -- -- -- -- -- -- -- --
>>> -- -- -- --
>>>
>>> 30: -- -- -- -- -- -- -- -- -- -- -- --
>>> -- -- -- --
>>>
>>> 40: -- -- -- -- -- -- -- -- -- -- -- --
>>> -- -- -- --
>>>
>>> 50: -- -- -- -- -- -- -- -- -- -- -- --
>>> -- -- -- --
>>>
>>> 60: -- -- -- -- -- -- -- -- -- -- -- --
>>> -- -- -- --
>>>
>>> 70: -- -- -- -- -- -- -- --
>>>
>>> and
>>>
>>> i2cdump -y 0 0xa
>>> No size specified (using byte-data
>>> access)
>>>
>>> Gives a whole host of stuff I don't yet
>>> understand but I don't care
>>> currently as something is actually
>>> happening.
>>>
>>> Will figure out a way of saving the
>>> console info (any hints
>>> anyone?) as it gets badly mangled when
>>> cutting and pasting but
>>> basically something like this:
>>>
>>> i2cdump -y 0 0xa
>>> No size specified (using byte-data
>>> access)
>>> 0 1 2 3 4 5 6 7 8 9 a
>>> b c d e
>>> f 0123456789abcdef
>>> 00: ff XX XX XX XX XX XX ff XX XX XX XX
>>> ff ff ff XX .XXXXXX.XXXX...X
>>> 10: XX ff XX XX XX XX XX ff XX ff XX ff
>>> XX XX ff XX X.XXXXX.X.X.XX.X
>>> 20: ff XX XX ff XX XX ff XX XX XX XX ff
>>> XX XX XX ff .XX.XX.XXXX.XXX.
>>> 30: XX ff XX ff XX XX XX XX ff ff ff XX
>>> XX XX XX XX X.X.XXXX...XXXXX
>>> 40: XX XX XX ff XX ff XX XX XX 64 XX XX
>>> d5 XX XX ff XXX.X.XXXdXX?XX.
>>> 50: XX ff XX XX XX XX XX XX XX ff XX XX
>>> ff XX XX XX X.XXXXXXX.XX.XXX
>>> 60: ff XX XX XX ff XX XX XX XX XX XX XX
>>> XX ff XX XX .XXX.XXXXXXXX.XX
>>> 70: XX XX XX XX XX XX XX ff XX XX XX XX
>>> XX XX XX XX XXXXXXX.XXXXXXXX
>>> 80: XX ff XX XX ff ff XX XX XX ff XX XX
>>> XX XX XX XX X.XX..XXX.XXXXXX
>>> 90: XX XX ff XX XX ff XX ff XX ff ff XX
>>> XX ff ff XX XX.XX.X.X..XX..X
>>> a0: XX ff XX XX ff XX XX XX XX XX XX XX
>>> XX XX ff XX X.XX.XXXXXXXXX.X
>>> b0: XX XX ff XX XX XX ff XX XX ff XX XX
>>> XX XX XX XX XX.XXX.XX.XXXXXX
>>> c0: XX XX XX XX ff XX XX ff ff XX XX ff
>>> ff XX XX XX XXXX.XX..XX..XXX
>>> d0: XX XX XX XX XX ff XX ff XX XX XX XX
>>> XX ff XX ff XXXXX.X.XXXXX.X.
>>> e0: XX XX XX ff XX ff XX XX XX XX XX XX
>>> XX XX ff XX XXX.X.XXXXXXXX.X
>>> f0: ff XX ff ff XX XX XX XX XX XX XX XX
>>> XX XX ff XX .X..XXXXXXXXXX.X
>>>
>>>
>>> Progress at least.
>>>
>>> Cheers,
>>>
>>> Julian
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 12 April 2013 11:27, Julian Brooks
>>> <jbeezez at gmail.com
>>> <mailto:jbeezez at gmail.com>
>>> <mailto:jbeezez at gmail.com
>>> <mailto:jbeezez at gmail.com>>> wrote:
>>>
>>> Message resent for thread archives
>>> with smaller picture size.
>>>
>>> Julian
>>>
>>> ---------- Forwarded message
>>> ----------
>>> From: *Julian Brooks*
>>> <jbeezez at gmail.com
>>> <mailto:jbeezez at gmail.com>
>>> <mailto:jbeezez at gmail.com
>>> <mailto:jbeezez at gmail.com>>>
>>> Date: 11 April 2013 19:24
>>> Subject: Re: [PD] Sensors GPIO
>>> Raspberry Pi Pd
>>> To: Martin Peach
>>> <martin.peach at sympatico.ca
>>> <mailto:martin.peach at sympatico.ca>
>>> <mailto:martin.peach at __sympatico.ca
>>> <mailto:martin.peach at sympatico.ca>>>
>>> Cc: PD List <pd-list at iem.at
>>> <mailto:pd-list at iem.at>
>>> <mailto:pd-list at iem.at
>>> <mailto:pd-list at iem.at>>>
>>>
>>>
>>> Hey Martin / list,
>>>
>>> Finally got all the stuff and ...
>>>
>>> It’s not working!
>>>
>>> We spent the day soldering cables
>>> and connecting stuff up as per
>>> the Omron ‘App Note 01’ spec sheet.
>>>
>>> Started off super-conservative
>>> using the I2C level converter
>>> (case 3 page 4)
>>>
>>> http://www.adafruit.com/__products/757#Blog/Flickr
>>>
>>> <http://www.adafruit.com/products/757#Blog/Flickr>
>>>
>>> We tried resistors on both sides
>>> (being super paranoid!) and
>>> then we took the low (Pi) side
>>> ones off.
>>>
>>> We then moved on to case 2 page 3
>>> of this same document…
>>>
>>> At each stage we checked with
>>> “I2Cdetect –Y 1” and nothing was
>>> visible.
>>>
>>> The grid shows no attached devices
>>> every time we run it.
>>>
>>> We re-booted at every stage
>>> following the various online
>>> tutorials/methods of setting up I2C
>>> GPIO on the Pi (checked &
>>> double checked).
>>>
>>>
>>> As you can see we’re using a pi
>>> protoplate:
>>>
>>> https://www.adafruit.com/__products/801
>>> <https://www.adafruit.com/products/801>
>>>
>>> In the photo I’ve attached the
>>> cables are coded as follows:
>>>
>>> Orange GND
>>>
>>> Yellow 5v
>>>
>>> Blue SCL
>>>
>>> Green SDA
>>>
>>> The white is also 5v for the pull
>>> up resistors.
>>>
>>> The resistor values are 4.7k btw.
>>>
>>> We have tested the cable that
>>> terminates at the sensor and all
>>> that is OK.
>>>
>>> I put a multimeter on the GND and
>>> SDA solder points on the
>>> sensor itself and got 3.7v…
>>>
>>> I put a multimeter on the GND and
>>> SCL solder points on the
>>> sensor itself and got 0.0v…
>>>
>>> Don’t know if this means anything
>>> or could be useful to know!
>>>
>>> Stuck and frustrated now but hey, 3
>>> weeks ago I knew absolutely
>>> bugger all about any of this and
>>> now I do (sort of).
>>>
>>> I'm thinking we could do with the
>>> most basic i2c sensor we can
>>> find as we have nothing to compare.
>>>
>>> Tonight I'm going to d/l a fresh
>>> raspbian and start from scratch
>>> to check that end.
>>>
>>> Feel like if we can't get past the
>>> 'i2c-tools' tests we're
>>> screwed - never mind getting it in
>>> and out of Pd.
>>>
>>> Any thoughts/pointers/options from
>>> anyone will be really
>>> appreciated?
>>>
>>>
>>> Cheers,
>>>
>>>
>>> Julian
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _________________________________________________
>>> Pd-list at iem.at <mailto:Pd-list at iem.at>
>>> mailing list
>>> UNSUBSCRIBE and account-management ->
>>>
>>> http://lists.puredata.info/__listinfo/pd-list
>>> <http://lists.puredata.info/listinfo/pd-list>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Pd-list at iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>
>>
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
// based on elinux.org/interfacing_with_I2C_Devices
// Martin Peach 20130416
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <linux/i2c.h>
#include <linux/i2c-dev.h>
#include <unistd.h>
//#include <sys/ioctl.h>
#include <sys/types.h>
//#include <sys/stat.h>
#include <fcntl.h>
#include <arpa/inet.h>
#include <netinet/in.h>
#include <sys/socket.h>
// Set a Pd [netreceive] to listen on this PORT
#define PORT 33333
// Pd is running on this machine IP
#define IP "192.168.2.15"
//#define IP "127.0.0.1"
// The SENSOR_PACKET_SIZE is 35 for D6T44L, 19 for D6T8L
#define SENSOR_PACKET_SIZE 35
// PD_SELECTOR is the first item in the message sent to netrecceive
#define PD_SELECTOR "d6t44l"
// this is Omron's crc code from the DST-44L/DST-8L Thermal Sensor Whitepaper
unsigned char calc_crc (unsigned char data);
int D6T_checkPEC (unsigned char *buf, int pPEC);
unsigned char calc_crc (unsigned char data)
{
int index;
unsigned char temp;
for (index = 0; index < 8; index++)
{
temp = data;
data <<= 1;
if (temp & 0x80) data ^= 0x07;
}
return data;
}
int D6T_checkPEC (unsigned char *buf, int pPEC)
{
unsigned char crc = 0;
int i;
//crc = calc_crc( 0x14 );
//crc = calc_crc( 0x4C ^ crc );
crc = calc_crc( 0x15 ^ crc );
for ( i = 0; i < pPEC; i++)
{
crc = calc_crc(buf[i] ^ crc);
// if (crc == buf[pPEC]) printf("MATCH at %d\n", i);
}
printf("D6T_checkPEC says 0x%02X\n", crc);
return (crc == buf[pPEC]);
}
int main (int argc, char **argv)
{
int file;
char filename[32];
int addr = 0x0A;
unsigned char inbuf[63];
unsigned char outbuf;
char netbuf[256];
const char *buffer;
int i, j, s;
int initialized = 0;
struct sockaddr_in sock;
// set up a socket to send UDP datagrams through
if (( s = socket( AF_INET, SOCK_DGRAM, IPPROTO_UDP )) < 0)
{
printf ("Unable to create socket (%d)\n", errno);
buffer = strerror(errno);
printf(">> %s <<\n", buffer);
exit ( EXIT_FAILURE );
}
memset (( char *) &sock, 0 , sizeof(sock) );
sock.sin_family = AF_INET;
sock.sin_port = htons ( PORT );
if ( inet_aton( IP, &sock.sin_addr ) == 0 )
{
printf ( "Unable to make address from %s\n", IP );
exit ( EXIT_FAILURE );
}
// The Omron sensor streams data after being initialized
if ( argc > 1 ) initialized = atoi(argv[1]);
printf("%s: initialized:%d\n", argv[0], initialized);
// Open the I2C connection
sprintf(filename, "/dev/i2c-1");
if ((file = open(filename, O_RDWR)) < 0)
{
printf ("Failed to open the bus. (%d)\n", errno);
exit (EXIT_FAILURE);
}
if (ioctl(file, I2C_SLAVE, addr) < 0)
{
printf ("Failed to acquire bus access and/or talk to slave. (%d)\n", errno);
exit (EXIT_FAILURE);
}
// start reading packets
do
{
do
{
// clear the inbuf first
for ( i = 0; i < SENSOR_PACKET_SIZE; ++i) inbuf[i] = 0;
outbuf = 0x4C; // the command
// we only need to write the command once.
// After that the sensor will return data
// any time it is read.
if (! initialized)
{
if (write( file, &outbuf, 1 ) != 1)
{
printf("Write failed (%d)\n", errno);
buffer = strerror(errno);
printf(">> %s <<\n", buffer);
exit (EXIT_FAILURE);
}
initialized = 1;
}
if (read (file, inbuf, SENSOR_PACKET_SIZE) != 35)
{
printf("Read failed (%d)\n", errno);
buffer = strerror(errno);
printf(">> %s <<\n", buffer);
}
} while (!D6T_checkPEC (inbuf, SENSOR_PACKET_SIZE-1));
for (i = 0; i < SENSOR_PACKET_SIZE-1; i += 2)
{
printf("%d ", inbuf[i]+(inbuf[i+1]<<8));
}
printf("<0x%02X>\n", inbuf[SENSOR_PACKET_SIZE-1]);
j = sprintf (netbuf, PD_SELECTOR);
for (i = 0; i < SENSOR_PACKET_SIZE-1; i += 2)
{
j += sprintf(&netbuf[j], " %d", inbuf[i] + (inbuf[i+1]<<8));
}
j += sprintf(&netbuf[j], "\n"); // CR NOT semicolon for Pd's [netreceive]
if (sendto ( s, netbuf, j, 0, (const struct sockaddr *)&sock, sizeof(sock)) < 0 )
{
printf ("sendto error (%d)\n", errno);
buffer = strerror (errno);
printf (">> %s <<\n", buffer);
}
printf("%s\n", netbuf);
usleep (400000); // wait 400ms
} while (1);
close(file);
return EXIT_SUCCESS;
}
-------------- next part --------------
#N canvas 0 0 857 610 10;
#X obj 34 111 unpack 1 2 3 4 5 6 7 8 9;
#X obj 34 39 netreceive 33333 1;
#X floatatom 34 197 5 0 0 0 - - -;
#X floatatom 74 197 5 0 0 0 - - -;
#X floatatom 114 197 5 0 0 0 - - -;
#X floatatom 154 197 5 0 0 0 - - -;
#X floatatom 194 197 5 0 0 0 - - -;
#X floatatom 234 197 5 0 0 0 - - -;
#X floatatom 274 197 5 0 0 0 - - -;
#X floatatom 314 197 5 0 0 0 - - -;
#X floatatom 354 197 5 0 0 0 - - -;
#X obj 57 305 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -260097
-1 -1 6909 1;
#X obj 77 305 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034
-1 -1 6020 1;
#X obj 97 305 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034
-1 -1 6426 1;
#X obj 117 305 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034
-1 -1 6477 1;
#X obj 137 305 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034
-1 -1 6401 1;
#X obj 157 305 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034
-1 -1 6375 1;
#X obj 177 305 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034
-1 -1 6274 1;
#X obj 197 305 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034
-1 -1 6274 1;
#X obj 217 305 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034
-1 -1 6248 1;
#X obj 34 79 route d6t8l d6t44l;
#X obj 462 96 unpack 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17;
#X floatatom 390 113 5 0 0 0 - - -;
#X floatatom 404 157 5 0 0 0 - - -;
#X floatatom 444 157 5 0 0 0 - - -;
#X floatatom 484 157 5 0 0 0 - - -;
#X floatatom 524 157 5 0 0 0 - - -;
#X floatatom 404 187 5 0 0 0 - - -;
#X floatatom 444 187 5 0 0 0 - - -;
#X floatatom 484 187 5 0 0 0 - - -;
#X floatatom 524 187 5 0 0 0 - - -;
#X floatatom 404 217 5 0 0 0 - - -;
#X floatatom 444 217 5 0 0 0 - - -;
#X floatatom 484 217 5 0 0 0 - - -;
#X floatatom 524 217 5 0 0 0 - - -;
#X floatatom 404 247 5 0 0 0 - - -;
#X floatatom 444 247 5 0 0 0 - - -;
#X floatatom 484 247 5 0 0 0 - - -;
#X floatatom 524 247 5 0 0 0 - - -;
#X text 59 251 Martin Peach 2013_04_20;
#X connect 0 0 2 0;
#X connect 0 1 3 0;
#X connect 0 2 4 0;
#X connect 0 3 5 0;
#X connect 0 4 6 0;
#X connect 0 5 7 0;
#X connect 0 6 8 0;
#X connect 0 7 9 0;
#X connect 0 8 10 0;
#X connect 1 0 20 0;
#X connect 2 0 11 0;
#X connect 3 0 12 0;
#X connect 4 0 13 0;
#X connect 5 0 14 0;
#X connect 6 0 15 0;
#X connect 7 0 16 0;
#X connect 8 0 17 0;
#X connect 9 0 18 0;
#X connect 10 0 19 0;
#X connect 20 0 0 0;
#X connect 20 1 21 0;
#X connect 21 0 22 0;
#X connect 21 1 23 0;
#X connect 21 2 24 0;
#X connect 21 3 25 0;
#X connect 21 4 26 0;
#X connect 21 5 27 0;
#X connect 21 6 28 0;
#X connect 21 7 29 0;
#X connect 21 8 30 0;
#X connect 21 9 31 0;
#X connect 21 10 32 0;
#X connect 21 11 33 0;
#X connect 21 12 34 0;
#X connect 21 13 35 0;
#X connect 21 14 36 0;
#X connect 21 15 37 0;
#X connect 21 16 38 0;
More information about the Pd-list
mailing list