PolyBLEP oscillators are just totally awesome. I haven't found a more CPU efficient way to get basic oscillators free of aliasing or artifacts. This patch lets you compare the sounds of polyblep oscillators with their standard counterparts.

The polyblep triangle which I cobbled together may be of most interest as both the square and the saw are found in the heavy library.
The triangle works by feeding a pb-square into an integrator. The integrator could probably be used on its own for purposes like envelopes or experimental feedback. Note that there's an audio loop with send and receive objects so you may want to use the integrator in an abstraction or change the s/r names if using multiple triangles in the same patch.

polyblep-oscillators.pd

I don't know if this is what you are going for, but based on your initial description this is what I envisioned.

I would use frequency modulation to get random pitch fluctuations.
I would use a random pitch oscillator to achieve this too, so it's not predictable like a sin wave would be..

You can see what I did in the screenshot.
I used perlin~ from the else library, it's a pretty good random pitch generator, but there are a few good ones in Else. It's worth trying a few out. I would use a low number, like less than 3 for the frequency of the oscillator doing the modulating.

I used a saw~ for the actual oscillator, and I think that's a Cyclone object.

For a brief explanation: a given frequency is being randomly oscillated within a given range (amount of oscillation). If you want a less wide oscillation change the amount of oscillation. The frequency of the perlin~ ( or whatever noise oscillator you use) is how fast the modulations are happening.

So, how about we discuss all these options and how they relate to each other? Anyone with me?

Let me talk about FOF here... Basically, it's a hard-synced oscillator! And I always thought hard synced oscillators sounded really nice for forcing harmonics into a fundamental pitch, and that's it... Ok, there's more to that of course, and it also passes through a decay envelope, which can be implemented with [rpole~], here's a minimal Pd patch of this main core.... it uses objects from ELSE of course... specially for making hard sync easier. Below, 150 is 'f0' (fundamental), 390 is center/formant frequency, and 100 is bandwidth, all in Hertz...

But then, the envelope grain might and can overlap. The Csound implementation is pretty much "Csoundy", ridiculously complicated with way too many parameters and options, not to mention a seemingly inexplicable low output that forces you to multiply it by a ridiculously large and arbitrary number. Besides the decay envelope, it also applies another envelope on top of it, which might be pretty useless when the first envelope simply dies before it, but it can be useful to apply an attack phase. What a mess! The FAUST implementation is simpler and makes more sense!

The Formlet UGen from supercollider implements a filter with attack and decay, and it rings, so you don't need the hard synced oscillator. Plus, it can "overlap" grains quite seeminglessly. It's pretty clever and it made its way back into Csound, where it's called fofilter.

What makes no sense for me is the "BandWidth" parameter in FOF (or using Formlet). In Pd's examples we have the paf like patches and the bandwidth makes actual sense because it represents a bandwidth of partials over the center frequency. In FOF we don't have that and the larger the bandwidth, the thinner the sound actually is because the decay is faster.

Now, i also ported the Formant UGen and this is what it is, basically, as a patch, guess what? Yup, another hard synced oscillator, basically, being enveloped, so... I guess it relates to the Fof approach... but not quite... one way or another, there's no reference in the docs or code of where it comes from and maybe I should ask the SC Forum (again) Below, BW ratio means the ratio of bandwidth according to the fundamental, so '3' is '150' hz. This parameter to me feels like controlling the "brightness" anyhow.

And there are also the FM approach, the paf, the VOSIM, not to mention the filterbank approach... Gosh, what a mess... I guess I know why I procrastinated so much to finally deal with this... but it's time and now I'll map them all and see how they relate to each other. And I'll sort it all out in my Live Electronics Tutorial...

I'm still thinking what are the objects that make sense actually including in ELSE...

Hi, it's been a while, here we go:

RELEASE NOTES:

Hi, it's been almost 8 months without an update and I never took this long!!! So there's a lot of new stuff to cover, because it's not like I've been just sleeping around

The reason for the delay is that I'm trying to pair up with the release cycles of PlugData and we're having trouble syncing up. PlugData 0.9.0 came out recently after a delay of 6 months and we couldn't really sync and pair up then... we had no luck in syncing for a new update now, so now I'm just releasing it up cause enough is enough, and hopefully in the next plugdata release we can sync and offer the same version.

As usual, the development pace is always quite busy and I'm just arbitrarily wrapping things up in the middle of adding more and more things that will just have to wait.

First, I had promised support for double precision. I made changes so we can build for it, but it's not really working yet when I uploaded to deken and tested it. So, next time?

And now for the biggest announcement: - I'm finally and officially releasing a new pack as a submodule, which is a set of abstractions inspired by EuroRack Modules, so I'm thinking of VCV like things but into the Pd paradigm. Some similar stuff has been made for Pd over the years, most notably and famously "Automatonism", but I'm really proud of what I'm offering. I'm not trying to pretend Pd is a modular rack and I'm taking advantage of being in Pd. I'm naming this submodule "Modular EuroRacks Dancing Along" (💩 M.E.R.D.A 💩) and I've been working on it for a year and a half now (amongst many other things I do). PlugData has been offering this for a while now, by the way. Not really fully in sync though.

MERDA modules are polyphonic, thanks to multichannel connections introduced in Pd 0.54! There are 20 modules so far and some are quite high level. I'm offering a PLAITS module based on the Mutable Instruments version. I have a 6-Op Phase Modulation module. A "Gendyn" module which is pretty cool. I'm also including an "extra" module that is not really quite a modular thing at all but fits well called "brane", which was a vanilla patch I first wrote like 15 years ago and is a cool granular live sampler and harmonizer. You'll also find the basics, like oscillators, filters, ADSR envelope and stuff I'm still working on. Lastly, a cool thing is that it has a nice presets system that still needs more work but is doing the job so far.

There are ideas and plans to add hundreds more MERDA modules, let's see when and if I can. People can collaborate and help me and create modules that follow the template by the way

Thanks to Tim Schoen, [play.file~] is now a compiled object instead of an abstraction and it supports MP3, FLAC, WAV, AIF, AAC, OGG & OPUS audio file extensions. A new [sfload] object can import these files into arrays (but still needs lots of more work). There are many other player objects in ELSE that can load and play samples but these don't yet support these new formats (hang in there for the next version update).

Tim also worked on new [pdlink] and [pdlink~] objects, which send control and signal data to/from Pd instances, versions and even forks of Pure Data (it's like [send]/[receive] and [send~]/[receive~], all you need is a symbol, no complicated network or OSC configuration!). And yes, it works via UDP between different computers on the same network. And hell yeah, [pdlink~] has multichannel connections support! By the way, you can also communicate to a [pd~] subprocess. This will be part of ELSE and PlugData of course, and will allow easy communication between PlugData and Pd-Vanilla for instance.

The great pd-lib-build system has been replaced for a 'cmake' build process called 'pd.build' by Pierre Guillot. This was supposed to simplify things. Also, the [sfont~] object was a nightmare to build and with several dependencies that was simply hell to manage, now we have a new and much simpler system and NO DEPENDENCIES AT ALL!!! Some very rare file formats with obscure and seldom sound file extensions may not work though... (and I don't care, most and the 'sane' ones will work). The object now also dumps all preset information with a new message and backwards compatibility broke a bit

I'm now back to offering a modified version of [pdlua] as part of ELSE, which has recently seen major upgrades by Tim to support graphics and signals! This is currently needed in ELSE to provide a new version of [circle] that needed to be rewritten in lua so it'd look the same in PlugData. Ideally I'd hope I could only offer compiled GUI objects, but... things are not ideal

The lua loader works by just loading the ELSE library, no need for anything "else". I'm not providing the actual [pdlua] and [pdluax] objects as they are not necessary, and this is basically the only modification. Since PlugData provides support for externals in lua, if you load ELSE you can make use of stuff made for PlugData with lua without the need to install [pdlua] in Pd-Vanilla.

For next, we're working on a [lua] object that will allow inline scripting and will also work for audio signals (again, wait for the next version)! Also for the next version, I'm saving Ben Wesch's nice 3d oscilloscope made in lua (it'll be called [scope3d~]). There's a lot going on with the lua development, which is very exciting.

As for more actual new objects I'm including, we have [vcf2~] and [damp.osc~]. The first is a complex one pole resonant filter that provides a damping oscillation for a ringing time you can set, the next is an oscillator based on it. There's also the new [velvet~] object, a cool and multichannel velvet noise generator that you can also adjust to morph into white noise.

I wasn't able to add multichannel capabilities to many existing objects in ELSE in this one, just a couple of them ([cosine~] and [pimp~]). Total number of objects that are multichannel aware now are: 92! This is almost a third of the number of audio objects in ELSE. I think that a bit over half might be a reasonably desired target. More multichannel support for existing objects to come in the next releases.

Total number of objects in the ELSE library is now 551!

As for the Live Electronics tutorial, as usual, there are new examples for new objects, and I made a good revision of the advanced filter section, where I added many examples to better explain how [slop~] works, with equivalent [fexpr~] implementations.

Total number of examples in the Live Electronics Tutorial is now 528!

There are more details of course, and breaking changes as usual, but these are the highlights! For a full changelog, check https://github.com/porres/pd-else/releases/tag/v.1.0-rc12 (or below at this post).

As mentioned, unfortunately, ELSE RC12 is not yet fully merged, paired up and 100% synced in PlugData. PlugData is now at version 0.9.1, reaching the 1.0 version soon. Since ELSE is currently so tightly synced to the development of PlugData, the idea is to finally offer a final 1.0 version of ELSE when PlugData 1.0 is out. Hence, it's getting closer than ever Hopefully we will have a 100% synced ELSE/PlugData release when 0.9.2 is out (with a RC 13 maybe?).

Please support me on Patreon https://www.patreon.com/porres
You can follow me on instagram as well if you like... I'm always posting Pd development stuff over there https://www.instagram.com/alexandre.torres.porres/

cheers

ps. Binaries for mac/linux/windows are available via deken. I needed help for raspberry pi

CHANGELOG:

LIBRARY:

Breaking changes:

• [oscope~] renamed to [scope~]
• [plaits~] changed inlet order of modulation inputs and some method/flags name. If a MIDI pitch of 0 or less input is given, it becomes a '0hz'.
• [gbman~] changed signal output range, it is now filtered to remove DC and rescaled to a sane -1 to 1 audio range.
• [dust~] and [dust2~] go now up to the sample rate and become white noise (removed restriction that forced actual impulses, that is, no conscutive non zero values)
• [cmul~] object removed (this was only used in the old conv~ abstraction to try and reduce a bit the terrible CPU load)
• [findfile] object removed (use vanilla's [file which] now that it has been updated in Pd 0.55-0)
• [voices] swapped retrig modes 0 and 1, 'voices' renamed to 'n', now it always changes voice number by default as in [poly] (this was already happening unintentionally as a bug when one voice was already taken). The 'split' mode was removed (just use [route], will you?)
• [voices~] was also affected by changes in [voices] of course, such as 'voices' message being renamed to 'n'.
• [sr~]/[nyquist] changed output loading time to 'init' bang
• [sample~] object was significantly redesigned and lots of stuff changed, new messages and flags, added support for 64-bit audio files (Pd 0.55 in double precision and ELSE compiled for 64 bits is required for this). Info outlet now also outputs values for lenght in ms and bit depth.
• [sfont~] uses now a simpler build system and this might not load very very rare and unusual sound formats.

Enhancements/fixes/other changes:

• builds for double precision is now supposedly supported, by the way, the build system was changed from pd-lib-builder to pd.build by Pierre Guillot.
• [play.file~] is now a compiled object instead of an abstraction thanks to Tim Schoen, and it supports MP3, FLAC, WAV, AIF, AAC, OGG & OPUS file extensions.
• Support for double precision compilation was improved and should be working for all objects (not yet providing binaries and fully tested yet by the way).
• The ELSE binary now loads a modified version of [pdlua], but no [pdlua] and [pdluax] objects are provided.
• added signal to 2nd inlet of [rm~].
• fixed 'glide' message for [mono~].
• fixed [voices] consistency check bug in rightmost outlet and other minor bugs, added flags for 'n', 'steal' and offset.
• [gain~] and [gain2~] changed learn/forget shortcut
• [knob] fixed sending messages to 'empty' when it shouldn't, ignore nan/inf, prevent a tcl/tk error if lower and upper values are the same; added "learn/forget" messages and shortcut for a midi learn mechanism.
• [mpe.in] now outputs port number and you can select which port to listen to.
• Other MIDI in objects now deal with port number encoded to channel as native Pd objects. Objects affected are [midi.learn], [midi.in], [note.in], [ctl.in], [bend.in], [pgm.in], [touch.in] and [ptouch.in].
• [pi]/[e] now takes a value name argument.
• [sr~]/[nyquist~] take clicks now and a value name argument.
• fixed phase modulation issues with [impulse~] and [pimp~].
• [cosine~] fixed sync input.
• added multichannel features to [cosine~] and [pimp~].
• [plaits~] added a new 'transp' message and a functionality to allow MIDI input to supersede signal connections (needed for the 'merda' version [see below]), fixed MIDI velocity.
• [pluck~] added a new functionality to allow MIDI input to supersede signal connections (needed for the 'merda' version [see below]).
• 26 new objects, [velvet~], [vcf2~], [damp.osc~], [sfload], [pdlink] and [pdlink~], plus abstractions from a newly included submodule called "Modular Euro Racks Dancing Along" (M.E.R.D.A)! Warning, this is all just very very experimental still, the object are: [adsr.m~], [brane.m~], [chorus.m~], [delay.m~], [drive.m~], [flanger.m~], [gendyn.m~], [lfo.m~], [phaser.m~], [plaits.m~], [plate.rev.m~], [pluck.m~], [pm6.m~], [presets.m], [rm.m~], [seq8.m~], [sig.m~], [vca.m~], [vcf.m~] and [vco.m~] (6 of these are multichannel aware).

Objects count: total of 551 (307 signal objects [92 of which are MC aware] and 244 control objects)!

• 311 coded objects (203 signal objects / 108 control objects
• 240 abstractions (104 signal objects / 136 control objects)

TUTORIAL:

• New examples and revisions to add the new objects, features and breaking changes in ELSE.
• Added a couple of examples for network communication via FUDI and [pdlink]/[pdlink~]
• Section 36-Filters(Advanced) revised, added more examples and details on how [slop~] works.
• Total number of examples is now 528!

@nicnut [osc~] is equivalent to [phasor~]->[cos~] (and there's no way to mix my way with your way as far as I know), but you're enforcing sync on the positive zero crossing of the base freq oscillator, and my way syncs on 1 (i.e. the start of the cosine cycle). You can shift the phase of my scheme to be equivalent to yours by subtracting 0.25 from the base phasor, thereby making the output of the following cos~ a sine wave filtermodwrap.pd. To my ear, this sounds the same as yours.

But in the title of your thread, you asked how to make all the oscillator's positive zero crossings line up with that of the base freq oscillator. If that's really what you want, then you should shift all the oscillator's phases (filtermodwrap.pd ),

Edit: this used to be much more of a stream-of-consciousness mess, but I saw you hadn't logged on in a while so I took the liberty to revise what I wrote to make it clearer. Ha, and now I see we cross-posted, oh well.

Here's an updated version of the pole-zero diagram I posted two years ago:

pole-zero-diagram-2.0.pd

Unfortunately, I didn't know about ELSE back then. As you probably know, it has frequency response and pole-zero plots as well, and there's also a section about the Z-plane in the wonderful live-electronics tutorial. In fact, these are the main reasons, why I decided to update my patch.

So the new version of my pole-zero diagram has two additional features: First, you can now switch between linear and logarithmic scaling of both amplitude and frequency, and second, I added some examples of standard filter types, so that you can also see the effect of changing a filter's parameters on the positions of its poles and zeros.

I hope this may be helpful for some of you. If something's wrong with the patch or the filter examples, please tell me!

@jameslo said:

if we stipulate that people can't hear the relative phases of harmonics, then shouldn't there be some arrangement of a given tone's harmonic's phases such that the DC component is maximal

This actually isn't true. The integral of a sine wave is always 0. The sum of the integrals of multiple sinusoidal components, then, must also be zero.

If you have extremely low frequency components, like 1/10 Hz, then at any given moment, that component's contribution in the short term may resemble DC and may be just as harmful to speakers as DC. But this isn't a harmonic component of a tone whose fundamental is audible, so it's not properly part of the "tone" that you mentioned.

True DC must have frequency = 0, which isn't a harmonic of anything (but which is necessary in Fourier analysis to account for an average offset away from the zero line).

That's interesting about the warble tones as beating, like an amplitude modulation artefact. EDIT: I'm having trouble, actually, finding a consistent definition of "warble tones." Some sources refer to frequency modulation, while others say it's amplitude modulation consistent with oid's post. That's not making it easier to evaluate the claims.

hjh

I was just experimenting with the “classic” feedback FM and stumbled on a related technique that seems quite interesting to me, especially because of its chaotic behavior. It’s actually very simple: The output of an oscillator is delayed and, scaled by some factor, fed back into that same oscillator as its frequency. So there is no external input, no carrier frequency (or a zero carrier frequency if you will), which means that it is a symmetric “through-zero” FM.

feedback-oscillator.pd

By guessing I figured out how the delay time determines the frequency of the oscillator, but I still don’t understand a few things: Why is there a factor of 4 involved so that the delay is one quarter of a cycle? And why is there still some error? I found two ways to fix it, first by oversampling and second by reducing the delay time by the duration of one half sample. To be honest I don’t have a clue why this works ... Any ideas?

What I find particularly interesting is the path from sinusoidal tones at modulation index 1 (which seems to be a critical value) to different modes of periodic oscillation and finally to chaos when the modulation index is increased: First odd harmonics are added, then even harmonics, then a period doubling or “bifurcation” occurs, and shortly after that we get into the chaotic region. This seems to be not too different from the logistic map or related chaotic maps. So I’m wondering if it’s possible to analyze the oscillator in terms of chaos theory to better understand and control its behavior.

Apart from being mathematically interesting, I think this could also be a usable noise generator with spectral control. Other effects can be achieved by adding an external input ... but for now, I’m more interested in understanding that simpler case.

@Dizzy-Dizzy You get clicks because the first or last sample is not zero.....so when you play the file the audio suddenly jumps from zero to some value for the first sample...... same at the end.
You can duck the audio...... take the volume down to zero smoothly at the end before you stop writing, and bring the volume up from zero after you start writing.
Put a [vline~] into the right inlet of [*~ 2] and bang messages into the [vline~] to do that...... after you start writing and before you stop writing.
[0, 2 3 0( at the start and [0 3( at the end should do the job..... a 3msec fade in/fade out.
You will need to delay the [stop( message to [writesf~] so that the volume has come down to zero before it stops writing.
David.

Hello,
I am new to puredata, just started very recently and still learning how the language works.
I created a minimoog style oscillator where I can change certain parameters like: waveform, fine tuning, panning, volume. This file I named oscillator.pd, after which I created a "synth.pd" file that basically uses two "oscillator.pd" as an abstraction.
The problem is the following: when I modify one oscillator it also modifies the other, so I can't use them separately but it's as if they are linked together.

I attach the files, thanks in advance for the help!

synth.pd pan.pd oscillator.pd

Agustin Davrieux