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

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

Howdy.

I'm very new to pd, having just installed it to see if I could use it to create a synth I have already designed.

At the heart of the synth is a pair of sync oscillators. So, to recreate it, I'll need to be able to reset an oscillator to the beginning of its cycle every time a master oscillator crosses zero.

After searching, I read a couple old posts dealing with generally ineffective ways to detect zero crossings, and then chanced upon a post that mentions [zerox~]. Apparently, it detects all zero crossings (2 per cycle of a sine wave) and there is no help file to speak of.

Does anyone have any experience with this object? I'm interested in knowing if it is practical for audio-rate detection.

I'll be doing some experiments of my own, which will progress slowly as I familiarize myself with pd.

Thanks

ha ha, it's not very scientific. but anyway...

[noise~] outputs a random value between -1 and 1 every sample.

we then multiply the output of [noise~] by a number between 2000 and 20000

this means that going into the frequency control of the [osc~] object will be a signal between -2000 and 2000 at the lowest setting, and -20000 and 20000 at the highest setting.
sending negative frequencies into [osc~] is just the same as positive ones, but the oscillator wave flows in the opposite direction.

so, every sample, we are changing the frequency of the [osc~] oscillator. if we only oscillate at frequencies between -2000 and 2000, then the maximum frequency output will be 2000hz. however if we ramp it right up to 20000, then the oscillator will oscillate at higher frequencies.

it still sounds like noise though, because the frequency of [osc~] is changing so rapidly that there is barely any periodic content in the output waveform.

aying to myself... as soon as I tried to use that oscillator in something like a synth, I realized that it is a real CPU hog. a single instance seems to take ~ 10% of my 1.83GHz dual core T2400

I suspect this has something to do with the 4 pow~ objects. so I banged my head on it for almost a whole weekend and I came up with a totally different approach, more puredata-friendly, which uses a single pow~.

basically, I use 3 phasors (freq, freq*2 and freq*4), get a square ware from the first two, then do some math to coerce them to various -1/0/+1 combinations, then use the results to do some other math on the main phase.

the code in C now would look something like this:

// sq1_zm: square at base freq (0>-1)
// sq1_pz: square at base freq (1>0)
// sq1_pm: square at base freq (1>-1)
// sq2_pz: square at freq*2 (1>0)
// sq2_pm: square at freq*2 (1>-1)
// phase4: phase at freq*4
output = sq1_zm+(sq1_pz-pow((sq2_pz-phase4)*sq2_pm, fatness))*sq1_pm;

pretty nasty stuff (I don't expect you to say "ahhh, yes, it's clear as light" , but it was a very challenging exercise. also very rewarding.

I was able to build a very basic 8-notes polyphonic 2-oscillator synth with it, that does frequency AND fatness modulation. the sound is interesting, but I still need to explore parameters tweaking and stuff.

please find attached the revised fatosc~ patch. feedback is really welcome.

I will post the synth as soon as I've cleared up the wiring mess and built a decent UI for it. (and if there's some interest in it, of which I don't see much... please show hands .

cheers,
Aldo

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

If you understand the basics of synthesis - which i assume you do - it won't be too hard to build a synth which has the same kind of architecture as an MS10 (although the patching could be tricky). Looking at/studying miller's synth in the pd help (browser -> 7.stuff -> synth -> 1.poly.synth.pd) will give you a good idea of how to start on this one.

However, if you're looking after an exact recreation of the ms10 sound, then you should talk to some guru's who know how the filters and oscillators of the original work, and i guess you're in for quite some fun.

Some quick tips to get you started :

For oscillators and lfo's look at [osc~] [phasor~] and [noise~] objects
For envelopes look at [line~] and [vline~] and if on linux/mac [ead~]
For filters look at [lop~] [hip~] [vcf~]

Right-clicking on an object will let you open the associated help file. These often contain links to many more related objects.

Hope this helps (a little),

Domien

hi,

i'm new to pd and started working in 0.38.4-extended under winxp. i just switched to version 0.40.2 (for easier handling of graph-on-parent) and get a problem: although my midi devices are listed properly when invocing pd with the -listdev %1 %2 %3 %4 %5 %6 %7 %8 %9 command line option, they are not selectable in the midi settings (only #1 is shown for input, and #1, 3 and 7 for output). do you have any idea what might be the solution?

(those are the devices:)

MIDI input devices:
1. MPU-401
2. SB Audigy MIDI IO [E000]
MIDI output devices:
1. Microsoft MIDI Mapper
2. SB Audigy Synth A [E000]
3. MPU-401
4. SB Audigy Sw Synth [E000]
5. SB Audigy Synth B [E000]
6. SB Audigy MIDI IO [E000]
7. Microsoft GS Wavetable SW Synth

Again, not much activity here because of problems in sysex/midi.
What would be nice here for people building external synth editors is a working
raw midi on all platforms and a set of abstractions to dump, store and examine
sys-ex messages. Have you looked through all of extended/grdiflow/etc and still
not found something to do it?

Manufacturers sysex charts, different for each synth but basically assign controllers to
internal parameters that just arent realtime controller messages, and you fill out the
variable field, usually at least two midi bytes (14 bits) or longer variable length
parts.

They're all published so setting up new synths is no worry. I would actually canibalise the
old sound diver data files I reckon. )

Patco did something with the idea of a "universal synth editor" not too long ago...

IIRC the expander is TWO matrix12's in a box, which is a beast of a synth with hundreds of
parameters... so yikes!, best to start with data in a form that is machine readable that you
can inject your variables into.

> it scares me to use it in case it wipes out all my patches forever!!

Do a sysex dump of your setup and restore it once to feel confident about hacking
the Oberheim via sysex.

Yep... stn, the bot environment is a great immediate, self-contained PD
environment. I really like the examples (tutorial) you provided
with it - great sounds and clear examples.

Apart from sequencing side, I looked a bit into "expandibility" of bot
since I really like the approach
of bot pre-made (and candy colored tools like filters, synths, FX but
this is not really easy: for example
if you want to add a synth to the bot arsenal (hardoff's great juno synth comes to
my head in this moment this is not immediate, nor it is to take a FX out
of bot and use it into other environments (at least you need to make some - mmh, heavy? - mods). So at the end if you want some special features
you may feel a bit "narrow" between bot walls

On the other side I think that if one being used to it, bot *is* one of the much powerful environment I've seen in PD for direct, straigth music composing out-of-the-PD-box. (X Andy: looking into your songs I've the impression
of a slightly different approach: if in bot sequencer is completely separated from
the synth-effect part like a orchestra-score in csound, in your songs the
division is not so "clear", and the sequencing side seems a bit more integrated
with the synth-effect side: am I right? I still need to find my way

So when I first started with PD last year it was a great
discovery like: "wow, this bot is really cool!", which for a PD starter like I was
this helped me a lot in staying inside PD world. So, even if it is not complete,
even if you are not completely satisfied with it ... put it on-line again

I saw that you prepared later last year a tool called "mmm": are you still
developing around it? That was a different approach, and personally I had a
bit more difficulties in understanding it w.r.t. bot...

All the best,

Alberto

Hello, my name is Martin. I am doing a simple PD patch but I have a lot of doubts and problems with it.
What I need is a simple synth to control ADSR , have 4 presets, simple modulation (AM, FM), and include a free improvise composition.

What I have done is this (Please see my pd patch synth.pd).

What I really want to have is something like this:
http://music.ucsd.edu/~tre/ - a simple 6 voice synth with presets

Anyone can help?

Thank you very much,

Martin.

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