When you say "amplifying partials" do you mean analyzing the spectrum of a sound file (or a real time audio source) then manipulating partials selected from the spectral information? If so, objects related to fourier analysis like [rfft], [ifft] are the ones you're looking for. Have a look at the examples starts with "I01.Fourier.analysis.pd" under the title of audio examples in the help browser (also E01.spectrum.pd).

If what you want is just to isolate some certain frequencies then amplify them (what we are talking is actually equalizer), then connecting your audio source to a series of bandpass [bp~] filters can be helpful. Check the help file to see how [bp~] works.

Hope this helps.

sunji: I believe it's iemlib... That's what it says in the help file.

arif: I know your pain... In fact, that's how I did it the first time. However, it depends to a large extent on the music you play - if you relay only on the composite amplitude, you might find out that if you cover the whole spectrum (e.g. green is very quiet and red is very loud) you get various colors only in very dynamic pieces. Otherwise it is red all the time (or another color, if you shift the spectrum).

On the other hand, if you apply the spectrum to a section between the limits (i.e. green is moderately loud and red is very loud), the shifts might be much too drastic (i.e. "disco").

In other words, if you get the perfect setting for one piece of music, it is very likely that it will be messed up for another. Which gave me an excellent idea to use dynamic mins and maxes for each fragment (piece of music starting with longer silence? each play instance?), but it might be hard to pull off...

Hmm.. I think I need to be a little more clear on that subject. What I'm trying to do is pretty much composing a piece in real-time by using the pitch material derived from the spectrum of a sound (in this case the instrument which plays the piece). For my "normal" compositions I use the same method by analyzing the spectrum of the sound by using SPEAR (klingbeil.com), saving the outcome in SDIF format, and importing it to OpenMusic (ircam.fr) which shows each partial as a note, also gives their dynamic level, duration, phase information etc. For my project, I don't need the later ones but only the pitch.

Well hardoff, for the sake of performance easiness (considering the deadline I have -- Nov.26) I just changed it from piano to flute.

I am attaching the patch I've got so far which creates random succession of notes any time it's triggered. What I want to do is to replace the random with a patch that analyzes the sound, and gives frequency information for each partial that.

transcribe~ looks like it should do trick for the upcoming concert hardoff. Thanks for suggesting.. But for the future projects, I think I am gonna need something more accurate.

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

I need something that is capable of a lot more detailed analysis sunji. I used fiddle~ in many of my other projects, but it's not working sufficiently for the one I'm currently working on. I want to build a patch that converts spectral analysis of a musical excerpt played by an acoustic instrument (in this case it is a piano) sampled periodically, and convert it to notation in real time. I've sorted out the notation part by using GEM, but got stuck with the analysis part. If it was a monophonic instrument playing clear lines, fiddle~ would make it, but in the case of piano, with all those pedals, chords, sustained sounds, it simply doesn't work... I guess fft~ objects will do it somehow, but it's certainly beyond my Pd knowledge to program them to get what I need...

This is definitely the way to go, if you're intent on using Pd:

[readsf~ 4] [metro 10] // 10ms = 80samples at 8000Hz
| | | | |
[pd $0-analysis]
| | | | |
[writesf~ 5]

Note that Pd has a logical clock: if computation takes too long, you get skips in the real world, but everything in Pd-land stays 100% in sync. So you can trigger your analysis stuff with a metro, and it should work fine - the only problem I can think of is that the analysis channel will lag behind the audio channels, unless you use delay lines in Pd.

Dear Community,

I'm a student and I'm going to realize a project with Puredata. The idea is a "Virtual DJ" that analyses sound files from a directory. Depending to their velocity (bpm) and the average frequency of the sound signal I want to classify them into an array.
Second I want to analyse the environment in realtime. With the webcam and the microphone I want to find out the loudness and the average color value.
Everytime when a song ends, the new one should be selected considering the information about songs in the array.

I'm an newbie and don't know much about Puredata. Just some working with the standard objects.I have some programming experience with Java, PHP and a little bit of C.

I would be really appreciated if one of you could help me out with some good tutorials to start with. And with ideas how to realise these analysing issues:

• How to analyse sound files from one directory? BPM and average Freq. of sound signal.
• How to analyse in real time microphone and webcam?

thank you a lot,
Michael

hi

Matt Black of Coldcut here.

as a step towards achieving multitrack audio visualisers, ie video synths which are controlled by multiple simultaneous audio inputs, i am interested in getting the following bit of software built, and think it could be made in PD. Am posting it here to see if anyone is interested. I can offer a fee to get this built.

This is the initial spec. I call it a Multitrack Analysis Module , MAM.

-MAM works with multi input ASIO soundcards eg RME fireface, and supports up to 16 audio ins.

-MAM performs SEPARATE fft /spectrum analysis on EACH AUDIO INPUT , say 16 frequency bands per input . delivers amplitude for each frequency band.

-outputs results of fft analysis as midi data. use cc numbers 1-16, with value 1-127 for the 16 frequency bands amplitudes. use midi channel 1-16 to distinguish the 16 audio inputs. Midi data can be routed to available midi interfaces/ports on the host machine, including virtual midi ports such as Maple, MidiYoke.

-optionally, output could be via OSC/ethernet which would get round possible MIDI data rate problems. (Do people think MIDI could handle this amount of data? it could be thinned)

-the MAM should be a self contained module , a stand alone patch that doesnt require a PD framework to run. As i dont know anything about PD , i dont know how it works, but you probably know what i mean.

-ideally, MAM would also be able to run with Ableton LIVE so that one can route the analysis data off to another machine to do the visuals, and still manipulate the audio on the machine with the audio ins in LIVE. this is not essential but i would like to know if people think it would be possible.

Hope this makes sense. I am looking for a good PD coder who is interested in working on a cutting edge project. A payment to build this initial module can be negotiated...not a huge one, but something. Interested parties can post here initially.

Thanks.
Matt Black

@daisy said:

I have read some where that "if a voice is at same pitch and same loudness and still if one recognize that two voices are different , it is becuase of TIMBRE (tone quality)". (I agree there are other features as well who need to consider).

Timbre is another word for spectrum. The spectrum of a sound is the combination of basic sine waves that are mixed together to make it. Every sound (except a sine wave) is a mixture of sine waves. You can make any sound by adding the right sine waves together. This is called synthesis.

@daisy said:

First Question:
So how we can calculate the TIMBRE of voice? as fiddle~ object is used to determine the pitch of voice? what object is used for TIMBRE calculation?.

[fft~] object splits up the spectrum of a sound. Think of it like a prism acting on a ray of light. Sound which is a mixture of sines, like white light, goes in. A rainbow of different colours comes out. Now you can see how much red, blue, yellow or green light was in the input. That's called analysis.

So the calculation that gives the spectrum doesn't return a single number. Timbre is a vector, or list of numbers which give the frequencies and amplitudes of the sine waves in the mixture. We sometimes call these "partials".

If you use sine wave oscillators to make a bunch of new sine waves and add them together according to this recipe you get the original sound back! That's called resynthesis.

@daisy said:

Second Question:
And how one can change TIMBRE? as pitch shifting technique is used for pitch? what about timbre change?

Thanks.

Many things change timbre. The simplest is a filter. A high pass filter removes all the low bits of the spectrum, a bandpass only lets through some of the sine waves in the middle, and so on...

Another way to change timbre is to do analysis with [fft~] and then shift some of the partials or remove some, and then resynthesise the sound.

@daisy said:

I have a kind of general idea (vcoder). but how to implement it? and how to change formant?.

A vocoder is a bank of filters and an analysis unit. Each partial that appears in the analysis affects the amplitude of a filter. The filter itself operates on another sound (often in real time). We can take the timbre of one sound by analysing it and get it to shape another sound that is fed through the filters. The second sound takes on some of the character of the first sound. This is called cross-synthesis.

/doc/4.fft.examples/05.sheepgoat.pd
Help -> 7.Stuff -> Sound file tools -> 6.Vocoder

"Frozen reverb" is a misnomer. It belongs in the Chindogu section along with real-time timestretching, inflatable dartboards, waterproof sponges and ashtrays for motorbikes. Why? Because reverb is by definition a time variant process, or a convolution of two signals one of which is the impulse response and one is the signal. Both change in time. What you kind of want is a spectral snapshot.

1. Claudes suggestion above, a large recirculating delay network running at 99.99999999% feedback.
   Advantages: Sounds really good, its a real reverb with a complex evolution that's just very long.
   Problems: It can go unstable and melt down the warp core. Claudes trick of zeroing teh feedback is foolproof, but it does require you to have an apropriate control level signal. Not good if you're feeding it from an audio only source.
   Note: the final spectrum is the sum of all spectra the sound passes through, which might be a bit too heavy. The more sound you add to it, with a longer more changing sound, the closer it eventually gets to noise.

2. A circular scanning window of the kind used in a timestretch algorithm
   Advantages: It's indefinitely stable, and you can slowly wobble the window to get a "frozen but still moving" sound
   Problems: Sounds crap because some periodicity from the windowing is always there.
   Note: The Eventide has this in its infiniverb patch. The final spectrum is controllable, it's just some point in the input sound "frozen" by stopping the window from scanning forwards (usually when the input decays below a threshold). Take the B.14 Rockafella sampler and write your input to the table. Use an [env~]-[delta] pair to find when the
   input starts to decay and then set the "precession percent" value to zero, the sound will freeze at that point.

3. Resynthesised spectral snapshot
   Advantages: Best technical solution, it sounds good and is indefinitely stable.
   Problems: It's a monster that will eat your CPUs liver with some fava beans and a nice Chianti.
   Note: 11.PianoReverb patch is included in the FFT examples. The description is something like "It punches in new partials when theres a peak that masks what's already there". You can only do this in the frequency domain. The final spectrum will be the maxima of the unique components in the last input sound that weren't in the previous sound. Just take the 11.PianoReverb patch in the FFT examples and turn the reverb time up to lots.

[fiddle~] gives you the main pitch of the sound incoming.

I do a project with sound analysis and sound production related to this analysis. For that moment, I've been inspired by a book " interactive musical systems" by Robert rowe.

I split the patch in two parts : LISTENER (analysis) ans PLAYERS (sound production).
Now I've focus 8 differents styles of incoming sound, very primitive with 3 couple of parameters :
CHAOS / REGULARITY
LONG / SHORT
STRONG / LOW

It has to be appreciate for different situations. But I think it's a good way to start. Now, I'm a little disturb by the actions of the PLAYERS. I'm split between two position : use a lot of different sounds (like audio files from crowd, weather, voices, drums and synthesis and live recording and playing )and focus just a limited range of sounds and use them to the death.

if you like to see the project, it's in french sorry :
http://impala.utopia.free.fr/projets/index.php?mode=plus&id=1