@Ale-H.H. OK....... You are going to have to trust me on this.
This took about an hour to build........ but you can now expand it in seconds.
Abstractions are a powerful tool......... but to build them you need to understand the use of variables ($0 $1 $2......etc.)..
NEW2.zip

PLEASE NOTE>>!!
Any abstraction can be copied and pasted......... .So if you want more oscillators within a [voice_gen] just copy/paste a [part_voice] within a [voice_gen] and give it a new number [part_voice $1 "x"]...... Change the pasted one's Name to [part_voice $1 "new voice number").......
It will need a timbre curve as well.... so open the relevant [timbre_gen"y"] and put a new [part_timbre $1 $2 "x"] make a new volume curve $1-$2-x by copy/pasting an existing one...draw a new curve....... and save the main [voice_gen] abstraction once you are happy.

BEWARE>>!!
1..... the [timbre_gen"x"] need to be saved individually because they contain the timbre sub-curves. They cannot be used as true abstractions (they must have separate names). If you decide you want a new timbre curve for something then copy and paste an old [timbre_gen"x"], changing its name........ then change the sub-curves and re-save the file.
((this could be done better by writing data out to text files, but I don't have the time now to implement that..... this solution works.......))
2.... If you add more oscillators to a voice then you will end up with some producing ultra-sonics. If you will need to specify some new relationship between the oscillators (other than x2,x3 etc. you can do that by changing the 2nd argument for the oscillators.... i.e. [part_voice $1 0.5] etc.
Don't forget to put the "0.5" in a corresponding [part_timbre] and it's graph....!

HOWEVER>>!!
I cannot help you to do this without abstractions..... it would be too difficult and too messy.
You are absolutely going to have to understand them for a project like this that is going to become very complex very fast.
See here for some help........ https://forum.pdpatchrepo.info/topic/9774/pure-data-noob/4
You will not have wasted your time.
The future benefit will be enormous...... as any sudden new idea for your patch can be working 100% just a few minutes later!.

You should probably print this post before you start playing with the patch.
And please do not despair.
You will, probably after a good nights sleep, have a $ eureka moment...... and from then on you will find patching in Pd as easy as Pi....... or is that Pie?.....

New2.zip should be working...... there is nothing clever or unusual.
I might not get time to help for a couple of days. If I get time to integrate a state saving system then I will integrate each [part_timbre] into each [part_voice] and the patching will become even easier.
You have 2 days to get familiar with this way of working...........
David.

@Ale-H.H. I am out tonight..... so no help I'm afraid.
I start to understand.
You can assign curves to what you wish....... so?

Anyway.... the last patch allows you to draw curves for each oscillator controlled by just one iaanix timbre curve.
You just have to decide how each oscillator should respond to that curve to create the timbre.
If you want the first oscillator volume to simply follow the iaanix curve then draw a line in "a" from bottom left to top right.
If you want the last oscillator to do the inverse then draw in "h" a straight line from top left to bottom right.
If you want the second oscillator volume to rise quickly as the iannix curve goes to 0.5 and then fall back to zero as the iannix curve reaches 1 then draw a triangle in "b"

I hope that makes sense.
David.

@katz

Thanks!
Indeed, using separate tables is the way to go here since the audio math is way too heavy for my computer for a patch with 4 voices and 3 operators per voice. Maybe there was an advantage on the 80's hardware, but definitely not here.

I have no way of knowing whether they are accurate either since all I've got is that picture, but I'm not going for an historic recreation of any of those synths. I just wanted to have something else other than sine, and those looked like a good place to start.

In fact, I've tried using those casio cz oscillators too (https://forum.pdpatchrepo.info/topic/5992/casio-cz-oscillators) in this context and they sound interesting. Here you basically have your waveforms modulating the phase of the cz waveforms before the phase distortion happens.

tx-wavs_cz-wavs.pd

Thanks for your help, I hope to be able to post the whole thing soon.

on a sidenote: on vanilla 0.47.1 I can't create [asin], but have got it to work with [expr asin($f1)], not sure why.

Ok, so I did a bit of looking through my patches and I think the culprit is the delay method I'm using. I also tried to mess around with changing the phase of the oscilators so that when they are on 0Hz they dont have any amplitude but I'm not sure how successful that was.

Here is the Delay patch:
Delay.pd

And the Audio-Out patch I am using:
Audio-Out.pd

And for good measure the Oscilator:
Oscilator.pd

Thanks!

Hi, I am wondering if it is possible to create an additive synthesiser for a verbos harmonic oscillator: https://static1.squarespace.com/static/52cddaa9e4b0999c86f84b8a/t/56145344e4b0e58796be4889/1444172612979/harmonic+oscillator+postcard.pdf

There are two parts to it, namely the oscillator core and the harmonic mixer. For the oscillator core, it has to output saw, square and triangle waves. How do I do that in pd?

Hello,
Below are links to the first alpha release of the GUI port of Pd-l2ork.

The GUI has been ported from tcl/tk to nw.js. The biggest visual improvements are ability to zoom in and out of a canvas, smoother animation of canvas objects (like the PacData game), user-friendly editing inside msg/obj boxes, and a more flexible API for visualizing data structures.

I've nicknamed it "Purr Data", because cats.

This is mainly a bug-collecting release. It should be decent enough to do some basic patching for awhile before hitting a bug. Some caveats up front: OSX is missing Gem and PDP, and both OSX and Windows are missing some pd-l2ork-related externals.

Bug tracker is here:
https://puredata.osuosl.org/jwilkes/purr-data/issues

Alpha builds are listed below (I'm abusing gitlab to distribute these, so some may have a zip within a zip):
OSX x_64 - https://puredata.osuosl.org/purr-data-binaries/osx-64-alpha0/repository/archive.zip?ref=master

Ubuntu 15.10 x_64 - https://puredata.osuosl.org/purr-data-binaries/ubuntu-15.10-64-alpha0/repository/archive.zip?ref=master

Ubuntu 14.04 x_64 - https://puredata.osuosl.org/purr-data-binaries/ubuntu-14.04-64-alpha0/repository/archive.zip?ref=master

Ubuntu 14.04 i386 - https://puredata.osuosl.org/purr-data-binaries/ubuntu-14.04-32-alpha0/repository/archive.zip?ref=master

Debian Jessie x_64 - https://puredata.osuosl.org/purr-data-binaries/debian-jessie64-alpha0/repository/archive.zip?ref=master

Debian Jessie i386 - https://puredata.osuosl.org/purr-data-binaries/debian-jessie32-alpha0/repository/archive.zip?ref=master

Windows 32-bit - https://puredata.osuosl.org/purr-data-binaries/win32-alpha0/repository/archive.zip?ref=master

I dont print to the output, I route it to drive an oscillator (and for debugging purposes to num boxes)

Ive got an external audio interface, a saffire pro 14, and that seems to be working fine, and as mentioned, there is no evidence of cpu load... and the audio is glitch free... its just the messages not being processed quickly

as you can see the basic function (for testing) is to drive an oscillators frequency, and mix in another parameter to get the volume (gain)

a few notes:

• Ive tested without the num boxes etc, i.e. just the oscillator and the issue is the same.
• its the same with only one half i.e. one udpreceive 'tree' and its the same

unfortunately, you can't test as such without the relevant controller and application to send the messages.

I'll try netreceive... perhaps that will help.
EDIT: nope, netreceive has exactly the same issue.
EDIT: oops, noticed the 9002 tree, i went via the num boxes to oscillator/gain, but taking directly from the unpack, still has no change

mectest.pd

Thanks.

Here it is. Kind of a messy patch: I use two screens. There are way too many oscillators. It sounds crazy because the block size is set up for visuals and ruins the audio. My favorite idea was using video effects in a feedback chain on the audio. So pix_convolve is messing with the oscillators.

I find that when the oscillators are very close to an exact multiple of the sample-rate divided by the block size (or something like that, idk), it looks & sounds cool. I have yet to try new waveforms with filters. I think that would be cool to modulate a filter on a square-wave that's tuned to the block-size.

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

Well, the result of that would be equatable to

[phasor 880]
|
[*0.5]

The catch with the sync is that there's basically always a more efficient alternative.

If you want a construct that's equatable to
bang X frequency X times a second

you could use phase-sync.mmb.pd and add two frequency controls that calculate the ratio between the two. Then feed the phasor~ with the first frequency and send the ratio to the *~

so

frequency 1 = 440
frequency 2 = 880

440/880 = 0.5

send frequency 2 to [phasor~] and 0.5 to [*~]

like above

you don't lose anything by driving this construct with control messages or with audio rate control. The considerations are only superficially different than using bang.

It's been a while since I've looked at phase-sync.mmb.pd, so it might do this already.

If you're interested in using sync as an oscillator feature,

if you can understand this, I personally can't digest it:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.65.1036&rep=rep1&type=pdf

otherwise, casio-style is handy:
http://en.wikipedia.org/wiki/File:Casio.CZ101.resonance.png

and if you're okay with the licencing implications, there are objects in extended that offer competent band limited sync. I forget the name, but the group that I'm thinking of has sync saw and a band limited comparator for PWM and square sync.

Basically you want to create an oscillator (bandlimited) then feed that through a resonant filter, then to your speakers.
Bear in mind lop~ isn't resonant, other people have created externals that are, or there is the moog~, although this will sound nothing like the monotron filter, from what I remember Korgs might be 12dB/octave (might be wrong!). Good luck in designing your own Analogue modeling filter, I tried and it was solid!

To replicate the monotron ribbon controller, it's probably simplest to control the frequency of the oscillator
create another oscillator (a simple sine wave), this will be your LFO. connect that up to either filter cutoff or amplitude
Amplitude would require you to multiply the output of your main oscillator by the output of LFO
Cutoff would mean multiplying the LFO output by The value you are inputting into your filter cutoff input.
You could incorporate a button switch so you could flick between them like the monotron

It is a very simple synth to emulate, I recommend reading this site to explain the basics of subtractive synthesis in PD , it also mentions bandlimited oscillators, which will stop them aliasing THIS IS VERY IMPORTANT!

http://en.flossmanuals.net/pure-data

A guy from this forum also wrote this site
http://obiwannabe.co.uk/html/music/6SS/six-simple-synthesisers.html

You will soon grow bored of replicating the monotron, and move into doing minimoog replications, and maybe even modular stuff.
I saw a video of someone who did a Swarmatron replication, very impressive. Wish I had that patch...