I'm creating a library for real time sound synthesis. It can help keeping your distribution size down and you will be able to alter everything at real time so you can create sound effects just like in the old days :-)

Currently it supports the following features:- Tone generator capable of playing sinus, sawtooth, triangle and square waves or user wave tables.Supports pulse width modulation.- White noise generator- Low pass filter with resonance.- Envelope generator (with attack, decay, sustain, release).- Mixer with unlimited inputs.- Amplifier/Attenuator- Panning- Internal processing using floats for huge signal-noise ratio and head room.- Sample recorder for creating samples from your generated sounds.- Modular design: you can patch everything any way you want.- Play back using javax.sound.- Easy to understand API.

I'm planning to create more modules such as LFO, Ring Modulator, FM, HPF, BPF etc. and some effects like chorus, phaser, reverb and such. Maybe I could even add some sort of sequencer.OpenAL using LWJGL will also be supported (JOAL support will probably just be trivial to add as well).Maybe I'll also add some sort of import of patches using XML.Well, anything I can think of I feel like adding will be there ;-)

It's not finished although all currently supported features do work. If anybody wants to give it a go, just mail me and I'll send it to you.

But really, there's no reason to give up on MIDI. A good MIDI sequencer is so much better and versatile than 'trackers' (and MIDI files are usually a lot smaller since there's usually no sound data in it).

I used to process little buffers of 32 samples. This was because I eventually need to send a buffer of a given size to the soundcard to play, so I thought I'd just create those buffers and mix, filter etc along the way and finally send the same buffer (after converting it to bytes) to the sound card.Every 32 samples (or whatever you set the buffer size), the controllers (Volume settings of tone generators, Envelopes etc.) were updated (adding a tiny bit of 'zipper noise' in the process).

Bad Idea :-/

In the process I created unneeded overhead, because of all the arrays everywhere. Java's bounds checks do take a performance hit (in the client anyway). The need to copy arrays in certain places (in panning for example which has to split a mono signal to stereo) doesn't help there either.Also the API became a little bit more complex than needed because I had to have AudioInput/AudioOutput interfaces (writing arrays) and ControlInput/ControlOutput interfaces (those not being compatible of course, Controls write just a float).

So, I got rid of all those little arrays and now have only arrays where absolutely needed (sending samples to the sound card, getting sound from the sound card etc).And, I can get rid of the control interfaces, because there's now just one type of signal that can be used for both audio and controllers, which means more flexibility in the connections you can make.

It sounds from the above that you are running control signals at the audio rate.

You might want to have a look at SuperCollider for ideas. SuperCollider has a separate audio rate and control rate. Control rate changes are interpolated at the audio rate to remove zipper artifacts..

I've not had the chance to dig into your project yet, but that might be something to look into if possible..

Yes, I am running control signals at the audio rate now. I did think about interpolation (I used to have some interpolation here and there; there's still an interpolator class which I used previously), but I think I'm going to keep it this way for a while. Control signals are most of the time cheap operations anyway (not much more expensive than interpolation I guess), and getting rid of the separation between controls and audio gains so much more flexibility and simplicity... I get to delete some classes, *and* get a more powerful api at the same time

But let's see how it turns out. Maybe I'll have to make some changes in controls again later, *if* control signals turn out to be a performance bottleneck. But then I think I would change something in the implementations of some controllers to speed them up, not the interfaces / API design.

A little web started demo with some sliders to play with.When you get distorted sound, turn down the 'gain' a little.I noticed that in this demo I *sometimes* get an ArrayOutOfBoundsException in an oscillator. Which should never happen, according to the code. Maybe some threading issue or something :-/

Yeah.. the demo is cool.. Keep it going.. Make sure that you can construct patches programmatically!

All of my GUI work with Scream should work great with your project. Plus eventually you might consider using OSC, Open Sound Control, to get your synth running via the network; Scream already has a client based OSC framework; I'll be extending it with server capability after J1; should be as easy as defining a protocol for your synth and interfacing with Scream...

I tipped off someone who might be interested in contributing to your project.. So who knows... Have you made a web page for it yet?

All of my GUI work with Scream should work great with your project. Plus eventually you might consider using OSC, Open Sound Control, to get your synth running via the network; Scream already has a client based OSC framework; I'll be extending it with server capability after J1; should be as easy as defining a protocol for your synth and interfacing with Scream...

Scream looks fantastic. Is OSC a java framework?

Quote

I tipped off someone who might be interested in contributing to your project.. So who knows... Have you made a web page for it yet?

No web page yet. I'm thinking about either a sourceforge.net project or a java.net project.

Checking into OSC will give you an idea about being able to configure your synth programmatically.

The audio engine I am using, SuperCollider3, which is covered in the OSC PDF can only be addressed via OSC.

The goal of a programmatic interface is language independence. I am able to fully configure and control SuperCollider3 from Java over the network.

Essentially, it would be awesome to have an interface that exposes the functionality of your synthesis system without having to know the implementation details.

The example you listed of being able to connect your synth is programmatic, but still tied more to OO programming than a generic interface. For instance you will probably want to break down your Oscillator class to particular implementation SinOscillator, SawOscillator, etc.

Spending time to review SuperCollider3 could be very beneficial in gaining some ideas on your project. SC3 is under GPL, but you should be able to convert the code for basic unit generators (oscillators, filters, etc.) to Java and not break GPL... I'd like to see your synth be released under BSD if possible.

I'd be glad to continue discussing all of this.. Time permitting I would also like to help out with implementation.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org