mapWindow

v1.0 [pdf]
v1.1 [pdf]
In this document one can find everything about the mapping stage with windows, used for our iDAFx. Four possible windows are presented (but adding some others is a piece of cake). For each window a big one and a small one are possible. The big one is 1024-points large and the small one only 128, which agrees with the range of the MIDI message parameters. The effect is the same, but the latter is obviously less accurate.

windows.m is the m-file that is used to make these windows. Every table is then saved in a textfile and this one is used inside Pure Data.
[hammBig.txt] [hammSmall] [blackmanBig.txt] [blackmanSmall.txt] [gaussBig.txt] [gaussSmall.txt] [hannBig.txt] [hannSmall.txt] [windows.m]
We supply two blocks for applying a window to a control signal: windowBig and windowSmall. The documentation is given hereunder:

---

windowBig/windowSmall

This block applies a 1024-points/128-points window to a control signal. One can choose between different windows. One has to define an argument to use multiple instances of this block in the same patch without influencing each other.

version

v1.0: built 29/04/2007 with Pd v0.40-2 [pd]/[pd]
v1.1: built 30/04/2007 with Pd v0.40-2 [pd]/[pd]

interface

Input 1: a control signal ranging between 0 and 1024/128

Output 1: a control signal ranging between 0 and 1

Controls: a knob per window type

implementation

The values for each window are read from a .txt file (that have to be found in the same folder as the patch). Upon clicking a button, a bang is sent to the appropriate read message, and the right curve is loaded in the graph. The tabread block is then used to map the inlet to the outlet.
In v1.0 one could not use multiple instances of this block in one patch, because there was an unsolved problem with arguments. That is now solved with the help of Frank Barknecht. In two help-patches he explains all our oddities with dollarsigns. [dollars-help.pd] [dollars.pd] And his most beautiful solution was adopted, the one with the sends, which at the same time doesn't have the problem of difference between arguments in objects and arguments anyway.

weekly update

What's been keeping us busy:

• We're working on the beat detection block for pure data. There keep existing some problems in matlab but they might soon be solved after thoroughly skinning and optimizing the code.
• As for me I implemented some extra blocks, mostly quite basic: the EARdetector (envelope, attack and rest), ring modulator (that also functions as tremolo), chorus and something more special. The documentation will follow.
• Also we started writing our thesis by making a contents summary. This will happen in LaTeX, something new for us...
• Also I've been and I still am trying to understand C for Pure Data externals.
  

mixer

This is collection of a few patches we made to use in main patches for using our effects. It is more than a simple mixer, but it certainly hasn't got all the functionalities of a professional mixer. It has got all that might be useful for our effects project: gain control, mute control, external input or wave files, many channels that are all summed on a bus to the master,... A functionality like sends and returns is not implemented. The structure that is used (apart input and channel patches) implicitly has this function, because one can attach multiple signals to them.
This document documents on the patches.
v1.0 [pdf]
v1.1 [pdf]
new block added; channel bug temporarily fixed

---

inputmulti~

This block implements a multichannel input. One can choose ten different wave files or five stereo files. When using wave files one can loop them. One can internally adjust the input gain of the signal to the best non-clipping level. The gain, clip and instantaneous RMS level is displayed on the block. It's best to not use more than one instance of this block in the same patch.

version

v1.0: built 15/05/2007 with Pd v0.40-2 [pd]

interface

To choose other sound files, one must open the input patch, specify the soundfile in the right folder in a message and click on that message.

Output 1, 2, 3, 4, 5, 6, 7, 8, 9, 10: a levelled mono audio signal

Internal controls:
start: start the chosen wave file. ctlin message 48.
play: when the wave file is done it is immediately replayed. ctlin message 49.
TO DO: we might better call this a loop button or something.

implementation

The wave playback section: each tabplay~ block starts playing when it receives a bang. It then plays the wave file that is loaded in the array with its name, found in the graph at the bottom left. One can choose another one by specifying a new soundfile in a message block. When the tabplay~ block is finished playing a track, it bangs the right output. This bang is used to let the message 1 allow the multiplication (when it's zero or without banging the hot input of the multiplication, the bang that follows will not be reached). The play toggle has a value of 127 to be consistent with the MIDI message value. A select block selects this value and bangs the tabplay~ block to replay the track.
A simple section is provided to adjust single gain factors per channel. Just specify another factor in the right message and click on it.

This implementation leaves away many features of the other input. But we found a bug there: if one wants to play different tracks he cannot. Due to the dollar problem with arrays it would change the array of each input~ block.

---

input~

This block implements a dual input. One can choose to use wave files or to go live with an external input (adc~). Both are calculated real-time. When using wave files one can loop them. When using the adc~ one can choose which channel of the audio card is routed to left and right channel. One can adjust the input gain of the signal to the best non-clipping level. The gain, clip and instantaneous RMS level is displayed on the block. When using more than one input~ block in a patch be sure to include an argument after the block name.

version

v1.0: built 20/04/2007 with Pd v0.40-2 [pd]

interface

To choose other sound files, one must open the input patch and click on a specific message that contains the file

Output 1: The mono audio signal or the left channel audio signal
Output 2: The right channel audio signal

Controls:
source for left, right: One can choose a channel from 1 to 8 from the soundcard that is available. When another routing is chosen, you must first enter 0 too. Otherwise you will be adding different channels from your soundcard to the same outputchannel of this block. If you are playing wavefiles it's best to put these sources to 0.
start: start the chosen wave file. ctlin message 48.
play: when the wave file is done it is immediately replayed. ctlin message 49.
TO DO: we might better call this a loop button or something.
reset: reset the gain to 0
gain slider: adjust the gain. the number box next to it only shows the chosen gain value, it does not change it!
clip: When the RMs of the signal exceeds 100dB (the zero attenuation level) this knob lights up in red.
VU-meter: shows the level of the signal at any time. You can also use it to see if it's a stereo signal or not.
TO DO: implement peak meter

implementation

The gain system: when reset is pressed, a message is banged that will send a 0 to the gain slider. The gain slider is he first control in the gain system, the rest is linked from there. The number box thus only shows results and does not adapt them. The slider ranges from -100 to +20 dB. It is then shifted and recalculated to RMS values before being used as an attenuation factor at the output, equal for both channels. The clip bang lights up in red when the moses block detects a RMS value higher than 0dB on the left channel.
TO DO: also check the right channel for clipping.
The wave playback section: the tabplay~ block starts playing when it receives a bang. It then plays the wave file that is loaded in the arrays named leftInput and rightInput, both contained in the graphs at the top right. One can choose another one by clicking on the specific message bottom left. When the tabplay~ block is finished playing a track, it bangs the right output. This bang is used to let the message 1 allow the multiplication (when it's zero or without banging the hot input of the multiplication, the bang that follows will not be reached). The play toggle has a value of 127 to be consistent with the MIDI message value. A select block selects this value and bangs the tabplay~ block to replay the track.
The VU meter section: The VU meters have to receive control messages in dB values ranging from -100 to +112. The output signals are therefore sampled with the snapshot~ block and recalculated from RMS to dB. In the future we might replace this wit env~ blocks or EARdetection~ blocks.
The adc source selection: The signal that is input in a specific input of your soundcard is multiplied by a 0 or a 1 depending on which number you input in the number box in the display. If you select two times another valid number for the same audio channel, they will be both output. So be careful to also select another number (0) to mute all the inputs.

---

channelM2M~

This is one of the channel blocks. It's the bottom part of channels on a real mixer. It allows to make all kinds of routing in your patch. It's output is routed to a master~ block to make it audible. When multiple blocks of this kind are used, one must specify a unique argument. This is almost always the case. No outlet is visible, because the signal is put on the right (depending on the signal: left or right channel bus of...) master bus internally. Be sure to include a master~ block in your patch!
In this block one can mute this channel, reverse the signal and adjust the level. A VU-meter is also visible to follow what happens. This specific block is one that has no counterpart in a real mixer, because you cannot put it in a stereo image. But it is useful though as an inline amplification block.

version

v1.0: built 20/04/2007 with Pd v0.40-2 [pd]

interface

Input 1: The mono audio signal
Input 2: A control input for the dB level. It ranges from 0 to 127, the former meaning silence, the latter the loudest.

Controls:
solo: doesn't work yet
mute: when enabled, the signal is not throughput to the masterbus. When released again, the last value is taken again.
reverse: when enabled, the phase of the signal is reversed. This is not audible per se, only in comparison with other tracks or itself.
dB-slider: see Input 2.
VU-meter: shows the level of the signal at any time.
TO DO: implement peak meter

implementation

The dB-level is divided by 1.27 to make the input of the dbtorms range from 0 to 100. This is smoothed (line~) and multiplied with the high passed signal at the input of the block. This signal is not connected to the hot inlet as normal, but this works because the level control signal is turned into an audio signal in the line~ block.
The reverse logic is the same as in the rev~ block [v1.0 pd] [v1.0 pdf]. In the future it might be substituted here.
The logic for driving the input of the VU-meter is a dB calculation and a shift to the right scale. But this might be replaced by an env~ block in the future.
The mute logic: If mute is banged the message 0 is put as master-lvl while the previous value is stored in the bottom f(loat) object. Another bang releases this value again on the master-lvl.

---

channelM2S~

This is one of the channel blocks. It's the bottom part of channels on a real mixer. It allows to make all kinds of routing in your patch. It's output is routed to a master~ block to make it audible. When multiple blocks of this kind are used, one must specify a unique argument. This is almost always the case. No outlet is visible, because the signal is put on the left and right master bus internally. Be sure to include a master~ block in your patch!
In this block one can mute this channel, reverse each channel signal and adjust the level. A VU-meter is also visible to follow what happens. One can also change and reset the place of the signal in the stereospectrum with the PAN parameter.

version

v1.0: built 20/04/2007 with Pd v0.40-2 [pd]

interface

Input 1: The mono audio signal
Input 2: A control input for the dB level. It ranges from 0 to 127, the former meaning silence, the latter the loudest.
Input 3: A control input for the PAN position. -128 means left and 128 means right.

Controls:
pan: when clicking on the bang the PAN position is reset to zero. The number box can be used to change the position and the result of either a change with the number box, either a change at the corresponding inlet will be visible with the slider. Internally (in the block) one can choose between 4 panning laws, also look at the documentation of the monopanner~). The default law is a sine curve.
solo: doesn't work yet
mute: when enabled, the signal is not throughput to the masterbus. When released again, the last value is taken again.
reverseL, reverseR: when enabled, the phase of the signal is reversed. This is not audible per se, only in comparison with other tracks or itself.
dB-slider: see Input 2.
VU-meter: shows the level of the signal at any time.
TO DO: implement peak meter

implementation

The dB-level is divided by 1.27 to make the input of the dbtorms range from 0 to 100. This is smoothed (line~) and multiplied with the high passed signal at the input of the block. This signal is not connected to the hot inlet as normal, but this works because the level control signal is turned into an audio signal in the line~ block.
The reverse logic is the same as in the rev~ block [v1.0 pd] [v1.0 pdf]. In the future it might be substituted here.
The logic for driving the input of the VU-meter is a dB calculation and a shift to the right scale. But this might be replaced by an env~ block in the future.
The mute logic: If mute is banged the message 0 is put as master-lvl while the previous value is stored in the bottom f(loat) object. Another bang releases this value again on the master-lvl.
The panorama logic is the same as in the monopanner~ block. view that documentation.

---

channelS2S~

This is one of the channel blocks. It's the bottom part of channels on a real mixer. It allows to make all kinds of routing in your patch. It's output is routed to a master~ block to make it audible. When multiple blocks of this kind are used, one must specify a unique argument. This is almost always the case. No outlet is visible, because the signal is put on the left and right master bus internally. Be sure to include a master~ block in your patch!
In this block one can mute this channel, reverse each channel signal and adjust the level. A VU-meter is also visible to follow what happens. One can also change and reset the place of the signal in the stereospectrum with the PAN parameter.

version

v1.0: built 20/04/2007 with Pd v0.40-2 [pd]

interface

Input 1, 2: The two channels of the stereo audio signal
Input 3: A control input for the dB level. It ranges from 0 to 127, the former meaning silence, the latter the loudest.
Input 4: A control input for the PAN position. -128 means left and 128 means right.

Controls:
pan: when clicking on the bang the PAN position is reset to zero. The number box can be used to change the position and the result of either a change with the number box, either a change at the corresponding inlet will be visible with the slider. Internally (in the block) one can choose between 4 panning laws, also look at the documentation of the monopanner~). The default law is a sine curve.
solo: doesn't work yet
mute: when enabled, the signal is not throughput to the masterbus. When released again, the last value is taken again.
reverseL, reverseR: when enabled, the phase of the signal is reversed. This is not audible per se, only in comparison with other tracks or itself.
dB-slider: see Input 3.
VU-meter: shows the level of the signal at any time.
TO DO: implement peak meter

implementation

The dB-level is divided by 1.27 to make the input of the dbtorms range from 0 to 100. This is smoothed (line~) and multiplied with the high passed signal at the input of the block. This signal is not connected to the hot inlet as normal, but this works because the level control signal is turned into an audio signal in the line~ block.
The reverse logic is the same as in the rev~ block [v1.0 pd] [v1.0 pdf]. In the future it might be substituted here.
The logic for driving the input of the VU-meter is a dB calculation and a shift to the right scale. But this might be replaced by an env~ block in the future.
The mute logic: If mute is banged the message 0 is put as master-lvl while the previous value is stored in the bottom f(loat) object. Another bang releases this value again on the master-lvl.
The panorama logic is the same as in the monopanner~ block. view that documentation. One might call it balance instead of pan, but the implementation is the same, because the two channels of the stereo spectrum are mixed before entering the pan logic.

---

master~

Each analog mixer has an audio chain that ends with a master section. It represents the last step and is connected with the master outs. This block is also the last block in our chain. It puts the two master busses on the speaker outputs. There can be only one master~ block per patch.

version

v1.0: built 20/04/2007 with Pd v0.40-2 [pd]
TO DO: also implement a recording facility for recording examples of our results.

interface

Controls:
mute: when enabled, the signal is not throughput to the speakers. Also the DSP is stopped. One can use it as a panic! knob. When released again, the last value is taken again. When the MIDI value 40 is received mute is toggled.
dB-slider: controls the volume level of each channel. They are both controllable with the MIDI values 30 and 7 (two last sliders on a Korg MICROkorg)
VU-meter: shows the level of the signal at any time.
TO DO: implement peak meter

implementation

For the level and meter logic the same implementation is used as in the examples above.
The DSP is stopped when the mute knob has value 1, with the command pd dsp 0. When it's not 1 (but lower, thus being 0) the command pd dsp 1 puts the DSP (and the sound) back on.

pan~

This block is a simple panorama block. It has an input to control the position and works according to the equal power idea, using a sine function.

version

v1.0: built 15/04/2007 with Pd v0.40-2 [pd][pdf]
TO DO: the sine function is implemented with a table. When pan~ is used several times in one patch, they'll all have to work with the same control function (sine in this case). I didn't yet find how to comprise the $ argument in the patch so that every pan~ block works with its own table.
v1.1: built 9/05/2007 with Pd v0.40-2 [pd][pdf]

interface

Input1 : the mono audio signal input
Input2 : the control input; ranging from -127 (LEFT) to 127 (RIGHT) where 0 marks the CENTER position

Output1: the left channel audio signal
Output2: the right channel audio signal

Controls: internally one can choose between 4 panning laws: sine, root, gogin and linear. (see the documentation of the monopanner~)

implementation

The inlet receives a control signal as specified in the interface section. This signal is shifted. It's range is then from 0 to 256, which is the same range as the table used. For every value an attenuation factor is looked up in the table. This is then multiplied with the signal itself.
The initialization is done by setting the control value to zero and initializing the table.
Dollar arguments are implemented to make sure multiple use of pan~ in the same patch allows for unique behaviour.

rev~

This block implements signal reverse: a stereo signal enters the block and one can choose to reverse each channel or both by sending a 1 for reverse and a zero for normal.

version

v1.0: built 14/04/2007 with Pd v0.40-2 [pd][pdf]

interface

Input1 : the left channel audio signal input
Input2 : the left channel control input; 0 is normal, 1 is reverse signal
Input3 : the right channel control input; 0 is normal, 1 is reverse signal
Input4 : the right channel audio signal input

Output1: the left channel audio signal, normal or reversed
Output2: the right channel audio signal, normal or reversed

implementation

To reverse a signal a multiplication with -1 is done. A moses block bangs the right message for the multiplication by routing the control input. This message changes the factor of the multiplication.

EARdetector~

EARdetector~

An envelope, attack and rest detector. This blocks tells us the instantaneous RMS and peak values of a signal, both in dB and amplitude scale. It also gives a bang when an attack is detected or a rest of more than a specified time constant is registered. The attack and rest detection is based on the envelope of the signal.

version

v1.0: built 20/04/2007 with Pd v0.40-2 [pd][pdf]

interface

Input 1: the signal you want to follow. The attack and rest detectors will only work nicely when this signal is amplified to the loudest level without clipping. This is like adjusting the gain on a mixer.

Output 1: in this output three results are packed: a smoothed RMS signal, the instantaneous RMS signal (both in dB) and the smoothed amplitude signal (between 0 and 1)
Output 2: in this output two results are packed: a smoothed peak signal in dB and the amplitude signal of it.
Output 3: receives a bang if an attack is detected. This happens when a threshold of 55dB is reached and the signal was lower than 45dB before it.
Output 4: receives a bang if a rest is detected. This happens whenever a threshold of 45dB is not reached for longer then 100ms

When loaded the rest outlet gives a bang after the specified delay.

implementation

The basic block used here is the env~ block. It's output is in dB. To calculate the RMS amplitude value a dbtorms block has to be inserted.
TO DO: test if different arguments give better results (the argument stands for the interval in msec used to calculate the RMS on)
This signal is smoothed by running it through three lowpass filters with a cutoff frequency of 1Hz. Because the filters work on audio signals, a snapshot~ block had to be attached.
In the help patch about the env~ block that is found in a standard version of Pd, one sees that the peak value is 3.01dB higher than the RMS value.
The different results are packed to two outlets, the first outputs all RMS values, the second all peak values.
The attack detection works as a state machine with two states. When the state is 0 and the signal reaches 55dB or higher, the state becomes 1. When the state is 1 and the signal gets lower than 45dB, the state becomes 0. It might be necessary to adapt these thresholds later.
Also the rest detector works a two-state state machine. If a signal is more than 100msec under the threshold of 45dB the state changes to 1. It might be necessary to adapt these thresholds later.

beat detection

development sheet

In this document blocks and thoughts will be collected that have anything to do with the development of a beat detector in Pure Data. This document (or post) will be updated as long as the first definitive version is not ready.
The basic implementation structure is as follows:
In a main file beat~ everything will be done.
Some smaller topics:

• First a few links to previous posts about the topic:
  
  • explanation of the idea
  • about bonk~
• An add block is made to be able to add more than two arguments at the same time. It receives a list from a pack command with up to 20 elements. When this pack block is banged at the first input, the addition is calculated, and only then. So be sure to put some kind of bang logic there! At the outlet appears the sum as a result of pairwise additions. This block tested and works when the bang is applied.
  
  --->implementation--->
• 
  

Oops: we are a bit banged by the complexity of using Pd to translate this algorithm. We're now skinning the matlab code we have (see link to beat it!) and learning how to make our own externals in C.

sin~

This block calculates the sine for a audio signal (sample by sample). Only cos~ is included in PureData.
The input is the audio signal. The output its' sine. You can verify its working well with testcos_sin.pd

version

v1.0: built 12/04/2007 with Pd v0.40-2 [pd][pdf]
related testfile: testcos_sin.pd
v1.1: built 13/04/2007 with Pd v0.40-2 [pd][pdf]

interface

Input1 : the (mono) audio signal input

Output1: the sine for the audio signal

implementation

The implementation is based on the relationship between the cosine and the sine function. You have to be careful here because in PureData the arguments are normalised. This means 1 corresponds to 360 degrees or 2*Pi. The cosine of 0.25 gives 0, 0.5 gives -1, 0.75 gives 0 again. This means the sine of 0.25 has to be 1, 0.5 has to be 0, 0.75 has to be -1. So there is a translation of 0.25 between the 2 functions. This comes from sin(x) = cos (pi/2-x)

rev_mono~

This reverb block contains only 1 input (the mono signal).

The creation arguments (liveness, crossover frequency, HF damping) are supplied in three inlets as shown.

• The "liveness" (actually the internal feedback percentage) should be 100 for infinite reverb, 90 for longish, and 80 for short and so on...
  
• The crossover frequency and HF damping work together: at frequencies above crossover, the feedback is diminished by the "damping" as a percentage. So zero HF damping means equal reverb time at all frequencies, and 100% damping means almost nothing above the crossover frequency gets through. This is implemented to simulate a vintage analog reverb sound, because the analog circuitry used had also as an effect that the high frequencies were attenuated.
  

version

v1.0: built 11/04/2007 with Pd v0.40-2 [pd][pdf]
Final version; defaults are included, output level has to be controlled from outside (not like in rev3~.pd)

interface

Input1: mono input channel.

Outputs1-4: 4 different combinations of the internal delay taps. Possibly combine them into left and right output

Controls:
INLET1: set a value for the internal feedback percentage, called liveness, usually between 85 and 100. It ranges form 0 to 100.
INLET2: set a value here that indicates the crossover frequency.Once reached, damping occurs. It ranges from 0 to 20kHz. Default is 3000Hz.
INLET3: set a value for percentage of feedback damping after reaching the crossover frequency. It ranges from 0 to 100.

implementation

The input directly goes to the pd doit block, actually the reverberation calculation block. In this case there is only one mono channel input. We make a combination of the same input into this block.

The control signals are, if needed, translated to different range/values and are given a name. This is the case for INLET1 (gets name fb): the liveness input goes from 0 to 100 (default 85), but in reality has a maximum value of 25%. For INLET2 (gets name lop): the crossover frequency default is set to 3000 Hz. For INLET3 (gets name damp): HF damping is set to a percentage value (default is 50) and a linear transition is set to 50 ms in order to obtain a smooth change of value.

In the figure below you can see the actual filter bank for calculating the reverberation effect. You can see there are 16 different delay lines that are combined into this diagram and all transformed with respect to the give parameters. Lop~ is used to subtract the low frequency part of the signal from the original in order to obtain the high frequency part. After this operation damping with factor damp occurs. The level of each delay tab is influenced by fb. The actual combinatorial diagram is just one implementation method. Different methods are possible. This is the best found.

rev_stereo~

Left/right input respectively for left/right stereo input.
The creation arguments (liveness, crossover frequency, HF damping) are suplied in three inlets as shown.

• The "liveness" (actually the internal feedback percentage) should be 100 for infinite reverb, 90 for longish, and 80 for short and so on...
  
• The crossover frequency and HF damping work together: at frequencies above crossover, the feedback is diminished by the "damping" as a percentage.So zero HF damping means equal reverb time at all frequencies, and 100% damping means almost nothing above the crossover frequency gets through.This is implemented to simulate a vintage analog reverb sound, because the analog circuitry used had also as an effect that the high frequencies were attenuated.

version

v1.0: built 11/04/2007 with Pd v0.40-2 [pd][pdf]
Final version; defaults are included included, output level has to be controlled from outside (not like in rev3~.pd)

interface

Input1 & 2: the left and right channel from stereo signal

Outputs1-4: 4 different combintions of the internal delay taps. Possibly combine them into left and right output

Controls:
INLET1: set a value for the internal feedback percentage, called liveness, usually between 85 and 100. It ranges form 0 to 100.
INLET2: set a value here that indicates the crossover frequency.Once reached, damping occures. It ranges from 0 to 20kHz. Default is 3000Hz.
INLET3: set a value for percentage of feedback damping after reaching the crossover frequency. It ranges from 0 to 100.

implementation

The input directly goes to the pd doit block, actually the reverbation calculation block. In this case there are 2 different inputs (left and right channel). It is possible to make a combination of the same input into this block.

The control signals are, if needed, translated to different range/values and are given a name. This is the case for INLET1 (gets name fb): the liveness input goes from 0 to 100 (default 85), but in reality has a maximum value of 25%. For INLET2 (gets name lop): the crossover frequency default is set to 3000 Hz. For INLET3 (gets name damp): HF damping is set to a percentage value (default is 50) and a linear transition is set to 50 ms in orde to obtain a smooth change of value.

In the figure below you can see the actual filterbank for calculating the reverbation effect. You can see there are 16 different delay lines that are combined into this diagram and all transformed with respect to the give parameters. Lop~ is used to substract the low frequency part of the signal from the origininal in order to obtain the high frequency part. After this operation damping with factor damp occures. The level of each delay tab is influenced by fb. The actual combinatorial diagram is just one implementation method. Different methods are possible. This is the best found.

waves

A block that implements some waves with a specific frequency and normalized output. It provides a (co)sine wave, (reverse) sawtooth, triangle and rectangular wave. Two blocks can be added or combined and rescaled in any other way to make new waves. One waves block connected to another one gives quadratic waves.

version

sin~ [pd]
v1.0: built with Pd v0.40-2 [pd] [pdf]
v1.1: adapted with Pd v0.40-2 [pd] [pdf]
sine wave added, RESET knob added
v2.0: built with Pd v0.40-2 [pd] [pdf]
new control logic
reverse sawtooth added

interface

Input 1: A value for the frequency of the wave. It is expressed in Hertz and thus must be positive.
Input 2: Reset knob. When it is pressed, the wave is restarted from the beginning. For a sine wave, square and sawtooth this is 0, for a cosine, reverse sawtooth and triangle it is 1
Input 3: MIDI control change number. This is used to select the wave: when MIDI control change message 52 sends a value of 127 (aka is pressed in), the different waveforms are cycled.

Output 1: A waveform with a specified frequency, specified form and an amplitude that ranges between 0 and 1.

implementation

fig: respectively prints of a reverse sawtooth, sine or cosine, sawtooth, triangle and quadratic wave

The frequency value one inputs is turned into a signal type with sig~. You get a signal with constant amplitude equal to the value specified. Then a phasor~ object runs through every value starting from 0 to 1 and again at a frequency specified. This already is a ready-made sawtooth signal.
The sine block is based on the relationship between sine and cosine function. Read more in documentation of sin~
The sawtooth wave is also used as table lookup signal for the other waves. The cos~ block calculates for each sample the cosine value. This sine is raised above 0 and normalized by dividing with two, or less expensive: multiplying with a half.
The triangle is calculated by shifting the sawtooth so it lies around zero, then taking the absolute value so that the negative part is mirrored to the positive side. This triangle wave has to be scaled by multiplying it with two.
To obtain a reverse sawtooth, the sawtooth is multiplied with -1 which results in a mirroring of the wave around the x-axis. To rescale the wave to a range of 0 to 1, a shift is performed by adding 1 to the wave.
The rectangular wave is made by selectively choosing a 1 or a 0 to output. This is done by the moses block. Because it takes only control lines or values, one has to add a snapshot~ block before it that is banged after each DSP cycle with the bang~ block. The sig~ block transforms this control signal into an audio signal again.
All waves can be seen in the graph when banged on the knob that is located next to the select block on top. It isn't automatically rewritten because that would slow down calculations. Every time a new wave is selected it will be drawn once.
The control logic is simple. When a specific MIDI control change number is received with a value of 127 a counter adds up. This addition is modulo the number of waveforms. An extra select block is added to select a number from the counter and then bang the right message. Each output in this patch has a multiplication with one or zero to turn it on or off.
-ronny 4/14/07 6:59 PM

phaser~

Adds a phase-shifted sound to the original sound, producing a swirling modulation that creates spaciousness and depth. Three different methods are selectable and one can control the frequency and range of the modulation, also providing different control wave forms.

version

v1.0: built 5/04/2007 with Pd v0.40-2 [pd] [pdf]

interface

Input1: incoming mono audio signal
Input2: this inlet takes values between 0 and 127 that specify the frequency of the control waves. It stands for the RATE parameter.
Input3: this inlet takes values between 0 and 127 that specify the range of the control waves. It stands for the DEPTH parameter.

Output1: The phase shifted mono signal that is output.

Controls:
Different control curves: For a sine wave, sawtooth, triangle or square wave, currently the MIDI control messages are assigned this way: respectively 52, 53, 54, 55.
Different phaser implementations: Also assigned with MIDI control change messages: 4 allpass stages is 56, 3 times 4 stages is 57 and 6 stages is 58. The default is four allpass stages.

implementation

The basic building block of the phaser is a pd allpass~ block. As seen in the figure it is a real one-zero (non-recursive) 'reverse' filter followed by a real one-pole (recursive) filter, both with the same coëfficiënts. For visual reasons, the coëfficiënts are passed to an outlet. This combination thus presents one stage of allpass filtering. This leaves the gain of all frequencies unchanged, but it alters the phase response.
The coëfficiënts of these allpass filters are altered in time. The waves block outputs a specific control curve with a chosen frequency (RATE). This curve (that lies between 0 and 1) is then scaled with the DEPTH parameter and it is also offset to lie under one. The DEPTH parameter is divided by 131 because the maximum value of the curve is 0.97 and when a range is chosen it can maximally extend to zero. The maximum value that can be passed is 127, so the 131 divides the interval maximally.
With the select and ctlin block one can choose between three setups. The A-form (A has no special meaning) uses four stages and outputs the signal coming from the last stage. The B-form, that sounds more boosted, uses three times four stages and sums every block of four stages. The C-form is another widely spread form that uses 6 allpass stages.

beat detection in pure data

Today I've also been working on a beat detection algorithm for pure data.
The basic idea behind the whole algorithm is outlined in beat this!.
It consists of four steps:

• filterbank
• smoothing
• diff-rect
• comb filtering

The first three steps (see website for more explanation) are done by the bonk~ block that is included in the standard Pd download. So as an output we get, for eleven parts of the frequency spectrum, the loudness of an attack.
The last step use a bunch of combfilters, each representing a specific tempo. All filters are convoluted with each signal and this should have to give higher energy values for comb filters that are close to the tempo of the signal.
I made a combfilter block that we can use afterwards. It uses three arguments: window, frame or blocksize firstly, then the resonant frequency and then the bandwidth. The bandwidth specifies how wide the teeth of the comb are: when it is close to zero, most of the signal is let through. When it's close to 0.5, the teeth are very wide and there is not much space between them.
I already realize that the convolution is better done in the frequency domain, because it is a multiplication there.
But the rest is for tomorrow or something.
Sleep tight

flanger~

This block applies a flanger effect on the incoming mono audio signal, that is the original signal delayed with a variable delay. It gives a metallic resonant effect like a jet plane taking off or landing. You can choose between several control curves and a free input for a control curve. You also have to include an argument otherwise the effect won't work.

version

waves v2.0: look at the documentation of this block to see what it does [pd]
v1.0: built 4/04/2007 with Pd v0.40-2 [pdf]
v1.1: built 5/04/2007 with Pd v0.40-2 [pdf]
waves block added for more choices in control curve
free control added
v1.2: built 13/04/2007 with Pd v0.40-2 [pd][pdf]
waves block is separated in development and documentation
thus no real differences with previous version, alone the documentation has changed.
v2.0: built 13/04/2007 with Pd v0.40-2 [pd][pdf]
a feedback loop is added and the level and feedback are unified into one control

interface

Input1: incoming mono audio signal
Input2: modulation frequency (MODFREQ) ranges from 0-127 (representing normalized values between 0 and 1). This parameter specifies how fast the delayed signal changes between leaping forward and lagging behind. It's modulation curve is selectable in the waves block: one can cycle through different waveforms by pushing a specific button (see documentation on waves). The amplitude is fixed to 10. If one wants to use a different amplitude for the control curve of the variable delay, the previous version should be used.
Input3: the feedback level (FBK) ranges from 0-127. This parameter specifies the range of the variable delay, how far it lags behind or leaps forward. It represents the maximum difference from no delay. When leaping forward the pitch gets higher and vice versa. If it's zero, the loop is off.
Input4: an inlet for a control signal that directly controls the variable delay time. Be careful to give a quite low frequency signal with an amplitude that is not too big.

Output1: outgoing mono audio signal: this is only the wet signal, the original signal delayed with a variable delay.

implementation

The input signal is written into a delay line.
The waves block outputs a normalized waveform with a frequency specified by the MODFREQ parameter.
The amplitude is fixed to 10 by a multiplication. This waveform is then used as the varying delay time for the vd~ block. When the values of the waveform are greater than zero, the delay will leap forward (with a maximum of one block size), when it's smaller it leaps behind (the delay time is greater).

This signal is put in the feedback loop, which feedback level is controlled by a simple amplitude logic consisting of scale block (/127) and a multiplication.

It is important to include an argument. This is needed to make, at the same time, 2 different flanger computations possible. Otherwise the delay-lines of several flanger effects used would have the same name. Now with the dollar sign, the name of the argument is inserted.

stereomultitapdelay~

monomultitapdelay~

This is a versatile delay effect. It can simulate the traditional delay (as in the monotraditionaldelay~ block and others), and many more. One has ten taps at his disposal, each one is separately controllable: delay time DLY, volume level of that tap LVL and place in the stereo image PAN. The first five taps also have the feedback level FBK parameter (as for the traditional delay).
Use:

• To simulate the monotraditionaldelay~ use one of the first five taps, set LVL and PAN to 0. All other parameters are also 0. Now choose your DLY and FBK.
• Ping-pong delay: Look at the figure on top of this page. Every tap is routed to another output. Here you see a L-R style. Other styles are: L_C_R, dynamic and random.

Every tap is output separately, but the stereo signal is on the last two outputs. All these signals are wet (that means, the original signal is not included)

version

monotraditionaldelaysimple~ v1.0 [pd]
pan~ v1.0 [pd]
v1.0: built 2/04/2007 with Pd v0.40-2 [pd][pdf]
Temporary version; presets will be included, display will be less full, more inputs will be added to control the effect like other delay blocks (BPM, measure, an array of DLY,...)

interface

Input1: the mono signal you want to delay/ go crazy

Outputs1-10: the mono signal that is output by the corresponding tap
Outputs11-12: the left and right main output of the effect. All the taps are summed here after being placed in the stereo image.

Controls:
DLY1-10: set a value here that indicates when the delayed signal will be throughput. It ranges from 0 to 3000msec.
LVL1-10: set a value here that indicates the volume level of the corresponding tap. It ranges from 0 to 100, 100 meaning at the same level as the input signal.
FBK1-5: set a value here that indicates the attenuation of the inner delay loop of this tap. It ranges from 0 to 100, 100 meaning that the loop will keep on repeating infinitely and as loud as the input signal (instability)(TO DO)
PAN1-10: set a value here that indicates where the mono signal is placed in the stereo image. It ranges from -127 to 127, 0 meaning CENTER. The panning curve used is the equal power sine curve.

implementation

The input is directly written in a delay line delay with a maximum delay length of 3000 msec. It is also on a bus with the throw~ block for every tap to grab the signal from.
The main output section also consists of two buses, one for each channel of the stereospectrum.

From left to right: a single delay part with feedback control, a single delay part and a single tap part.

A delay in a tap is done by reading the delay line delay at a specific time. The delread~ object does this. For the five first taps also a simple mono traditional delay block is foreseen. It's nothing but a skinned version of the original monotraditionaldelay~ block. It also has no display. You can see the implementation in the figure hereunder.
Every tap is then attenuated by the LVL parameter before being sent to its output. Also this attenuated signal is panned with a pan~ block, also a simpler version of the original monopanner~ block. See the figure underneath. As you can see, also here the controls are left out and only the inlets are kept. It is then put on the buses outL and outR. There will be no documentation for these two blocks as long as their not used elsewhere.

For completeness also the implementation of the controls and display are given. Every parameter is sent or received apart, where a pack and unpack block could have been used. This is not done because the idea exists that it would slow down the algorithm. This because every time a parameter would change, a whole array must be re-sent, packed and unpacked. On the other side, it would look nicer.