Hi folks,

Been playing with a band for a while but been encouraged to start a solo project. here's a first track sequenced live on PD with a novation launchpad.

Makes heavy use of samples, beat cutting and of course my recently released minimoog style synth
http://puredata.hurleur.com/sujet-4087-minimoog-style-synthesizer
programmed via OSC.

After reading this article
http://en.flossmanuals.net/PureData/Antialiasing
I decided to create my own bandlimited signal generator.

This external generates square, triangle saw, reverse saw and saw-triangle waves band limited to the nyquist limit.

In order to conserve CPU usage it uses a series of wavetables. Because of this it might take a little while (a few seconds) to load up the first instance.

The easiest way to use it is to add the bandlimited folder to your path. But you can also use it like this:

[bandlimited/bandlimited~ square]
[bandlimited/bl.sq~]

as long as the bandlimited folder is placed into a folder already in the path (ex: ~/Library/Pd on OS X)

...

There are wrapper abstractions for each waveform type (bl.saw~, bl.tri~, bl.rsaw~, bl.sawtri~, bl.sq~]

Start by taking a look at bandlimited~-help.pd

The object should act a lot like [osc~] and [phasor~]. The first signal inlet controls the frequency while the second float inlet sets the phase and it takes a creation argument for the starting frequency. There are three methods but I'll let the help file explain.

There should already be a win32 dll build and an OS 10.5 build. I'm sure linux folk can take care of themselves in this regard. Tested on PD-Extended 0.41

There's a repository here
http://gitorious.org/bandlimited/bandlimited

I plan on adding more waveforms and am taking suggestions.

v0.92

EDIT:
Version v0.92 includes a new waveform, pulse. This wave form is a lot like a square wave but with a variable duty cycle (it's not symmetric). This new parameter is set by a third signal inlet whose value should be between 0 and 1. 0.5 would give you a square wave.

Version v0.91 includes new method "approximate" which uses the CPU a little less for a close enough waveform.

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

Is there a fundamental difference between netsend/netreceive and sendOSC/dumpOSC?

Does netsend and netreceive not work for OSC?

After a year of off again on again work I finally finished a virtual minimoog in PD. It's pretty close to the real thing. It doesn't do the low frequency rhythmic clicks and I guessed the proportions on L and K, but it works well enough.

Requires PD-Extended 0.41, check out INSTALL for instructions.
It requires muug~ http://puredata.hurleur.com/viewtopic.php?pid=17403#p17403 which is included in this zip in a folder named extra-externals (binaries for Windows and OS 10.5 already compiled). In extra-externals there is also a popup.dll. I found that popup does not work properly in windows and made a fix for it. I submitted it here:
https://sourceforge.net/tracker/?func=detail&aid=2985017&group_id=55736&atid=478070

But I included my fix here anyway. It was compiled with MinGW. First see if your version of popup exhibits this error:
error: popup0xa4fda0: no such object
while attempting to select an item from the list. If so replace it with the provided dll. It should be in the PD folder under extra/flatspace

It uses OSC instead of midi but there is a midi to osc interpreter. There's also a computer keyboard to osc interpreter but it doesn't work very well.
Check out minimoog-hep.pd

You can load more than one minimoog at a time but you'll have to use different OSC ports for each instance.

Thoroughly tested in OS X. Quickly tested in Windows and Linux. In Linux it tends to crash PD when closing the patch.

I made a repository for it here
http://gitorious.org/pd-minimoog
So if you'd like to include some changes let me know.

Latest version here
http://gitorious.org/pd-minimoog/pd-minimoog/archive-tarball/master

EDIT:
v0.92 - Added antialias option before filter.
v0.91 - fixed some issues with OSC and FUDI

http://www.pdpatchrepo.info/hurleur/pd-minimoog.zip

Is there anything like a drop down list object in PD?

http://en.wikipedia.org/wiki/Drop-down_list

Recently a student of mine created a sampler that loads files from disc but had issues with the long pauses on synthesis caused by loading the files through soundfiler. Having the same problems myself as well as noticing others commenting about this around here I've decided to do something about it.

I give you samplemap. Basically it maps file names to arrays so that a file is loaded only once. To install copy the samplemap folder (not its content) onto a folder in PD's path. First check out help.pd for a general overview and then try out help-example.pd for a practical example.

Samplemap works through the abstraction [samplemap/load]. This abstraction receives through its inlet a filename and returns an array name through its outlet. In between it communicates with [samplemap/samplemap-int] which is opened only once and should not be closed (you don't need to open it, [samplemap/load] takes chare of that). samplemap-int checks to see if the file was already loaded, if so it returns the array names in a list (one per channel), if not it loads all the channels through [soundfiler] onto dynamically created arrays and returns a list of those array names.

There's also a [samplemap/loadfolder] abstraction that loads all wav files in a folder. It is not recursive.

help-example.pd shows you how to set up your patches to pre-load wav files.

I've tested it on a Windows and Mac boxes. Works only with WAV files. Uses Jack/RYBN 2009 patch that concats a list onto a single symbol with spaces, so folders and files with spaces in them work ok.

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

Hey guys and gals,

Just finished this video with a friend of mine using GEM. The music also relies heavily on PD.

Enjoy!

Has anyone ever worked with drawing a signal onto a plot in PD?

I'm look for something like tabwrite~ but that draws to a plot rather than a table.

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

This came about the discussion on topic http://puredata.hurleur.com/viewtopic.php?pid=10547

It's an example of waveshaping with attack and release settings. Could be made better by using tabsend~ and tabread~ but I'm not sure how to make the phasor~ work in phase with the block size.

table waveshape holds the distortion table, and table distortion is what is actually used to shape the signal. What's in waveshape is mixed with a linear signal in accordance with the attack and release settings.

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

The logic is quite simple. A low pass filter filters out high frequencies. When you have a control signal spitting out 0s and then at some point it just shifts directly to 1 in the span of 2 samples it will generate high frequency signal. You can even test it by sending it straight to your speaker, when it goes from 0 to 1 back to 0 in the span of 3 samples you'll hear a high click. The lowpass filter attenuate this high frequency by averaging out the change over a longer period of time creating the desired smooth fade.

It is a topic worth discussing. In my experience most people programming in PD do not have a software engineering background and end up doing a lot of things that are frowned upon by software engineers, eg: unmaintainable copy-past code, always starting from scratch, monolithic code.

A the end of they day though we shouldn't just apply higher level SE principals just for the sake of it, it should be done to help us be more productive and efficient in writing our code. One thing that I've personally found useful is decoupling programing interface from implementation code. Basically I'll create an abstraction with an expected number of arguments and certain inlets and outlets for a doing a job and then several different abstractions for doing that job. As an example I'll create a compressor abstraction that is instantiated like this:

|
[compressor name ratio threshold attack release]
|

The guts of this object would look like this:

[inlet]
|
[$1Compressor $2 $3 $4 $5]
|
[outlet]

So in order to work there must exist in PD's path an patch called nameCompressor.pd. This patch would then hold the implementation details for a particular kind of compressor. The advantage of coding like this is that it allows your code to be modular. I can have a few different algorithms (linear, non-linear, with or without antialiasing, etc) but since the patches deal with them through the compressor abstraction it becomes very easy to plug them in and out of my existing projects without breaking anything. It also forces me to develop any future compression patch to work with this interface for the same reason, ease of using it with my existing projects.

The example I gave here is pretty trivial. When we start dealing with varied controllers (midi, keyboard/pointer, osc, netsend) the advantages become more obvious. You can create a new instrument (synthesizer, sampler, etc) and easily change the controlling device without having to directly change the code of the instrument itself precisely because the code that handles the input from the controller is decoupled from the patch that is using that input.

Add add a filter after the delay output, try a hi pass filter at around 300-500hz.

You'll also have to add in some shotnoise.

I made a patch for that a while ago.

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

Been reading the PD mailing list. Apparently there's some performance issue with PD (exended or not) running on OS X with the internal soundcard.

pretty sweet!

One more thing. Using a LPF by itself often is not enough, you have to do so in an upsampled block. Check out the original article.

http://en.flossmanuals.net/PureData/Antialiasing

Distorting often adds harmonic frequencies which would lead to aliasing, even with an originally bandlimited signal.

If you want a single variable to be accessed by all instances of an external just declare it static.

I see an error, should be
L = [expr 22 + (56 -22) * (1 – cos ($f1)) / 2]

[Lmax – Lmin] wasn't being grouped.

p