Hi, I'm a long-time Reaper user but have never coded...so a total JS newbie. I have an interest in pure waveforms, related to psychoacoustics, and have used Adobe Audition's Generate Tones function for years. Generate Tones is limited, but it's very precise, and can use multiple oscillators. I want to move those features into Reaper, to able to use them in real-time and to automate all parameters from a single plugin. AA's Generate Tones is basically a rendering engine and I've reached the limits of that. I built a simple equivalent in MaxMSP - that seemed quite trivial to do, but I need to be in a timeline-based DAW. I've done some little hacks to the JS synthesis/tonegenerator and the ones by Tale, to try to see how JS oscillators work. But can anyone steer me a bit, as to how to make such JS tonegens multiple-oscillator? Do I just copy-paste existing code and rename variables as I go, and then make some sort of mixer, or is there a more elegant route? I don't need any MIDI, so no classic poly synth stuff or envelopes or filters etc, just an expanded test-tone concept. Thanks

I don't have vast experience with js, but the namespace objects work nicely so far. I like em. Haven't looked at oscillator code but I would try to make an oscillator object then use however many are needed. For mixing, assuming an oscillator object-- For instance 4 oscillators, you could do something like this though perhaps another approach would be more elegant-- The OscSetFreq(), OscSetPhase(), OscSetAmp() are broken out from OscInit() so that when you first initialize an oscillator, it will call all those for you, but if you want to sweep freq, phase or amplitude during runtime, you can call the individual functions once everything else has been set up ready to run in the OscInit() call. In other words, the OscSetFreq() function would only have to do whatever is necessary to change the frequency, assuming that everything else that the oscillator depends on, has already been set up. So you would want to configure the initialization calling sequence so that each function has anything it needs already set up before getting called. For instance the OscInit() sets its self.samprate before calling OscSetFreq(). Sometimes the order of initialization could be confusing enough that maybe you would want to duplicate some of the init code both in the init call and also in a setter call. Just to make sure there are no train wrecks. The self.blahblah are variables private to each instance. So if you call osc_0.OscInit(100...) and also osc_1.OscInit(200...), then each one has its own private copies of self.frequency or self.phase, etc. osc_0.frequency happens to be 100 and osc_1.frequency happens to be 200. So the code in OscDoTick() runs at 100 Hz for osc_0 but the same code runs at 200 Hz for osc_1. Code:

Tale made a colored noise plugin which I use constantly. He also has both LFO and poly_blep generators. Otherwise it looks like you have the basic idea for the object and helper functions. The hard part is writing oscillator code that sounds good and doesn't alias all over the place (i.e. "naive" methods). One way to reduce aliasing is to use a method like polyBLEP, of course others exist. There is both a discussion here and on the KVR developer's forum about fast sine approximations, there's always wavetables, and of course Google is your friend.

Hi klangtest I've used CoolEditPro/Audition generate tones for many years but almost always sine waves, and occasional rare need for square waves. I narrow-mindedly assumed you wanted sines merely because that is what I mostly used. What kind of waveshapes do you need?

In CEP/AA Generate Tones I began with pure sines, to explore beats and spatial movement via channel phase difference. Later I used the sine "flavors", ie sine squared and root sine, and the fact you could set different start and end states for these. Ditto for the square-pulse and the saw-triangle pairs. They are genuine waveform morphs, not crossfades, Tale has coded similar in poly_blep and I want to access those. Morphing from symmetric to asymmetric waveform makes the overtones dynamic and interesting, especially when you modulate the results. The most useful VST I've been using is the Melda MOscillator, very versatile, but a single oscillator and not quite as precise as what I can see within JSFX. Pre-DSP, people like Alvin Lucier, La Monte Young, Eliane Radigue and others have done great work with hardware oscillators - and without keyboard input, so away from keyboard-based temperament. Radigue had the ARP2500 to work with, unlike most of us ;) I know you can do most all of this in MaxMSP, but it's the timeline and realtime automation control of a DAW that makes JSFX tone generation interesting in Reaper, from my sound design POV. I just have to get the math together...

It was a long time since I coded any oscillators. Usually it was not for direct musical use. For instance generate reference pitches for "by ear" instrument tuning or generate test tones for filter or re-sampling testing. This could be wrong, but I suspect a sine wave will be easiest to generate with low aliasing and low distortion. It is easy to get surprised that things are trickier than first imagined, so possibly even sine generation could have difficulties once one gets into it. But a low-distortion sine would only have one frequency and ought to be alias-free so long as its frequency is lower than half the samplerate (nyquist). Was just thinking, maybe the easiest way to get started would be a sine oscillator object, and then experiment with code to control the multiple oscillators the way you desire. After that is working as a test-bed, you could work on new oscillator objects, or enhanced osc objects which have different waveforms or waveshape control features. Once your sine wave test bed is working, you wouldn't have to worry about the test bed part of the program while refining low-distortion, low-alias behavior with other wave shapes. Here is a possible low-distortion sine oscillator code but it would run fairly slow. Possibly even this would run "fast enough" for dedicated experiments where the jsfx doesn't have to run fast enough to keep up with a high-track sequence with lots of plugins. It is written hopefully for clarity rather than speed. Code:

Ok jcjr, great, thanks for all this, I'm beginning to see daylight, slowly! - I'm away now for the month, will pick it up when I get back. Between what you've explained and studying Tale's poly_blep code I've got a lot to work with now.