Matrices and reallocating memory
EDIT:
The original thread title was: Interrupt/disable perform method while reallocating memory
I changed it, as it was based on searching for a solution caused by faulty code.
After discarding my code the topic of the thread got a new direction.
Hi,
I try to write an external, which calculates the averages of samples at their positions over time.
For example:
With average time = 3:
3 signals given over 3 blocks: [1, 3, 5 ...], [2, 4, 6...],[1, 3, 5...] should result in [1.33, 3,33, 5,33, ...]
The example code below works, as long as I don't try to resize the average time to a lower value while dsp is running.
On changing the average time while dsp is on, my code reallocates memory for the average vector. The result is an exception in the perform method in line 53 x->avg[n] -= x->sampel_arr[x->pos][n];
The commented lines using x->busy were an attempt to use a switch. But the code of the switch is never used, so it doesn't work.
Does anybody have an idea how to bypass the perform method while memory is reallocated?
#include "m_pd.h"
#include <string.h>
#include <stdlib.h>
static t_class *average_tilde_class;
typedef struct _average_tilde {
t_object x_obj;
t_int len_delay;
t_int block_size;
t_int pos;
t_sample **sampel_arr;
t_float *avg;
t_int busy;
t_inlet* x_in;
t_outlet* x_out;
} t_average_tilde;
void average_tilde_free(t_average_tilde *x)
{
// Deallocate rows
for (int i = 0; i < x->len_delay; ++i)
free(x->sampel_arr[i]);
// Deallocate columns
free(x->sampel_arr);
// Deallocate avg
free(x->avg);
}
t_int *average_tilde_perform(t_int *w)
{
t_average_tilde *x = (t_average_tilde *)(w[1]);
t_sample *in = (t_sample *)(w[2]);
t_sample *out = (t_sample *)(w[3]);
int block = (int)(w[4]);
/*if (x->busy == 1) {
while (block--) {
*out++ = *in++;
}
return (w + 5);
};*/
float val;
for (int n = 0; n < x->block_size; n++) {
x->avg[n] -= x->sampel_arr[x->pos][n];
val = in[n] / x->block_size;
x->avg[n] += val;
x->sampel_arr[x->pos][n] = val;
*out++ = x->avg[n];
}
x->pos++;
if (x->pos == x->len_delay) x->pos = 0;
return (w + 5);
}
void resize_avg_array(t_average_tilde *x)
{
int i,j;
/*post("resize");
x->busy = 1;*/
// Allocate the columns
x->sampel_arr = (int**)realloc(x->sampel_arr, x->len_delay * sizeof(int*));
/*if (x->sampel_arr == NULL)
post("error");*/
// The new column's pointer must be initialised to NULL
for (i = 0; i < x->len_delay; i++)
x->sampel_arr[i] = NULL;
// Allocate the rows
for (i = 0; i < x->len_delay; i++) {
x->sampel_arr[i] = (float*)realloc(x->sampel_arr[i], x->block_size * sizeof(float));
/*if (x->sampel_arr == NULL)
post("error");*/
}
// Initialize the element(s)
for (i = 0; i < x->len_delay; i++)
for (j = 0; j < x->block_size; j++)
x->sampel_arr[i][j] = 0.0;
// Allocate avg-array
x->avg = realloc(x->avg, x->block_size * sizeof(float));
/*if (x->avg == NULL)
post("error");*/
// Initialize avg-array
for (i = 0; i < x->block_size; i++)
x->avg[i] = 0.0;
/*x->busy = 0;
post("resize2");
post(" ");*/
}
void average_tilde_dsp(t_average_tilde *x, t_signal **sp)
{
x->block_size = sp[0]->s_n;
float arr_size = sizeof(x->sampel_arr) / sizeof(x->sampel_arr[0][0]);
if (x->block_size * x->len_delay != arr_size)
resize_avg_array(x);
dsp_add(average_tilde_perform, 4,
x,
sp[0]->s_vec,
sp[1]->s_vec,
sp[0]->s_n);
}
void set_len_delay(t_average_tilde *x, t_floatarg f)
{
if ((int)f > 0) x->len_delay = (int)f;
resize_avg_array(x);
}
void init_array(t_average_tilde *x)
{
int i = 0, j = 0;
// Allocate the columns
x->sampel_arr = (int**)calloc(x->len_delay, sizeof(int*));
// Allocate the rows
for (i = 0; i < x->len_delay; i++)
x->sampel_arr[i] = (float*)calloc(x->block_size, sizeof(float));
// Initialize the element(s)
for (i = 0; i < x->len_delay; i++)
for (j = 0; j < x->block_size; j++)
x->sampel_arr[i][j] = 0.0;
// Initialize avg-array
x->avg = realloc(x->avg, x->block_size * sizeof(float));
for (j = 0; j < x->block_size; j++)
x->avg[j] = 0.0;
}
void *average_tilde_new(t_floatarg f)
{
t_average_tilde *x = (t_average_tilde *)pd_new(average_tilde_class);
// initialize values with defaults
x->len_delay = ((int)f > 0) ? (int)f : 10;
x->block_size = 64;
x->pos = 0;
init_array(x);
x->busy = 0;
x->x_out = outlet_new(&x->x_obj, &s_signal);
return (void *)x;
}
void init_average(void) {
average_tilde_class = class_new(gensym("r_avg~"),
(t_newmethod)average_tilde_new,
(t_method)average_tilde_free,
sizeof(t_average_tilde),
CLASS_DEFAULT,
A_DEFFLOAT, 0);
class_addmethod(average_tilde_class,
(t_method)average_tilde_dsp, gensym("dsp"), 0);
CLASS_MAINSIGNALIN(average_tilde_class, t_average_tilde, len_delay);
class_addfloat(average_tilde_class, set_len_delay);
}
void helloworld_setup(void) {
init_average();
}```
// The code for reallocation is taken from here:
// http://hesham-rafi.blogspot.de/2009/02/resize-2d-matrix-using-realloc.html
libpd on mac: clarification requested on expected behavior of cpp sample
Hi! I am running Pd-0.47-1-64bit on Mac OS 10.11.6 and libpd 0.9.2. I am trying to work with the samples/cpp/pdtest. Here's the github repo. I currently have an app that takes video and spits out a 2D array of color values for regions of interest to file. I have a pd patch that then loads those into a table and plays the corresponding pitch. I need the two (patch, c++ app) to coordinate the IPC.
I compiled the cpp code in the samples directory however, when running pdtest executable there is no patch opened. Is this by design? I was not able to find a pd-vanilla to build from source so took the most recent (pd-0.47-1-64bit.mac.tar.gz). Does libpd need to have the pd built after libpd? If so, can anyone please point me to a src file?
Here is a truncated output from running the compiled pdtest. Could someone tell me if this is what is expected?
Thank you for your help.
BEGIN Patch Test
Patch: "pd/test.pd" $0: 1003 valid: 1
Patch: "pd/test.pd" $0: 0 valid: 0
Patch: "pd/test.pd" $0: 1005 valid: 1
PD: PATCH OPENED: 1003
print: 0
PD: PATCH OPENED: 1005
print: 0
FINISH Patch Test
BEGIN Message Test
FINISH Message Test
BEGIN MIDI Test
FINISH MIDI Test
BEGIN Array Test
array1 len: 10
array1 0.0857145 0.328572 0.500001 0.57143 0.514287 0.47143 0.357144 0.285715 0.057143 0
array1 0 1 2 3 4 5 6 7 8 9
array1 10 10 10 10 10 10 10 10 10 10
FINISH Array Test
BEGIN PD Test
FINISH PD Test
Processing PD
PD: bang
PD: 100
PD: symbol test string
PD: bang
PD: 100
PD: symbol test string
PD: 1.23 a symbol
PD dollar zero: 1.23 a symbol
PD: 1.23 sent from a List object
PD: msg 1.23 sent from a List object
PD: 1.23 sent from a streamed list
PD MIDI: notein 2 60 64
PD MIDI: ctlin 2 0 64
PD MIDI: pgm 2 101
PD MIDI: midiin 1 239
PD: symbol test
PD: START MSG TEST
CPP: bang toCPP
CPP: float toCPP: 100
CPP: symbol toCPP: kaaa
CPP: list toCPP: 100 2.3 test 1 2 3 ffsfff
CPP: message toCPP: kaa 1 2.3 test ffs
PD: MSG TEST FINISH
PD: START MIDI TEST
PD: MIDI TEST FINISHED
PD: START ARRAY TEST
PD array1: 10
PD array1: 10
PD array1: 10
PD array1: 10
PD array1: 10
PD array1: 10
PD array1: 10
PD array1: 10
PD array1: 10
PD array1: 10
PD: FINISH ARRAY TEST
PD: test_abs: Hello World!
CPP MIDI: note on: 0 0 127
CPP MIDI: note on: 0 0 127
CPP MIDI: note on: 0 60 64
CPP MIDI: control change: 0 64 100
CPP MIDI: program change: 0 99
CPP MIDI: pitch bend: 0 2000
CPP MIDI: aftertouch: 0 100
CPP MIDI: poly aftertouch: 0 64 100
CPP MIDI: midi byte: 0 239
CPP: float env: 75.5457
CPP: float env: 87.9506
CPP: float env: 93.5842
...
CPP: float env: 88.5503
CPP: float env: 87.7612
print: 1
CPP MIDI: note on: 0 0 0
CPP MIDI: note on: 0 1 127
CPP: float env: 86.8932
...
CPP: float env: 41.2584
CPP: float env: 0
print: 2
CPP MIDI: note on: 0 1 0
CPP MIDI: note on: 0 2 127
...
print: 20
CPP MIDI: note on: 0 19 0
CPP MIDI: note on: 0 20 127
Trying to route or select a symbol that "looks like an integer"
[float] should be given a symbol method that tries to parse the incoming symbol to a float. If it can, forward the result to the float method. If it can't, error out as it currently does.
Downside: a patch author can not rely on [float] generating an error when it receives symbol atoms that can be parsed as floats. But it's a very edgy edge case where a patch author erroneously hooks up a symbol connection to [float], AND that symbol connection is only sending symbols that can be parsed as a float.
[muse] -- float array that acts like a musical scale
Creates music scales using simple lists or by sending new pitches to individual notes. The more creation arguments there are, the more inlets there will be. It sends a frequency value through the 1st outlet and the unaltered midi value through the 2nd outlet.
- [muse 40 4 7]
- Sending 0, 1, 2 returns 40, 44, 47 respectively.
- The scale cycles through higher and lower octaves
- 3, 4, 5 returns 52, 56, 59
- -1, -2, -3 returns 35, 32, 28
functions:
- [list | l | d | x | i ..(
- Takes a list of numbers and maps the values to the array.
- Any non-numeric values are skipped over.
- They're basically all the same function, with the differences being in their offsets and/or whether it should change the size of the scale implicitly based on list size.
-- i is an implicit list, which changes the size of the scale based on the number of arguments specified.
-- x is an explicit list, which means that it doesn't change the scale size because it's leaving that up to the user to change explicitly. This message is also good for changing the root note.
-- list or l is the default list, and whether it interprets lists implicitly or explicitly is based on whether the toggle "exp" is set to 1 or 0. By default, lists are interpreted implicitly.
-- d has an offset of 1. It's basically a short form of [list d ...( or, a list that skips the root note. Like a normal list, it also adheres to the "exp" toggle to determine whether it is implicit or explicit.
- [exp 1|0(
- sets a boolean to determine whether or not scale size is implied in the size of lists sent.
- if exp equals 1, scale size will not change, unless the list is preceded by i.
- if exp equals 0, scale size will change, unless the list is preceded by x.
- [n $1(
- sets the size of the scale.
- the scale by default, with no creation arguments, is only 2 float values. This amount grows based on how many arguments are specified. but the array also resizes itself automatically to twice its original size whenever a size requested goes over the current maximum range.
- the same doubling effect applies to lists with more arguments than the maximum scale size.
-- [muse 40 2 4 5 7 9 11] has 7 floats worth of bytes reserved for the scale.
-- upon receiving [n 16(, since 16 is greater than (7 x 2), scale is resized to hold 16 floats.
-- upon receiving [n 17(, scale is resized to hold 32 floats. This doesn't mean the scale uses all 32 notes, but the space is now reserved if you ever decide to increase the scale size later.
- sets the size of the scale.
- [set $2 $1(
- scale is assigned the value $1 at index $2.
-- [set 6 11( set the 6th interval to 11.
- scale is assigned the value $1 at index $2.
- [ref $1(
- sets the reference pitch of middle A.
-- default value is 440.
- sets the reference pitch of middle A.
- [tet $1(
- assign the number of tones in an octave.
-- tones refer to how large a semi-tone needs to be in order to evenly disperse an octave into a specific amount of distinct pitches.
- assign the number of tones in an octave.
- [oct $1(
- assign the number of notes in an octave.
-- notes refer to the number of semi-tones that the scale should jump when going to the next or previous octave.
- assign the number of notes in an octave.
- [octet $1( / [ot $1(
- assigns # of notes and # of tones simultaneously
- [peek label(
- prints the current scale.
- a label is optional.
- [ptr label(
- prints the current size of the float pointer that your scale uses. It isn't necessarily the same size as the scale itself.
Problems or missing understanding with send and receive
hi there,
i just started working with PD for an art project.
and somehow i'm stuck with send and receive.
so reduced from everything special around that's what i want to do:
i have a number box connected to the right inlet of a float (memory) object.
and there is math operation objects ("+2", "+15", ...).
and there's bang object which gets the value stored in the float object.
because i need the the value of the float object several times i connected its outlet with a send-box ("s Xvalue") and everywhere i need the value of the float object i have a receive object ("r Xvalue").
and for the same reason - i need the value of the float objects several times - the bang object is connected with the float object throug send-receive ("s getValue" or "r getValue").
for some reason i don't know after changing value in the number-box then hitting the "getValue" bang, which activates the float memory box, the value hasn't changed. then i hit again and it is changed.
i have the same situation with a couple of number boxes and with some it's no problem with some it is.
and generally: isn't there a easier way to set a variable with a value and have it accessable in the whole programm without send/receive or linking
just as it is in most other programming languages?
thanks for any help
stephan
Arduino, ultrasonics and Pd: HELP needed for degree project!
Dear Pd'ers… I'm fairly new to Pd and have been using it during my 'Audio Production' degree at SAE college in London. I'm here to ask for help on my final degree project, which aims to control objects within Pd by way of proximity sensors connected to Arduino.
I have had moderate success, first using a Sharp GPD12 IR sensor connected to an analog port on an Arduino Diecimila, then a Devantech SRF02 connected via I2C to Arduino. I have managed to get Pure Data reading the sensor values using the Pure Data example included in SimpleMessageSystem (http://www.arduino.cc/playground/uploads/Code/SimpleMessageSystem.zip)... and only altering the number of the comport the Arduino appears on.
On the Arduino end, I have added the SimpleMessageSystem library, and am using the following sketch to run one or both of the sensors depending on whether or not I omit the SRF02 or GPD12 parts of the code.
// top //
#include <Wire.h>
#include <Servo.h>
#include <SimpleMessageSystem.h>
int sensorPin = 0;
int sensorValue = 0;
Servo servo1;
#define sensorAddress 0x70
#define readInches 0x50
#define readCentimeters 0x51
#define readMicroseconds 0x52
#define resultRegister 0x02
void setup()
{
Wire.begin();
Serial.begin(9600);
}
void sendCommand (int address, int command) {
Wire.beginTransmission(address);
Wire.send(0x00);
Wire.send(command);
Wire.endTransmission();
}
void setRegister(int address, int thisRegister) {
Wire.beginTransmission(address);
Wire.send(thisRegister);
Wire.endTransmission();
}
int readData(int address, int numBytes) {
int result = 0;
Wire.requestFrom(address, numBytes);
while (Wire.available() < 2 );{
}
result = Wire.receive() * 256;
result = result + Wire.receive();
return result;
}
void loop()
{
// SRF02 READING //
sendCommand(sensorAddress, readInches);
delay(70);
setRegister(sensorAddress, resultRegister);
int sensorReading = readData(sensorAddress, 2);
Serial.println(sensorReading);
delay (200);
// GPD12 READING //
sensorValue = analogRead(sensorPin);
int range = (6787 / sensorValue);
Serial.println(range);
delay(200);
}
// bottom //
Pure data is picking up the sensor's output as a decimal number, through the serial port, correctly, and showing this as a number in the SPECIAL CHARACTER section of the Pd patch, which I can then use to control various Pd parameters, like a slider for example.
If printing both sensor readings to the serial, the Pd patch will pick up the two sensor values alternately, but there seems no way of differentiating the two sensors within Pd, as they both come through the serial. I have tried prepending the serial print at the Arduino stage with a tag such as "IR" or "UL" for each sensor, but this simply ends up in nothing coming through in Pd.
Using one sensor gives the ability to control parameters with a fairly narrow detection range, but for the final version I would like to incorporate 4 or 5 sensors in order that I can cover nearly a full 360 degree range.
After a bit of research I have gone and bought 4 x Maxsonar EZ0's. They've got a wider range than the Devantech sensors, and can operate via I2C, serial or PWM. A number of people online seem to mention the improved stability when operating via PWM, so I thought this could be kinda useful.
I am going to London Hackspace tomorrow to get help with wiring up the sensors to my Arduino Diecimila, but for now, my main problem seems to be how to achieve greater communication between Pure Data and the sensors. It's all very good and well being able to take the decimal readout from an analog input to give one set of values in Pd, but I would like to know how to either to read (and trigger) each sensor discretely via PWM, or to somehow differentiate between each sensor's analog output, so that I can have the different sensors controlling different objects within Pd.
As well as SimpleMessageSystem, I looked at using the Pduino object. But to be honest, it is either not working properly (I have noticed reported issues with bugginess), or I am being stupid, as it has totally boggled my brain. In theory though, it seems like it should be able to do what I want, ie. send and receive commands between Arduino and Pd.
****************************************
So…. my questions for anyone out there with a knowledge of using Arduino + multiple sensors (preferably Maxsonar EZ's) with Pd are:
What is most appropriate for my project?
- Simple Message System or Pduino?
- analog or PWM?
And how do I get proper communication between the two platforms so I can discern discrete values from each sensor?
I'd really like to get a discussion going with this as (a) it would really help me in my degree (which ends in about 4 weeks!!!) and (b) I really want to share what I am doing, especially as the discussions on Arduino/Pd communication on the various forums seem a little patchy (at least for noobs like me). I also hope to continue my research in the future, sharing any findings I make with the community…
****************************************
PS. In the sharing spirit, please check out the Radio Tuner patch I've just posted over on the patch section of this forum - it's my first successful attempt at Pd... I hope you enjoy
How do I go about....
oh and if you did manage to find an OSC output from the liveOSC scripts, you would then need to call your LED the same as the OSC command from live, or you would need to reformat the command from live using puredata to that of the LED.
e.g. if LiveOSC has an OSC send called /live/tempo/beat (I doubt it does) then you would have LiveOSC script connect to your TouchOSC, and the LED would be also /live/tempo/beat.
It may be that even if there's no way to send OSC tempo beat messages from Live using the liveosc script, you could maybe use live to map the beat to move a controller, and send this information to puredata where you could reformat it.
I just checked http://github.com/willrjmarshall/AbletonDJTemplate/blob/44609dbd1be136d517c420f14fc987e9aa96fcc6/TouchOSCTemplate/LiveOSC/OSCAPI.txt
There isn't anything that will solely broadcast beats over OSC, but there are a couple of things that with some puredata manipulation might be able to do this:
live/tempo = Request current tempo, replies with /live/tempo (float tempo)
/live/tempo (float tempo) = Set the tempo, replies with /live/tempo (float tempo)
/live/time = Request current song time, replies with /live/time (float time)
/live/time (float time) = Set the time , replies with /live/time (float time)
It might (just) be possible to write code to examine the song tempo, examine regularly the song time and from there calculate when the beat will drop. I'm not about to start on this any time soon but there is the potential to do this. The amount of work might be offset by actually monitoring the metronome, or just listening to the music to get an idea where the bars are ;o)
Just guesses but good luck with it, I want to do similar as I'm working on a full remote DJ tool for TouchOSC (clip browser and selecter, tempo, monitoring, mixer, xfader, effects and filters). I'm using puredata for this, touchOSc and the l;iveOSC remote scripts. I tested all the theoretical bits for this and have it working, just need to but the behemoth PD together to handle it all! Oh, and another feature will be a toggle on the accelerometer to control any effect, fader etc so "put your hands in the air" and "drop the bass" will be actually doable! Of course, the main reason I want this is I like the music I spin and I'm sick of being stuck behind sensitive equipment where I can't dance properly
Arrays within data structures
ah ok, so essentially if i want to have a data structure that holds 8 arrays of floats i need to.
Define a struct and have the arrays defined as being another struct type eg:-
struct track-info-template array a float-struct array b float-struct etc....
and then in seperate sub patches in the main patch have structs which define float-struct thusly :-
struct float-struct float
then i need to append these onto the data window to create them, and then from there i can resize them/use them etc??
did i miss the documentation for this or is it just not written down anywhere?? i'm genuinly tempted to take all this knowledge and try and put together a comprehensive tutorial explaining all this.
Digital inputs not reading in arduino/pduino
Hi all..
I've been having troubles reading the digital inputs of an arduino duemilanove (328) using the pduino firmware. I mean having troubles like not reading anything from them at all.
Analog ins and digital outs work fine, but the DI do not want to read anything. I've checked that they are OK (I can effectively read them) with other sketches including the button read example from the arduino website, so there are no hardware issues.
I've tried he latest version of the pduino firmware, and went all the way back to pduino 0.4 with firmata 2.0. I even changed the moocow objects for flatspace as someone hinted somewhere here but to no avail (yes, I'm on windows XP).
I've tried the pduino-help and pduino-test patches included with the download and everything works except the digital input reading.
.. and of course, the digital ports are enabled and the pins' output mode are in 0 (input) and the serial port is set correctly both with the selector and inside the [arduino] object (just in case)
The toggle objects do not change at all in the lower right section of the pduino-test patch. As a matter of fact nothing comes out of any [route digital] object, even if it is directly connected to the [arduino] object
Am I missing something here?
any help would be appreciated
thanks
rick
Passing $1 to textfile through add message
first of all, if you want to write a float from the inlet to a textfile, you will need tell your [trigger] object to forward that float. at the moment your trigger object looks like [t b b b], that means, it only sends out bangs, no numeric values.
second point is, if you only want to save one float to a textfile, you don't need the combination of a [clear( message and a [add( message, you can use a [set( message instead. the sense of the [symbol( message i completely don't understand.
try it like this, should work, i guess:
[inlet] <- incoming float
|
[trigger bang float] <- first send the float, then a bang
| |
[write save.txt( [set $1( <- first set float, then write to file
| |
[textfile]