Hi,

I have been trying to make externals using C and I have some difficulties to find information about a maybe rough subject: I need to use severals arrays within an external which must be modified by current samples and returned once updated.

For instance, I am considering the following problem :

• I need to pass a signal sample (inlet~) named e[n] (current input sample);
• I neeed to pass two arrays of the same size N_tab, tab1 and tab2 (for instance corresponding to whole signals);
• I need to output one signal sample (outlet~) s([n] (current output sample);
• I need to output a modified version of array tab2.

The core dsp processing could be (for one sample or to be repeated inside a loop if externasl can only take a signal buffer instead of only one sample):
tab2 = tab2 + e[n] * tab1;
s[n] = tab2(0);
// In fact, I will use a circular buffer and pass the index of the buffer as inlet, and return
// the updated value of this index as another outlet.

I would very appreciate any help to cope with my problem (use of _array, _garray interesting to plot the arrays or another type of variables ?) as I do not see, for the moment, how to mix signals samples and (maybe) rather huge arrays in a same external.

I'm "lost in Pd translation" at this time while I intend to realize several externals, to process sound in realtime using pd and offer them (sources and binaries) by the end of the year, as soon as the whole set of object swill be efficient and documented.

Sincerly yours,
Laurent Millot

Generally, it's useful to look at the source of Pd and other externals to see how its done. I recommend looking at pd-0.41-4/src/d_array.c lines 686-839 ([tabsend~] and [tabreceive~]).

Note that in pd-0.41-4 the array access API has changed: the old API was not 64-bit safe. If you have issues with that change, I can show you how I handled it in my code.

@ClaudiusMaximus said:

Generally, it's useful to look at the source of Pd and other externals to see how its done. I recommend looking at pd-0.41-4/src/d_array.c lines 686-839 ([tabsend~] and [tabreceive~]).

Note that in pd-0.41-4 the array access API has changed: the old API was not 64-bit safe. If you have issues with that change, I can show you how I handled it in my code.

Hi, ClaudiusMaximus

Thanks a lot for your answers.

I have already worked with the "HOWTO write an external for Pure Data" and have some difficulties with, notably (I put the first compiled version of the external in a subfolder to use it within pd, while trying to see the code differences compiling the library elsewhere, without noticing any diference, obviously...), a potential bug in the code for span~.

• within the text:
  typedef struct _pan_tilde {
  t_object x_obj;
  t_sample f_pan;
  t_float f;
  } t_pan_tilde;

• within the code:
  typedef struct _pan_tilde {
  t_object x_obj;
  t_sample f_pan;
  t_sample f; // Here is the difference: t_sample rather than t_float (better for the use?)
  } t_pan_tilde;

I have made a first partial version (I have not translated the whole appendix) of a translation in French, adding some information about cross compilation, found in another external example.

I will consider to post it, if interesting, as soon as the translation would be enough good according to me. I will try to quote some potential mistyping errors to the author and german remaining formulation within next weeks, as, for the moment, I must first achieve several projects.

I have also studied another external code processing audio signals and begun to study the "m_pd.h" file and the d_array.c file or d_delay.c (quite fastly as I was in a hurry last night). I was searching for quoted versions and for another simple examples.

And I did not think, at this time, to see the code for tabsend~ or tabreceive~ functions: when you have the head in the handlebars, you do not see further than the end of your nose....

So, thanks a lot for the advice.

At this time I will just consider data in 16, 24 fixed or 32 floating point bits, so, I would not need the 64-bit representation: I do not use the FFT, working with an alternative potentially fast temporal method for convolution, needing far less requantization operations and then a less precise format for a more satisfying result.

But I could be quite interested in the future to consider 64-bit operations, so I would be happy to se how you manage this in your code.

I must have finished the related external(s) before next sunday as I will present the algorithm at the Audio Engineering Convention on monday 2008/05/19 at 10 am and I really would like to be able to perform a real time demonstration of the algortihm using pd...

I have much more experience with scilab and matlab prototyping, and I have been working since mid-january, with two assistants (doing a great and heavy work), to perform a C++ cross platform port of a scilab prototype of a perceptive audio scenes analyser I have designed, using the temporal convolution algorithm. So, I have been studying how to realise pd externals to have light but powerful real time demonstrators.

I will publish the sources (with a LGPL-like licence) and offer the binaries (Max OS 10.4 and 10.5.x for PPC or Intel-based processors, Windows XP and Vista at least, maybe Linux if its works directly) for downloading by the end of the year, once the documentation and the code will be enough satisfying and operational.

Once again, thanks a lot for your help. I will give feedback information and, maybe, ask for some more help, in next days... ;O)

Sincerly yours,
Laurent Millot

Laurent, if C++ is your preferred language and you want a flex_ible t_emplate for externals that incorporates a bit of cross platform forethought then hava a look at Flext.

http://grrrr.org/ext/flext/

@obiwannabe said:

Laurent, if C++ is your preferred language and you want a flex_ible t_emplate for externals that incorporates a bit of cross platform forethought then hava a look at Flext.

http://grrrr.org/ext/flext/

Hi Obiwannabe,

In fact I do not have really a preference between both langages, as I used both in my current projects, even if I have seen and made more C code, for the moment.

I am most "fluent" to develop with either matlab or scilab, either max/msp or pure data, but, now, to go from prototypes to powerfull and easier to distribute and use applications, I have been considering working with either C (DSP processing) or C++ (rather easier to build a GUI, according to my capabilities and available time) as I want to deliver cross platform applications: Objective-C is smart with Apple Developpers Tools but I am not sure it is really easy to perform cross platform applications with it.

As I mainly develop prototypes and physical models, play with ugly sets of equations, I do not have a great experience with these three languages. It may change in the following months.

And, as I need to succeed in finishing an external by sunday evening for a potential real time demonstration on monday 05/19 mrining, I have taken the first way to develop externals I found and thought I may be able to manage within less 2 weeks, a week ago!

Yet, I am going to have a quick look at Flext, today if possible, in order to determine if it is easier for me to perform the job by sunday using it rather than using C-coded externals.

My constraints are to be able to:
-receive two arrays, one sample, one circular buffer index as inputs;

• perform a simple addition between both arrays, one being multiplied by the input sample value, using a cricular buffer for the second one array;
• send the current sample output, the updated circula buffer array and an updated version of its index as output;
• make the whole external work for samples given by a 44.1 kHz and 16-bit wavefile, in real time!

I also need to be able to develop, at least another external, to change one of the arrays, in perceptive real time, to use it as input ( the first array, not the circular buffer) of the first external. And, being able to plot the modified array to show what it looks like could a nice improvement.

This array would be a caricatural time-varying impulse response, maybe, with changes related to the positions of the source and the receiver (within a time-varying ?) shoe-box room, taking into account several orders of reflexion.

I may know how to make the inner C code for DSP processing, I "just" need to encapsulate them in a pd external, enough efficient to present a temporal convolution algorithm without FFT, working yet in real time without (perceptible) latency with as long as possible "impulse reponses" (around 350 ms I guess or hope for the first version).

So, here are the rules, I "just" have to use the right external coding tool as I must have finished by the end of this week...

And, I will distribute the externals and their related code as soon as I will have time to write a good documentation, above all for the English version, which is not my native tongue, as you may have noticed 8;O).

Sincerly yours,
Laurent Millot