Yop,

found people that succed in installing Pd-extented on a cubieboard2 (6month ago). That's in french, and is a bit concise (notes rather than a tuto) : http://bricoles.du-libre.org/doku.php?id=cubieboard:start
They have an already-compiled pd-extended that can be downloaded but I'm not sure yet of the linux version they use (again, the text is a bit confusing).

Another page, on getting a cubieboard working with usb external soundcards and pd-extended : http://alotof.org/w/Small_machine_for_open_field

When I see the perfs/price ratio ad knowing this could be done with some guidelines I'm clearly leaning towards a cubieboard project. And I only searched for an hour or so...

Nau

Yop,

good news from Autostatic ! : http://linux-audio.4202.n7.nabble.com/cubieboard-dac-module-td87862.html

Latency can be good on this device.

I'm very close to order one.

Nau

Yop,

@katjav said:

If you zeropad an IR, process in frequency domain and bring it back to time domain, you can easily discard samples, like the non-causal part of an IR. But in a real time patch, you really have to transform the zeropadded signal in an upsampled fft block. For example if the non-zero signal part is 1024 samples, transform it with a 2048 point fft. But this is no trivial thing to do in Pd. A signal upsampled by the [block~] object appears diluted with zero's, that's not what you want. A solution could be to reposition the non-zero samples using [tabread~] / [tabwrite~] with an index table designed for the purpose. And after ifft, dilute again before downsampling. Katja

I tried to make a 2x zeropadded version of my IR computation patch. Again, I'm not sure at all it actually works, so I hope Katjav or anyone else will comment it. I couldn't figure out how to remove zeroes and relocate audio stream samples within an upsampled realtime subpatch, so I tried a workaround. The input audio tables are chopped into frames and the frames copied into another table, alternating with zero frames to create a zeropadded audio table (in the main patch, no upsampling), and then play that table inside an upsampled subpatch. Then I go on with the usual computations. No need of "re-delution" here as I don't have to get back into the time domain to do these calculations.

It could be actually working, but I couldn't find a way to make consistency checks. The spectrums and IR are very close to the one calculated with the previous version of the patch, and it still sounds good. I wish I had found exactly all the values of the not-zeropadded magnitudes in the zeropadded results, saparated by new interpolated values, but It seems not to be the case. I'll be playing with text editors, gnuplot and Ocatve to enhance my graph capabilities (it's not trivial to export data from pd to make a plot, from my point of view). There's probably a wrong "normalizing factor" in fft mag and phase computation in the upsampled subpatch, as I maintained the old 32768 value. That's what I can say so far.

The frame length is 32768 and the zeropadding leads to 65536 samples fft size, that is pretty long (not from the computational workload point of view, as this is done not in real time). It could be more interesting to maintain a maximum fft size of 65536 but with frame length 2, 4 or 8 times smaller, combined with the corresponding zeropadding process. I'd like to investigate this as a next step, maybe with an adaptative patch (it's boring to make several parallel versions of the same patch).

But I won't do that before someone here has given me opinions on my zeropadding workaround, sorry I'm a forum's slave

Attached file is the IR computation patch, to be used with the previous material.

Thank you,

Nau

http://www.pdpatchrepo.info/hurleur/ir_construction_16_zeropadded.pd

Yop,

I gave a break to the zeropadding prospectives, and tried the least square method for "system identification" (useful keywords).

I found the page http://eeweb.poly.edu/iselesni/lecture_notes/least_squares/ and played with the Matlab scripts under Octave. Made two 1000samples-long IRs, one using 30000 samples of the glissando (Toeplitz1), the other using the first 100000 samples of tune2 (Toeplitz_jungle). They "play" rather less "precise" or "open" than the IRs obtained with the pd patch discussed earlier, and have heavier tails (I didn't bother to fade them out), but they are still doing a substantial part of the job.

Longer data vectors and IRs will soon lead to an memory overflow, so the job has to be done with shorter data, that's the reason why I used tune2 to make a test, wondering if it would add "liveliness" through liver input than the classical glissando for such a short data length. I personally do prefer IR_Toeplitz_jungle to IR_Toeplitz1.

The data waves are opened into Pd, than saved to ascii files easily handled by Octave. Once the IR is calculated (in single precision) it is saved into an ascii file in order to be read by Pd and finally converted to wav. This workflow should be modified in order to preserve data precision, I guess. I imagine that Octave can handle wav files with the corresponding package.

To be continued...

Nau

http://www.pdpatchrepo.info/hurleur/least_squares_nau.zip

Interesting method, it seems that all sorts of dsp matters can be solved with least squares. I never understood how it is done, and still don't understand after reading the article. Anyway if Octave can do it, that's nice. And it seems to sound OK. One thing I noticed when looking at the IR plots, is that the energy is concentrated in the left side, but they are not as minimum-phase as could be. You could still try to rearrange phases in these IR's to minimize the sudden cut at the right side.

By the way I tried to work out an upsample-and-zeropadding test routine, and found that the plots within the upsampled patch do not graph the actual array content. This is very confusing as it is hard to check if things happen as intended. Looking at the array list however, it gives the correct result. See attached patch (or skip if you give up on zeropadding).

There's another thing to reckon with when doing fast convolution with Pd's fft (unless it is magnitude-only): phases are not processed as if time zero is centered in the fft frame, with phases ranging from -pi to pi, but rather it assumes phase 0 to 2pi. When doing complex multiplications (or divisions, for inverse filtering), this is not a useful range. There are tricks to get it right, like rotating time domain samples within the frame, or alternating phases in frequency domain before processing.

Katja

http://www.pdpatchrepo.info/hurleur/zeropad-test.pd

Thanks Katjav. I'll check this out.

Yop,

@katjav said:

By the way I tried to work out an upsample-and-zeropadding test routine, and found that the plots within the upsampled patch do not graph the actual array content. This is very confusing as it is hard to check if things happen as intended. Looking at the array list however, it gives the correct result. See attached patch (or skip if you give up on zeropadding).
Katja

Here's a small patch that allows comparison between various frame sizes and with or without zeropadding. It loosely follows the Bitweenie article cited above.

Any suggestion ? The "normalizing" factors used in the fft magplots could maybe be refined, for example...

Nau

http://www.pdpatchrepo.info/hurleur/zeropadded_article_katjav.pd

That is a great demo indeed. The comparison clearly illustrates that zero padding does not give better spectral resolution, while increasing input frame size does. With zero padding you get better interpolation in the spectrum, which is interesting if you want to calculate frequencies of harmonic peaks. But the most common purpose for zero padding is to get reduced phase angles so you can manipulate phases in frequency domain without circular convolution effect.

It seems to me that factor 2 zero padding (N samples + N zeroes) would always be sufficient to avoid circular convolution. Multiplication of two complex numbers each with a phase within range -pi/2 till pi/2 will avoid wrapping, which is exactly what you want. Would be nice to have a demo of that too. Unfortunately Pd's fft objects give phases in the range 0 till 2pi so this would require more reorganisation of the input samples (swapping the input frame halves).

There is by the way a frequency domain equivalent of zero padding a signal: upsample a signal by zero padding it's spectrum. In Pd this would only work if the spectrum is written to arrays in one subpatch, and read and ifft'ed in another subpatch with larger block size for a larger zero padded fft.

When using hann windowing for fft and ifft you need 4 times overlap. This is missing in your patch, Nau. Therefore the reconstruction of subpatches fft-analysis1024 and fft-analysis8192 sound weird.

Katja

Thanks Katjav !

I made the changes in the two non-zeropadded subpatches and it works fine. But I can't explain why this doesn't work/isn't needed in zeropadded subpatches (sounds weird and more than 3/2 times greater in fft values than without overlapping).

In my impulse response calculation patch I got good results without zeropadding and without overlapping, but with Hann windowing. I made an overlapped version and discarded it, because it was difficult to decide which one was the best from my very subjective point of view, even though they were prettty different. I do prefer without overlapping, it seems to have "more body" to me. So now I know now the overlapped one is theorically the best one and I will try to educate my ears.

Here are two IRs, the first one Hann windowed but not overlapped (neither zeropadded), the second one Hann windowed, 4 times overlapped, not zeropadded.
convol5.pd allows to make a listening test, providing you have the previously uploaded material.

I will make a zeropadded version of my IR calculation patch and share results.

My understanding of fft processing seems cursed to be eternally shallow...

Nau

http://www.pdpatchrepo.info/hurleur/IR_wood1.wav

Thanks Katjav !

I made the changes in the two non-zeropadded subpatches and it works fine. But I can't explain why this doesn't work/isn't needed in zeropadded subpatches (sounds weird and more than 3/2 times greater in fft values than without overlapping).

In my impulse response calculation patch I got good results without zeropadding and without overlapping, but with Hann windowing. I made an overlapped version and discarded it, because it was difficult to decide which one was the best from my very subjective point of view, even though they were prettty different. I do prefer without overlapping, it seems to have "more body" to me. So now I know now the overlapped one is theorically the best one and I will try to educate my ears.

Here are two IRs, the first one Hann windowed but not overlapped (neither zeropadded), the second one Hann windowed, 4 times overlapped, not zeropadded.
convol5.pd allows to make a listening test, providing you have the previously uploaded material.

I will make a zeropadded version of my IR calculation patch and share results.

My understanding of fft processing seems cursed to be eternally shallow...

Nau

http://www.pdpatchrepo.info/hurleur/IR_wood1.wav

Thanks Katjav !

I made the changes in the two non-zeropadded subpatches and it works fine. But I can't explain why this doesn't work/isn't needed in zeropadded subpatches (sounds weird and more than 3/2 times greater in fft values than without overlapping).

In my impulse response calculation patch I got good results without zeropadding and without overlapping, but with Hann windowing. I made an overlapped version and discarded it, because it was difficult to decide which one was the best from my very subjective point of view, even though they were prettty different. I do prefer without overlapping, it seems to have "more body" to me. So now I know now the overlapped one is theorically the best one and I will try to educate my ears.

Here are two IRs, the first one Hann windowed but not overlapped (neither zeropadded), the second one Hann windowed, 4 times overlapped, not zeropadded.
convol5.pd allows to make a listening test, providing you have the previously uploaded material.

I will make a zeropadded version of my IR calculation patch and share results.

My understanding of fft processing seems cursed to be eternally shallow...

Nau

http://www.pdpatchrepo.info/hurleur/IR_wood1.wav

Hi there,

here is a naive spectrum-tweaking patch.

Open a magnitude spectrum saved in a txt file (here it is an asymmetric one, 32768 samples, coming from my previous "system identification" aka microphone simulation patch).

Open a test tune as a wav file. (left:piezo, right:dpa4099)

Then use Maelstorm's rslider to create a parabola (of course other windows could be implemented, this is the first one I wanted to try) mask in order to make a selection region. (take a look at the four modes of hrslider). Only the left part of the spectrum is used for selection, though the modifications occur in a mirror fashion between left and right parts of the mag spectrum.

Then, using the knob, amplify or attenuate the selected region (region is multiplied by a factor (1+knob*parabola)).

Then bang the minimum phase impulse response calculator.

Finally, bang the listening test and browse between piezo, simulated microphone and dpa 4099 microphone sounds. Simulation is done by convolving the piezo track with the impulse response computed by the patch. Later on it is always possible to edit the spectrum and bang the IR calculation on-the-fly to hear directly the spectral changes (simu selected on the hadio), or, from time to time, restore the original spectrum reloading the spectrum.txt file.

This patch is maybe a bit naive as is, but may also suit someone's needs. It's still a bit buggy with artefacts at the boundaries of selection regions, and could gain resolution using the same space in order to visualize only the left part of the spectrum (left both here because I wanted to be more self-explanatory).

Material : http://bitshare.com/files/bdd4x65v/spectrum_editor.zip.html

Nau