Several people asked for an update of project Slice//Jockey. It dates from Pd-Extended times. SliceJockey3 finally works with vanilla Pd. Find it here:

www.katjaas.nl/slicejockey/slicejockey.html

It needs a few external libraries which are available from deken for all current platforms. Details on the webpage. The project was verified to work on Linux (Intel and ARM), MacOS and Windows (tested through Wine).

I want to make some help and test patches with vanilla objects only. Is [output~] part of vanilla?

A video showing the try out of my wearable live sampling outfit:

Software is all Pd / Linux on an rugged convertible tablet (Panasonic CF-19) with touch screen. It feels good to be liberated from the conventional laptop table.

Katja

[partconvEQ10~] is a 10 band equalizer abstraction based on minimum-phase FIR filtering and partitioned convolution. Even though it uses a 2048 point FIR filter, it adds no more than a few samples latency to your patch. This is because the energy of the filter kernel is concentrated right at the start (minimum-phase instead of zero-phase). FIR filtering does not suffer from phase distortion.

The low latency makes this EQ suitable for live performance. I use it for microphone correction with -12 to +12 dB range, but it can be used with more extreme amplitude effect as well, to kill frequency bands like it is done in DJ mixers. The help patch has examples of both applications.

Average CPU load of this EQ is modest, ~1% on a regular laptop. However, computing a minimum-phase kernel (done for every filter parameter update) is CPU intensive and causes a short spike in CPU load. Therefore the technique may not be suitable for small platforms like Raspberry Pi. On my 1 GHz core2duo laptop tablet it performs well.

The abstraction uses Pd-extended objects [bsaylor/partconv~], [cyclone/speedlim] and [iemlib/for++].

If you want to read yourself a headache on minimum-phase filtering, here's the background documentation:

http://www.katjaas.nl/minimumphase/minimumphase.html

Katja

http://www.pdpatchrepo.info/hurleur/partconvEQ10~.zip

Hello,

I'm planning to do a graphic equalizer as fast convolution FIR filter in Pd. Let's say the equalizer has 10 sliders, one per octave. The question is how to translate the octave amplitudes to a smooth frequency curve. I was thinking about something along these lines:

1. upsample an array containing the amplitudes via FFT and larger zeropadded IFFT to get a smooth curve of 1024 points

2. warp the linear curve to logarithmic using [tabwrite4~] interpolation, to get 1024 spectrum points

Not sure if step 1 will work. Before reinventing the wheel, I'd like to know if someone has already built a graphic EQ FIR filter in Pd.

Katja

Hello,

Today [ipoke~], a variable speed writer class with linear interpolation, is released as beta version. This class enables you to model some intriguing processes, like variable speed sound-on-sound looping and doppler effects.

[ipoke~] was originally written for MaxMsp by Pierre Alexandre Tremblay. The Pd port results from a happy collaboration between P.A. Tremblay, his colleagues at Huddersfield University, and Pd people. Collaboration still goes on - a version with higher order interpolation is in the pipeline, but that is for the next version. Find [ipoke~] v.3test1 with source code, binaries and test patches here:

http://puredata.info/Members/ipoke

We're in test phase so if you find bugs or flaws, please let us know. And if you design cool patches with [ipoke~], please upload!

Katja

Not specially exciting, but just in case you'd need to find that bit for some reason, here's an abstraction (message rate).

Katja

http://www.pdpatchrepo.info/hurleur/msb-index.zip

Hello,

I am working on a Freeverb using vanilla objects. In contrast with [freeverb~] it should match with samplerates other than 44.1 KHz.

Freeverb is explained here by Julius O. Smith:

http://www.dsprelated.com/dspbooks/pasp/Freeverb.html

Apart from small details [vfreeverb~] is operational. It needs (performance-)testing. I'd be eager to know if it works on tablet platforms.

Katja

http://www.pdpatchrepo.info/hurleur/vfreeverb~.pd

Effective GUI elements are crucial for making a responsive music tool. Pd has only a few basic GUI objects, but in the course of time I've found methods to produce more advanced GUI's. For example, a numbox which scrolls in both directions (horizontally and vertically). Or [selector], a fancy radiobutton. An xy-pad with multiple controls, and a beat indicator with built-in BPM tap key. Graphically, it is all made up from the native IEM guis in Pd, but [cyclone/MouseState] is mostly used for their operation.

See attached gui-extended.zip for a small collection. With some patience, you don't need MaxMsp for it's slick GUI's at all!

Katja

Edit: an updated version (with a bug-fix) is in post #6

http://www.pdpatchrepo.info/hurleur/gui-extended.zip

Hello,

Today I could query the user list without being logged in. I thought this used to be impossible, or at least it should be impossible, no?

Katja

'Life in Pure Data' is a sonic fiction story about a flute maker's fatal obsession with frequencies. It's all done with Pd-processed voice and manipulated acoustic instruments. No synths, no prerecorded samples. Here's a stream:

http://www.katjaas.nl/LifeInPureData/LifeInPureData.html

Katja

Hello,

This post is about a plan to develop a software library with realtime analysis routines, to be used in Pd and possibly other realtime dsp frameworks. The idea was loosely discussed with Jwif in another thread.

My concept of RAP (realtime analysis project) would be based on the following: an audio stream has features which can be found from the waveform itself, features which can be used to reorganize that waveform in a sensible and musically pleasing way. A realtime cut and paste concept, applied to an incoming audio stream, rather than a file from disk. I apply this concept already in Instant Decomposer and Slice//Jockey. Jwif does so in his RjDj apps.

Analysis procedures for realtime cut and paste must be very precise, robust, and low-latency. Existing signal analysis classes in Pd (bonk~, fiddle~, sigmund~) are of good quality, but they can not give very precise locations of where things happen in a signal.

For this reason, I had earlier developed classes slicerec~ and sliceplay~, which operate with sample-precise attack cuepoints to indexes in a signal buffer. With this construction, incoming audio is spliced so fast and precise that rhythms can be created on the fly without sloppiness in the timing. slicerec~'s attack detector is however not so sensitive for all signal types as bonk~.

The concept of realtime splicing could be expanded beyond the obvious cut-on-attack approach, if period tracking is taken into account. If period length is known, periods can be cut, copied and pasted as well. This is a finer grain of signal reorganization, but still based on information of the signal itself. Like complete notes, periods can be stretched or shrunk to change their spectral information. You could use this for pitch shifting, realtime stretching or formant manipulation. Together, transient- and pitch detection give sufficient information to do very weird things with a signal, without completely loosing the original character.

The main info's needed from a signal are: envelope, attack point, transient length, and in case of periodicity the period length.

The RAP library would be a set of analysis routines written in C, which can be used in different combinations to create RAP-based Pd classes. The C routines should be of high quality and efficiency. For pitch tracking, procedures in [helmholtz~] are probably the best option (http://www.katjaas.nl/helmholtz/helmholtz.html). For attack detection, procedures in [bonk~] can be a guideline.

RAP-based Pd classes could be, for example:

a class [attackpoint~], taking an audio stream and an index stream, and producing cuepoint messages

a better [slicerec~]

a PSOLA pitch shifter

The above ideas sketch a very rough impression of what RAP could be. To design it's structure and implementation will be a delicate and time-consuming process. Do not expect it to be ready within days or weeks. If we take time to work out a decent structure, it will be possible to use the library for all sorts of purposes, and extend it over time. Like Pd, it should be BSD licensed to avoid limitations in the way how we can use it.

Katja

I've refined procedures in pitch tracker [snac~] (based on Philip McLeod's Specially Normalized Autocorrelation function (SNAC)), and renamed the object in the honour of the great 19th century explorer in the world of sound and frequencies, Hermann Helmholtz. The guy who listened through resonators to isolate frequencies in a sound.

[helmholtz~] is by default deaf for noise, but hears periodic sound no matter how faint. As a result, analysis frames containing transients, note jumps, or other signal segments with low autocorrelation are ignored. It's better to have no pitch report than an erroneous pitch report. Pitch estimation is precise up to +/- 0.1 Hz.

While regular methods need at least two periods in the analysis frame for detection, [helmholtz~] can do with a minimum of 1.2 periods. As a result, a female voice can be pitch-tracked with a frame of 512 samples at SR 44100, that is ~11 milliseconds. For a male voice and most instruments, 1024 samples are sufficient, that is ~23 milliseconds.

Remember that a time domain method can not distinguish multiple pitches in a stream, so [helmholtz~] must be used with monophonic channels only.

The object uses 0.6% CPU time per instance on my 2GHz CPU, with default settings, no analysis overlap. Since it only needs fundamental frequencies, it can be used in downsampled time as well, for example with resampling factor 0.25. Then you can do four overlapping analyses for the price of one, making things smoother as you get analysis results at a faster rate. Don't forget to resize the analysis framesize accordingly, otherwise you get long latency times.

I've extensively tested [helmholtz~] with my voice and all sorts of sweeping and jumping test tones. It does not seem to make mistakes with these sources. That may be different for other instruments, I'm eager to hear comments.

Attached file helmholtz~.zip contains source code, makefile, 32 bit binaries for OSX, Windows and Linux, help file and test patches.

Thanks to elden, who posted so many useful links on pitch shifting and tracking on this forum. [helmholtz~] would not have existed without all the info's. Find Philip McLeod's thesis introducing the SNAC function here:

http://miracle.otago.ac.nz/postgrads/tartini/papers/Philip_McLeod_PhD.pdf

Katja

P.s. [snac~], the experimental predecessor of [helmholtz~], is now discontinued.

Edit: find the latest [helmholtz~] now on:

http://www.katjaas.nl/helmholtz/helmholtz.html

http://www.pdpatchrepo.info/hurleur/helmholtz~.zip

Pitch tracking stuff seems to be popular these days (referring to moog1's bass pitch tracker in this forum section).

I've implemented Philip McLeod's Specially Normalized AutoCorrelation (SNAC) method in [snac~]. Initially, I only wanted to evaluate the method. But it turned out to have some excellent characteristics which make it really useful in practice, therefore I decided to build binaries and share the stuff. See attached snac~.zip if you're logged in.

For one thing, it is incredibly accurate with no more than 0.1 Hz deviation from the real input pitch. Secondly, it generates 'fidelity' messages, indicating to which degree the input signal is periodic. So you can easily exclude results from noisy frames (transients or other non-periodic content). Fidelity messages do not depend on signal RMS level, they even distinguish periodic content at very low sound levels.

Theory of SNAC is described in Philip McLeod's thesis (though at the moment of this writing, the site seems to be inaccessible):

http://miracle.otago.ac.nz/tartini/papers/Philip_McLeod_PhD.pdf

Katja

Edit: [snac~] is discontinued and replaced by improved object [helmholtz~], go to:

http://puredata.hurleur.com/viewtopic.php?pid=29125#p29125

It took me a full day to track a nasty bug in STK class LentPitShift, but in the end it could be made to work as a Pd object [lent~].

Lent's method reportedly does not produce the Mickey Mouse effect. This topic was discussed in thread:

http://puredata.hurleur.com/sujet-6614-upsampling-audio-signals-using-automatable-sampling-frequency

LentPitShift (and [lent~]) is a proof of concept, it is programmed without optimization and does some 15% CPU load for a rather crappy output. But the concept is quite clear: indeed there is no Mickey Mouse effect, the formants are preserved while the pitch is altered.

I've never heard this effect before in an open source real time application. Is it so hard to program? Probably, if you want to do it right.

I've compiled it on OSX 10.5, and can do a Debian Squeeze (32bit) build too if anyone interested. See attached lent~.zip with lent~.pd_darwin, lent~-test.pd and all the sourcecodes and makefile.

Here is the LentPitShift project description by author Francois Germain:

http://www.music.mcgill.ca/~francois/MUMT_618/Report/Report.pdf

Katja

Edit: find a zip with OSX, Linux and Windows binaries in post #7.

http://www.pdpatchrepo.info/hurleur/lent~.zip

Hello,

This post is related to and inspired by elden's topic on pitch and formant shifting

http://puredata.hurleur.com/sujet-6614-upsampling-audio-signals-using-automatable-sampling-frequency

but I do not want to clutter that thread too much with my experiment results so therefore started this new thread on pitch tracking, a subtopic of time domain pitch shifting.

ACF (autocorrelation function) and SDF (squared difference function) are used a lot in time domain pitch tracking or fundamental period identification. In Pd, I was trying how autocorrelation looks like. I also constructed another function, of which I don't even know if it has a name. For the moment, I'll call it IPPASS: 'instantaneous power of phase aligned signal segment'. It can be considered a modification or extension of autocorrelation. It seems to me that IPPASS might be useful in pitch detection, as it can much better indicate periodicity in case of missing fundamental. However, I'm not yet sure how to make it work in practical implementation, if it is possible at all.

In attached patch IPPASS02.pd, ACF and IPPASS functions are plotted for a synthesized test signal with variable harmonic recipe. The concept of period detection with ACF is, to make harmonics line up so together they peak at the fundamental interval. In addition to that, IPPASS employs periodic amplitude modulations in the signal.

By no means these functions are rock solid true/false indicators. The 'art of peak picking' is another aspect of pitch tracking. Read Philip McLeod and Geoff Wyvill on ACF, SDF and the art of peak picking:

http://miracle.otago.ac.nz/tartini/papers/A_Smarter_Way_to_Find_Pitch.pdf

Katja

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

Hello,

Attached is a patch with a fixed-interval time domain octave harmonizer (octave down and up). The approach differs from regular time domain pitch shifting, and the result is also quite different. A delay is noticeable for the octave tones, but the harmonies are very smooth. No rough tones, as they are normally associated with time domain pitch shifters. It is therefore particularly suitable for long notes.

Katja

http://www.pdpatchrepo.info/hurleur/octave-harmonizer.pd

Attached is a patch with a stepping variable delay, to make pitch steps on the input sound. Think a poor man's guitar arpeggiator. Very simple vanilla patch, no clue why it took me so many years to figure out. Great fun with voice, flute, kalimba and other melodic instruments.

Katja

http://www.pdpatchrepo.info/hurleur/step-vibrato.pd

Hello,

In case you're looking for a decent audio interface that works with Pd under Linux, you might consider the Mackie Blackjack. To my surprise, it worked out of the box in Debian Squeeze (Linux kernel 2.6.32 and 2.6.33).

The Mackie Blackjack is 2 channel with combined line / hi-z instrument / phantom-powered mic inputs, balanced jack outs plus headphone out with separate volume control. All pots and switches on top, very convenient on-stage form factor.

I use this interface with an Audio Technica ATM 33 condenser mic. Signal-to-noise ratio is excellent indeed.

The only gripe I have is about the build. Not really 'like a tank', as claimed by Mackie. Yes, the steel box will endure all abuse, but the plastic-shaft pots supported by nothing else than the print should be treated like a baby rather. Well I love it enough to do so.

Katja

Is it a fata morgana or not: long FIR filters with low latency? The topic has been on my mind for years, but I was ignorant of techniques that were already invented decennia ago. Now I finally sorted out how it can be done in Pd.

The key points are: minimum-phase filter kernels and partitioned convolution. Pd-extended has Ben Saylor's [partconv~] object. A minimum-phase filter kernel can be computed by Hilbert Transform of the log-amplitude spectrum. All taken together, it is not quite trivial, but it works! I am happy, this will save me ~40 ms of latency in my real time performance patches.

See attached patch for a demo.

Katja

http://www.pdpatchrepo.info/hurleur/minimum-phase-FIR.pd