@billystiltner said:

And another question is it more processor intensive to use [expr] instead of

• , [+], etc..?
  Only negligibly so.

Can a moog like filter be done without writing c code? Where can I learn about designing ladder filters in pure data? I like all the ext moog filters I've heard I'm just wanting to keep my patches vanilla unless I write the external.

I haven't tried it myself, but with what I have read about Moog ladder filters, it would require upsampling due to the non-linearities of the distortion. Also, I'm not so sure it would be easy to do with Pd's raw filters. If that's the case, you'd have to get down and dirty with [block~ 1], single-sample delays, and/or [fexpr~] within this upsampled patch. In other words, it might be a cpu intensive pain in the ass.

Why must you only use your own externals? That's not exactly vanilla, either.

Another weird thing is I made a bypass for my filters. So I had 6 voices, 6 oscillators per voice, 2 filters per voice so that is 36 oscillators and 12 filters running. I added a 3rd filter per voice and when they were bypassed my machine went up to 90% cpu usage and more. ...<snip>...

Sounds like a denormal issue. Try sending very quiet noise through them at all times.

Which filters are you referring to, btw?

At what point does your patches get too big?

They don't. Your computer just gets too small.

Now I have some questions.

number 1
how do you get your last operation not to be calculated first?
I had made this intricate tuning calculation for a Karplus - Strong 12 string.
It's microtuneable to non octave tunings so in order to detune the second strings it has to be done on the fly. So every now and then the thing plays way out of tune.
I put prints in enough places so I could see what was going on.
Well final operation on calculating the frequency was getting calculated first. Or at least it was getting printed first. So I started tracing trigger bangs and floats all the way back to the first bang that started the calculation. That was crazy While making the thing I had followed the path very carefully down but since some operations depended on other operations to get done first the bangs split in multiple directions. Instead of trying to get more confused in the tangled mess I started replacing

• , [+ ], etc.. with [expr] which made it a lot easier to comprehend still sometimes the thing plays out of tune.
  This leads to my next question. The Karplus-Strong patch I started with sets a [block~ 1] is it possible this small block size is causing some of the calculation to get interrupted.

If the things that need to be calculated are not done within one block does that screw things up?
I thought the control operations were only sent once per block anyways.
and is that so if you change the block size to anything other than 64?

And another question is it more processor intensive to use [expr] instead of

• , [+], etc..?

Can a moog like filter be done without writing c code? Where can I learn about designing ladder filters in pure data? I like all the ext moog filters I've heard I'm just wanting to keep my patches vanilla unless I write the external. Propellorhead's Thor Ladder filter does not sound like any of the moog filters I've heard in pure data. Maybe it has something to do with the frequency snapped to the harmonic series or something but I've done that with the pure data moog filters and don't get the same results. Maybe the Propellorheads are upsampling to do the filters.

Another weird thing is I made a bypass for my filters. So I had 6 voices, 6 oscillators per voice, 2 filters per voice so that is 36 oscillators and 12 filters running. I added a 3rd filter per voice and when they were bypassed my machine went up to 90% cpu usage and more. So I removed the 3rd filter. Still CPU usage would go up when the filters were bypassed so I added a switch to turn them off whenever they were bypassed that fixed the problem with that. I probably ought to switch the oscilators off when they are not in use as well so I can add more. Some of them are feedback oscilators and generate chaotic signals so I guess there need to be an option to leave them on.
Now the next question and that will do it for today.

how do you print your entire patch to a ghost script printer?
I tried scaling the page so I could see the patch on the screen and still only get part of the patch in the ps file.

How do I do modulation routing with a matrix and do it polyphonically?
I want anything that has an input to be able to be routed to anything with an output and be scaled along the way. My voices are allready huge and so I would like it all to be done from within the main patch. At what point does your patches get too big? oops.

After looking at this (and your videos) and thinking about it more, I'm not so into using [sigmund~] anymore. Because it only works at message rate, I don't think it's well suited for resynthesis. I think it could be done with FFT, but I can't wrap my head around how to do it with live input (I'm not well-versed in FFT anyway), which is what I think you want to do in the end.

But I think you'll be okay with band-pass filters, unless there's something bigger here your trying to achieve that requires strictly sinusoids. I do have some recommendations, though, for how to improve your patch a bit.

First, I think you should switch to [vcf~]. You can control the center frequency at audio rate, and if you intend on doing any bends, you'll likely want that.

To go along with that, I don't think it's necessary to use _out of [sigmund~]. (In fact, the way you have it now, if your guitar is slightly flat, it will truncate to the half-step below. It should actually be [+ .5]->_if you're looking to "autotune.") Doing that kills some important guitar idiosyncrasies, like bends and vibrato. You might be better off instead using the non-integer MIDI note like this:

[sigmund~]
|
[mtof]
|
[vline~]
|
[lop~ 4]
| [r partial.number]
| /
[*~ ]
\
\
[vcf~]

Obviously you'd rework that a bit to fit in your patch, but I think you get the idea.

To pull frequencies out instead of isolate them, you'll want a notch filter. This is just a reverse band-pass filter, really, so you could make one like this:

[inlet~]
| \
| [vcf~]
| |
[-~ ]
|

Also keep in mind that [sigmund~]'s output is delayed by the hop size, so you should delay the copy of the input signal going into the filters by that amount if you want the filters to line up perfectly with the notes. Well, it won't be perfectly, but "closer to perfectly."

One last thing, instruments like guitars have noisy attacks, which can result in initial erratic pitches coming out of pitch trackers. There are two things that can help with this. One is to low-pass filter the signal going into [sigmund~] to keep the output from being to high (Some pitch trackers actually work better if you get rid of some unnecessary high-frequency content. Not sure about [sigmund~], though). The other thing is to get a running median of the output of [sigmund~]. This essentially has the effect of throwing out any outliers. You can use [median_n] from mapping to do this. You may find you'll need to delay the signal a bit more for this to be accurate, though. Probably by hopsize*median_n arg/2.

Hope that helps.__

Greetings all,

I have just posted a collection of student patches for an interaction design course I was teaching at Emily Carr University of Art and Design. I hope that the patches will be useful to people playing around with Pure Data in a learning environment, installation artwork and other uses.

The link is: http://bit.ly/8OtDAq
or: http://www.sfu.ca/~leonardp/VideoGameAudio/main.htm#patches

The patches include multi-area motion detection, colour tracking, live audio looping, live video looping, collision detection, real-time video effects, real-time audio effects, 3D object manipulation and more...

Cheers,
Leonard

http://www.VideoGameAudio.com

Pure Data Interaction Design Patches

These are projects from the Emily Carr University of Art and Design DIVA 202 Interaction Design course for Spring 2010 term. All projects use Pure Data Extended and run on Mac OS X. They could likely be modified with small changes to run on other platforms as well. The focus was on education so the patches are sometimes "works in progress" technically but should be quite useful for others learning about PD and interaction design.

NOTE: This page may move, please link from: http://www.VideoGameAudio.com for correct location.

Instructor: Leonard J. Paul
Students: Ben, Christine, Collin, Euginia, Gabriel K, Gabriel P, Gokce, Huan, Jing, Katy, Nasrin, Quinton, Tony and Sandy

GabrielK-AsteroidTracker - An entire game based on motion tracking. This is a simple arcade-style game in which the user must navigate the spaceship through a field of oncoming asteroids. The user controls the spaceship by moving a specifically coloured object in front of the camera.
Features: Motion tracking, collision detection, texture mapping, real-time music synthesis, game logic

GabrielP-DogHead - Maps your face from the webcam onto different dog's bodies in real-time with an interactive audio loop jammer. Fun!
Features: Colour tracking, audio loop jammer, real-time webcam texture mapping

Euginia-DanceMix - Live audio loop playback of four separate channels. Loop selection is random for first two channels and sequenced for last two channels. Slow volume muting of channels allows for crossfading. Tempo-based video crossfading.
Features: Four channel live loop jammer (extended from Hardoff's ma4u patch), beat-based video cross-cutting

Huan-CarDance - Rotates 3D object based on the audio output level so that it looks like it's dancing to the music.
Features: 3D object display, 3d line synthesis, live audio looper

Ben-VideoGameWiiMix - Randomly remixes classic video game footage and music together. Uses the wiimote to trigger new video by DarwiinRemote and OSC messages.
Features: Wiimote control, OSC, tempo-based video crossmixing, music loop remixing and effects

Christine-eMotionAudio - Mixes together video with recorded sounds and music depending on the amount of motion in the webcam. Intensity level of music increases and speed of video playback increases with more motion.
Features: Adaptive music branching, motion blur, blob size motion detection, video mixing

Collin-LouderCars - Videos of cars respond to audio input level.
Features: Video switching, audio input level detection.

Gokce-AVmixer - Live remixing of video and audio loops.
Features: video remixing, live audio looper

Jing-LadyGaga-ing - Remixes video from Lady Gaga's videos with video effects and music effects.
Features: Video warping, video stuttering, live audio looper, audio effects

KatyC_Bunnies - Triggers video and audio using multi-area motion detection. There are three areas on each side to control the video and audio loop selections. Video and audio loops are loaded from directories.
Features: Multi-area motion detection, audio loop directory loader, video loop directory loader

Nasrin-AnimationMixer - Hand animation videos are superimposed over the webcam image and chosen by multi-area motion sensing. Audio loop playback is randomly chosen with each new video.
Features: Multi-area motion sensing, audio loop directory loader

Quintons-AmericaRedux - Videos are remixed in response to live audio loop playback. Some audio effects are mirrored with corresponding video effects.
Features: Real-time video effects, live audio looper

Tony-MusicGame - A music game where the player needs to find how to piece together the music segments triggered by multi-area motion detection on a webcam.
Features: Multi-area motion detection, audio loop directory loader

Sandy-Exerciser - An exercise game where you move to the motions of the video above the webcam video. Stutter effects on video and live audio looper.
Features: Video stutter effect, real-time webcam video effects

Hi all, I kind of new to Pd and this is my first post here so bare over with me

I'm trying to make a synth-like patch that gets a signal in (from a microphone) and control an oscillator (osc~) so that the notes coming out is always within a certain (selectable) scale and key. I've already made a small patch that process the signal from the microphone, so my incoming signal is auto-calibrated to be between 0 (no signal/activity) and 1 (max signal/activity).

I now want to spilt my interval up in say 8 (I select major/ionian scale, and for instance the key C), so for an incoming signal of 0 it plays C3. If the signal become larger a D3 will be heard, and so on. For max signal I will hear C4. If I get for example a F3 and the signal gets weaker it should play E3. (hope you get the idea)

I know how to adjust the scale with just adding to a midi-note-number, so I reckon it would be easier to operate with midi-numbers rather than frequency...

I'm unsure on how to implement this. Maybe I should define all the different scales I want to use in tables, and pick notes from it by moving back and forth within the table (if this is possible) or maybe it's a smarter solution.

I hope any of you have any ideas. I know my explanation was not the best, but I want the end result to be a patch which let me play it like an instrument with the input from a microphone, always in tune with selected key/scale.

[adc~]
|
[module with noise filtering and auto-calibration (already made this)]
|
[magic module I need help with ]
| \
[osc~] or: [mtof]
| |
[dac~] [osc~]
|
[dac~]

Any ideas or reflections will be greatly appreciated,

best regards,
ZnakeByte

this is old... BUT

when I try to open this I get this error:

spigot~
... couldn't create
 spigot~
... couldn't create
 spigot~
... couldn't create
 spigot~
... couldn't create
 spigot~
... couldn't create
 spigot~
... couldn't create
wahwah~: an audio wahwah, version 0.1 (ydegoyon@free.fr)
 spigot~
... couldn't create
 spigot~
... couldn't create
 spigot~
... couldn't create
 spigot~
... couldn't create
expr, expr~, fexpr~ version 0.4 under GNU General Public License 
[makesymbol] part of zexy-2.2.1 (compiled: Jul 21 2008)
    Copyright (l) 1999-2007 IOhannes m zmölnig, forum::für::umläute & IEM
[msgfile] part of zexy-2.2.1 (compiled: Jul 21 2008)
    Copyright (l) 1999-2007 IOhannes m zmölnig, forum::für::umläute & IEM
[list2symbol] part of zexy-2.2.1 (compiled: Jul 21 2008)
    Copyright (l) 1999-2007 IOhannes m zmölnig, forum::für::umläute & IEM
[folder_list] $Revision: 1.12 $
    written by Hans-Christoph Steiner <hans@at.or.at>
    compiled on Jul 21 2008 at 06:08:28 
setting pattern to default: C:/Users/Cody/Desktop/ma4u/*
error: signal outlet connect to nonsignal inlet (ignored)
... you might be able to track this down from the Find menu.
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
expr divide by zero detected

whats up?

transcomp~ uses transdetect~ to shape the initial attack and release of a signal.

Requires IEM's FIR~, fexpr~ and dbtorms~ which are provided in PD-Extended.
To work properly the transdetect folder should be added to PD's path.

Start by opening help-transcomp~.pd

01 Implementation:

transdetect~ works by using two pairs of envelope followers. The first pair
subtracts an envelope follower with a slow attack from an accurate follower,
the result of which is a signal containing the initial attack. For the initial
release, the second pair subtracts an accurate envelope follower from one with
a slow release.

An envelope follower measures the mean square power of a signal over time
(see 3.audio.examples/H06.envelope.follower.pd for details on implementing an
envelope follower). To do this we must use a low pass filter at a very low
frequency. In order to achieve an accurate follower a linear phase FIR filter
was used (using IEM's FIR~ external). Unfortunately this introduces a phase
delay.

In order to facilitate the use of different envelope follower implementations,
transdetect~ requires a filter type as a creation argument implemented in
followernameTransDetectEF~.pd. 4 linear phase fir implementations are provided:
181, 251, 451 and 501 taps filters. The 501 taps filter provides the most
accurate filter but with a phase delay of 5.668 ms at 44.1kHz (raise the
sampling rate to lower the phase delay). They were all generating using
http://www.dsptutor.freeuk.com/FIRFilterDesign/FIRFiltDes102.html with a
cutoff frequency between 5 and 10 Hz.

A compromise between accuracy and phase delay might be achieved by using
minimum phase FIR filters. A 5th implementation using PD's native lop~ object
is also provided under the designation iir (FIR~ not required).

Along with different possible envelope follower implementation transdetect~
also requires an attack and hold type implemented in
attacknameTransDetectAttackShape~.pd and holdnameTransDetectHoldShape~.pd
respectively. These implementations dictate the kind of attack and release
curves used on the envelope followers (linear, slow[er|est] and fast[er|est]).
All implementations provided use fexpr~. A more efficient external could be
made to take fexpr~ place.

02 Use

In help-transcomp~.pd patch enable start and pay attention to the snap in the
hit. Disable the green toggle button to disable the compression make the snap
go away. Check out the tables on the left to see the results of the transient
compression.

transcomp~ is useful when used with recorded drums to maximize or minimize
its transient (to make it punchier or to make snare drums less clappy).

transcomp~ uses transdetect~. By itself transdetect~ can be used to synthesis
hits from a recording. For example, take a bass drum recording and use the
signals generated by transdetect~ to shape the frequency and envelope of a
synthesized kick drum.

Would love to have some feedback and some help in turning the linear phase filters into minimum phase filters.

http://www.pdpatchrepo.info/hurleur/transdetect.rar

[*~ ] just multiplies the signal by a number or fraction. so, if you multiply by 0.5, the volume of that signal will be half.

then, a basic eq would have stuff like this:

a) lowpass

[lop~ 500]

midpass

[hip~ 500]
|
[lop~ 2000]

c) highpass

[hip~ 2000]

for ease of drawing here, let's use a send/receive pair to show what happens to the signal in a simple one channel eq:

[inlet~]
|
[s~ my-signal]

[r~ my-signal]
|
| [0 ....-> 1]
| |
[*~ ]
|
[lop~ 500]
|
[throw~ eqd-signal]

there's the lowpass section. we just multiply the signal by a fraction between 0 and 1 to decide how much of the signal goes through the lowpass section.

here's the mid eq:

[r~ my-signal]
|
| [0 ....-> 1]
| |
[*~ ]
|
[hip~ 500]
|
[lop~ 2000]
|
[throw~ eqd-signal]

again, we just multiply the signal's amplitude to decide how much will go through the mid-eq section.

and finally the high end:

[r~ my-signal]
|
| [0 ....-> 1]
| |
[*~ ]
|
[hip~ 2000]
|
[throw~ eqd-signal]

then...we just catch~ all the signals at the end, and output to our speakers, or headphones or whatever:

[catch~ eqd-signal]
|
[dac~]

so, if you were to multiply that into 120 subpatches, every subpatch would contain 3 amplitude multiplications [*~ ] , and then 3 sets of filters.

however, because the 3 filter sections will be the same in every subpatch, you can just multiply the amplitudes (very cheap on cpu) and then output all 120 signals to one group of filters before going to the output.

if you look at the eq i posted as a patch, the aplitude multiplication occurs AFTER the filters. so it would be like:

[inlet~ ]
|
[lop~]
|
[*~ ]
|
[outlet~]

but, you can switch the order and have the same result:

[inlet~ ]
|
[*~ ]
|
[lop~ ]
|
[outlet~]

Yeah, it's possible to do exactly as you require for slow moving signals, by sending a [0( to the right [phasor~] inlet and forcing its phase to 0 on a transition. Problem is that this operation is block-accurate not sample-accurate so for fast signals comparable with the audio block size some dirty clicking will happen. [vline~] on the other hand can construct nice accurate time domain lines that aren't block quantised.

The lowpass used with [sig~] is a little trick to slew the control signal and make it more like an analog synthesiser. You could also use [line~] here with a 5-20ms follow time.

A signal that moves fast contains higher frequencies than a signal that moves slowly.

Let's say we have a signal that moves from 0 to 3 in 4 samples.
A perfectly linear function like a wire outputs the same number that
goes in, so for an input that goes {0, 1, 2, 3 } the output
would also go {0, 1, 2, 3}. Easy.

Now if we replace the wire with a function that makes the output be the average of the current value and the last two values, what happens? A low pass filter works by averaging together previous inputs, so it has to have some kind of memory. If the signal was at 0 to begin with then let's assume previous memory locations will contain 0.

out[0] = (0 + 0 + 0 )/3 = 0 same as before
out[1] = (1 + 0 + 0 )/3 = 0.33 now our output moves more slowly
out[2] = (2 + 1 + 0 )/3 = 1 trying to catch up
out[3] = (3 + 2 + 1 )/3 = 2 the averaging acts like an 'inertia'
out[4] = (3 + 3 + 2 )/3 = 2.66
out[5] = (3 + 3 + 3 )/3 = 3 finally we get there

It took us 6 steps to get to where we would have got in 4 steps.

This way of thinking about filters makes easy sense, but to really to understand you can read about how filters work below, but you need to sit down and scratch your chin over the maths. Millers explanation is in Argand/pole form which I find more difficult, Smiths examples include more block diagrams and C code that are more instructive to programmers imo.

http://crca.ucsd.edu/~msp/techniques/latest/book-html/node140.html
http://ccrma.stanford.edu/~jos/filters/Simplest_Lowpass_Filter_I.html

Hello,

please excuse my stupidity both in programming and generally in understanding PD. i've been trying to figure a way to convert a frame number (received with OSC) to a timecode but the code i tried to adapt from a matlab script by Malcolm A. MacIver that i found here http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=1116&objectType=File
involves some for...loop and i dont know how to do the same in PD... can anyone explain, please?
i guess the field part of the smpte timcode (and other bits of information) are usually not needed, for most people HH:MM:SS:FF Information will be ok... maybe with an adjustable framerate between 30 (ntsc) and 25 (pal)

greetings,
till

function smpte = dec2smpte(init, framecount, field)
% convert the smpte time from the total elapsed frames and field as an integer
% to the new smpte time

first_field=init(9);
weight=[1080000 108000 18000 1800 300 30 10 1];

ns=[];
remain=framecount;
for i=1:8
  ns(i)=floor(remain/weight(i));
  remain=remain- (ns(i)*weight(i));
end

if strcmp(first_field,':')
   second_field='.';
else                                     
   second_field=':';
end

if field==1
   field_flag=first_field;
else
   field_flag=second_field;
end

smpte=[ ...
    num2str(ns(1)) num2str(ns(2)) ':' ...
    num2str(ns(3)) num2str(ns(4)) ':' ...
    num2str(ns(5)) num2str(ns(6)) field_flag ...
    num2str(ns(7)) num2str(ns(8))];

different approach here

function itc (int "framecount", float "rate", bool "ms")
{
rate=default(rate,25)
ms = default(ms, false)

drop = (rate==29.97)? true : false
rate2 = (drop==true)? 30 : rate

hours=floor((framecount/rate)/3600)%60
mins=floor((framecount/rate)/60.0)%60
secs=floor(framecount/rate)%60
milli=floor(1000*framecount/rate)%6000%1000
fmilli=framecount/rate - floor(framecount/rate)
#frames=floor(fmilli*rate2)
frames=framecount%int(rate)

dframes = (drop==false)? frames : (secs==0)&&(mins%10!=0)? floor(fmilli*rate2) + 2 : frames

return (ms==false)? (string(hours,"%02.0f")+":"+string(mins,"%02.0f")+":"+string(secs,"%02.0f")+":"+string(frames,"%02.0f")) :
\ (string(hours,"%02.0f")+":"+string(mins,"%02.0f")+":"+string(secs,"%02.0f")+":"+string(milli,"%03.0f"))
}