This is a collection of abstractions that generate bandlimited oscillators. They include:

[bl-saw.mmb~] - bandlimited sawtooth waveform
[bl-pulse.mmb~] - bandlimited pulse wave with PWM
[bl-tri.mmb~] - bandlimited triangle wave
[bl-asymtri.mmb~] - bandlimited asymmetrical triangle wave (sort of...see below)

There is also an object called [bl-init.mmb]. This is the object that initializes all the waveforms and at least one instance MUST be included in order for the others to work.

There are also help patches included.

IMPORTANT!
Before you can use these, you must do the following steps.

1. Open [bl-init.mmb]
2. There is a message box that says [44100(. This is the maximum sampling rate that these will work at (running at lower sampling rates will be fine). If you plan on using higher sampling rates, change this message box and click it. Technically, it will still work at a higher sampling rate, but it won't generate harmonics above the sampling rate in this box.
3. Click the [bang( to fill the wave tables. This patch actually creates a wavetable for EVERY harmonic between 30Hz and the Nyquist frequency. So it will take a few minutes. Be patient! You will get a message in the Pd window when it is done.
4. Save the patch.

Once you do this, [bl-init.mmb] will simply load with the tables already generated, so you don't have to wait every time you instantiate it. I didn't have this already done for you in order to keep the upload small, and so you can see how to adjust it if you need to.

So, I guess I'll go ahead and try to explain how these work. As stated above, every harmonic is generated in [bl-init.mmb] for the oscillators. It doesn't create a table for each set of harmonics however (e.g., there isn't a saw table with two harmonics, a saw table with three harmonics, etc.). Instead, each of these individual tables are tacked on to the end of each other to create one long wave table. So, for each set of 1027 samples in the sawtooth wavetable, there is one cycle with a set amount of harmonics.

When the oscillators read the frequency input, it is divided into the Nyquist frequency to determine how many harmonics are needed. It then uses this (* 1027) as the offset for the table. This is how I got around the problem of table switching at block boundaries. By doing this way, the "switching" is done at audio rate.

There are actually two [tabread4~]s. One has one less harmonic than the other. As the frequency changes it crossfades between these tables. When one table goes completely silent, that's when it "switches." Below 30Hz, they switch to geometrically perfect waveforms.

[bl-saw.mmb~] and [bl-tri.mmb~] just read through the tables. Nothing really interesting about them.

[bl-pulse.mmb~] is actually the difference between to sawtooths. In other words, there are two bandlimited sawtooth oscillators inside of it. Adjusting the pulse width cause the phase of one of the sawtooths to shift. When you subtract this phase-shifted sawtooth from the other, it creates a bandlimited pulse wave...without oversampling! This is the same Phase Offset Modulation method used in Reason's SubTractor.

[bl-asymtri.mmb~] uses the same technique as [bl-pulse.mmb~], except it uses bandlimited parabola waves instead of sawtooths. Adjust the phase offset sets where the top vertex is. This doesn't really generate true triangle or saw waves, though. They still have the parabolic curve in them, so the harmonics seem to come out a little more. It's more of a "reasonable approximation." But, it is bandlimited, and it does sound pretty cool to modulate the shape. I don't have the scaling quite right yet, but I'll get to it later...maybe.

I should also mention that these use my [vphasor.mmb~] abstraction, so the phase reset is sample accurate.

I'll eventually set these up to allow frequency and pulse-width arguments, but I'm currently in the process of moving to another country, so it may be a little bit before I get around to it.

Didn't any of that make any sense?

http://www.pdpatchrepo.info/hurleur/bl-mmb.zip

hmm. ah, okay, that's common sense. I should have picked up on that. Thanks for helping me out a second time on the same issue, haha. That will work for the main thing I have in mind.

However, one thing I'd like to do eventually is have two oscillators running at independent frequencies and one phase modulating the other. So it would be useful for me to have a control that would reset the phase on a note-on message. That way I could toggle the control to have either free-running oscillators or oscillators that start at a specific phase each time a note is produced.

to realize this should I just use a master phasor~ by default and toggle in additional phasors as independent frequencies become necessary? I feel like at that point I would still be lacking note-on phase syncing.

The note-on phase syncing is handy for realizing predictable note attacks when the difference in frequency is relatively small. It's a feature in Ableton Live's Operator, for example (I don't own this actually).

Thanks for bearing with me on this. The relative nature of phase has always confused me to a degree.

If you plan on using [xerox~] to phase sync two oscillators, it probably won't cut it. Generally, you want those things to be sample accurate. [xerox~] will give you a click corresponding to zero crossings out its right outlet, but, as far as I know at least, Pd's oscillators can't really use that for phase syncing ([xerox~] is actually based on a Max object, yet strangely Max's oscillators can't use it either). It would require a conversion to message rate to reset the phase, which kills sample accuracy, not to mention the fact that the phase input of [phasor~] quantizes to block boundaries (default 64 samples in Pd), which also kills sample accuracy.

However, if you know the ratio between your two oscillators, phase syncing can be achieved using a master [phasor~] to run both oscillators. Use the master sync frequency to drive the [phasor~], then multiply the output of the [phasor~] by the ratio between the synced (slave) oscillator and the master one. In other words, it should be multiplied by:

slave frequency / master frequency

Then, you just [wrap~] the signal and viola, you have a new synced phasor signal to drive the slave oscillator. The attached patch should hopefully clarify.

http://www.pdpatchrepo.info/hurleur/phase-sync.mmb.pd

Hi,
I attached a really small patch I created to start a soundfile when a face is infront of the camera.
I use windows, so I use Processing to detect the face. That is the [OSCroute /face] object. /y is another parameter (influenced by a color detection) that should later controle the volume.
If there is a face, than the value of 1 is transferred to /face and the tabplay should start and loop. If there is no face the value of 0 is transferred, but I don`t know how to stop a play. It should stop directly and not after the ongoing play is finished.

And moreover, it should stop, if the value of 0 is 2 seconds constant, because the face detection is not always stable.

And another problem, I don´t know how to use the onebang correctly.

Can you help me? That would be so great!

Thanks a lot,
Anna

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

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

> Obi - doesnt the timbre suffer if all the phases are equal (sounds a bit static)? I
> think in the expensive version they are all running at different phases which
> makes the result richer. Can wrap~ be used to offset the phases and still be
> cheaper than a bank of osc~ objects

Yes, but it depends on how the wave is used. "Suffer" might not be the best word. Some sounds thrive on phase synchrony.

Having free running (independent) oscillators or a common phase makes very little difference to a constant timbre, a drone/sustained note. The ear doesn't pick out any phase relationships, even if they change slowly within the sound.

But if you want a very percussive sound, like a struck string, to sound correct and reliably trigget on each hit, you need to sync the phases.

The method given above is equivalent to using [sinesum( messages with [tabosc~] or waveshaping - the component phases are governed entirely by the driving waveform. In a polyphonic instrument each voice would be identical and the total result would sound dry/sampled/2D. But with independent oscillators each voice would start with subtly different component phases, and the total result is much deeper/richer/fat.

To compromise efficiency and quality it's good to supplement very terse methods like the one shown with some chorus/flanger/phaser

About [wrap~], it is unneccesary in this case because [cos~] is a periodic function which already remaps the domain. In fact the domain offset _is_ the phase offset, but in out case they are all integers (multiples of 2 * pi if we didn't have Pd rotation normalised functions) so each is a harmonic that aligns with one beneath it. [wrap~] could be used to align phases from a line. In fact a [line~] plus a [wrap~] is a [phasor~]. But we wouldn't get different frequencies by taking the cosine of shifted copies, instead we need to multiply each new phase by a constant to change its slope. The slope multiplier, m in the equation y = mx+c, gives the rate of change and hence the frequency. Interestingly that means if the phases are synced perfectly there's always a transient at the start t=0 where every cosine must be simultaneously 1, so great for struck body sounds.

hello all.

I'm a total newcomer here, and I have more or less 2 days working experience with Pd

so please bear with me for the "bad coding" or naivety or whatever. anyway, this is my first Pd patch, and I thought it deserves to be shared.

it is a morphing oscillator with controllable fatness, thus called "fatosc~". it has 2 inlets (frequency and fatness) and one outlet (the noise!).

the "fatosc~demo" patch features an oscilloscope and can be eventually played via MIDI. (no envelope or fancy stuff, monophonic and note on/off sensing seems to be a bit flakey).

I originally coded the oscillator for a completely different project of mine, but wanted to do some quick soundcheck with a realtime system, and Pd fitted just perfectly.

the original C code looks like this:

if(phase > 0.75) {
    output = -1.0 + pow((phase-0.75)*4.0, fatness);
} else if(phase > 0.50) {
    output = -1.0 + pow(1.0-(phase-0.50)*4.0, fatness);
} else if(t > 0.25) {
    output = 1.0 - pow((phase-0.25)*4.0, fatness);
} else {
    output = 1.0 - pow(1.0-phase*4.0, fatness);
}

I had a hardtime figuring out a Pd equivalent for if/else. and I'm still not sure I got it right

anyway: with fatness=1 the oscillator generates a triangle wave. with fatness=PI, it generates a sine wave (don't know if it's a mathematically pure sine, but it looks pretty similar). going up with the fatness, it approximates a square wave.

on the other hand, with fatness < 1 it generates a nice looking curved triangle waveform, which I've called "jawtooth". I was really thinking "shark tooth", but my fingers are faster than thought

with very small fatness values, it "degenerates" to almost silence.

should be interesting to do some FM or other modulation with it. that's what I'm going to try next.

hope you find it useful and/or entertaining.

PS. of course, the algorithm is "pat.pend.", so if you're going to use it in a commercial product, my horde of lawyers will knock at your door and haunt you in your dreams.

ok, just jocking, feel free to do whatever you like with it.

critics welcome!

cheers,
Aldo

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

hi forum.

we proudly announce the first public release of our compact composer
for pd, mmm.
grab it at http://netpd.org/mmm-0.1.0.zip
mmm is best described in it's faq, see below. don't expect too much
yet, there is still a lot to be done. comments, bugreports, cash, are
welcome.

have fun with it!
christopher charles & enrique erne

faq for mmm-0.1.0 - eden

what is mmm?
mmm is a pd patch collection aimed at providing a studiolike(?),
streamlined, dynamic interface for making synthetic music.

screenshots?
http://www.netpd.org/mmm.png
ymmv depending on your operating system. we put some effort in
detecting the operating system and setting the fontsize according to
it, but quirky xorg or dpi settings might screw things up again.

where can i get it?
we currently host the mmm at http://netpd.org/mmm-0.1.0.zip ,
alternatively, you can grab netpd, enter the chat, and if either of
the authors is online, download it directly through netpd and start
rocking.

what does "mmm" stand for?
mmm was originally just the working title, but we came to like it
somehow. the original meaning is "music making machine" but you can
substitute every m for whatever you want. so "massive multiplayer
music" is okay with us, too.

what is the inspiration?
having worked on/with the bagoftricks (lots inconsistently coloured
gop-patches to be connected freely) and netpd (lots of
inconsistent-looking windows to clutter up the screen), we came to
mock up an clean, dynamic interface in which modules don't bring their
own gop or open their own window, but log onto the interface that's
provided for them by the motherpatch. all modules sharing the same
interface made it easy for them to share the same sequencer and
arranger.

what are the dependencies?
mmm should work with pd-0.39 and zexy installed. iemlib is important
for many synth and effects patches, and there's even set of gem
modules you can chain if you want.

is it actually usable?
no. this 0.1.0 release is rather a tech demo and a taste of things to
potentially come. you can crunch some acid loops out of it already,
but don't sell your protools studio equipment to start working with
mmm on monday.

how does it work?
mmm's interface (mmmmain.pd) is divided into 3 parts: there is the
module/channel view, where you can chain up synths and effects on 8
different channels. select an empty field on a channel, and then use
the scrollbox on the left to select a patch and open it. when clicking
on a patch you loaded up in the module view, the 2nd view comes into
play: from there you control the patch's sliders on the left, right of
it is the stepsequencer for each of the slider (means everything is
sequencable!). yet you won't hear anything until you did the following
2 things: press play in the uppermost row of mmmmain, and set up the
arranger to play the stepsequence. the arranger is not module-based,
but controls all modules of a channel are grouped in the arranger. for
now, you can only select pattern 01 or nothing to play in the
arranger. so set up a loop for the first pattern (loopstart:0,
looplength:1) set the first field on the channel you got your patch on
in the arranger to p01 and start making some noise.

does it work online?
yes. mmm is compatible to netpd and will automatically log on to
netpd's server if you have the netpd chat open. you can also download
the whole mmm package through netpd. feel free to jam around the
world.

what's not working yet / what is planned?
as for now, there is no support for samples whatsoever, it isn't
planned to support them soon. further, there is no hard disk recorder
available yet, but it is planned. the arranger/sequencer combo is very
crippled at the moment, only supporting 1 16-step-pattern to choose
from and 1 page of 16 patterns in the arranger. this will change
rather soon. next there are plans for luxury editing functions,
especially in the sequencer like copy, paste, random pattern,
interpolation and so on. plans exist for full keyboard control, but
this will be worked on not too soon. the module roster is far from
being complete yet, more is to come.

can i save my stuff?
should be possible with the buttons above the channels. don't rely on
the result though, this is still 0.1.0

can i add my own modules?
modules are not to hard to write, but for now, the list of selectable
modules is hardcoded. look at all the 4m-* patches in the patches
folder to see how they are ticking. contact us for adding your patch
to the mmm or try to figure out yourself how it works

what's the license?
mmm is licensed under the gnu lgpl. if you think this is a too useful
product to be free of charge, please consider donating the amount of
money you would've paid for it (or the amount of money you got from
selling your protools equipment on monday) to a trust of your choice.

who are the authors?
mmm is developed by enrique erne (eni, swiss, pd{at}mild.ch) and
christopher charles (syntax_tn, germany, chr.m.charles{at}gmail.com).
we can be contacted via email, irc (#dataflow) or directly in the
netpd chat. several patches within mmm are based upon netpd versions
of them, check netpd for the original authors. mmm shares some of it's
netcode with netpd, by roman haefeli.

disclaimer.
we cannot give you any guarantees on using mmm, not even that you
have fun. it should be relatively harmless, but don't come crying to
us if mmm accidently hijacks your *mule and downloads david hasslehoff
recordings to your computer.

eofaq