Java Theremin

[philfrei]

I made some changes, putting items in arrays via overwriting rather than via adding and dropping objects. After doing so, I was able to lower the latency from 4096 to 1536 samples. (An improvement--but still a ways to go to reach 600.) Below that, I'm getting a slight sfzt sound at the start. At least, the echo and its length are no longer an issue.

With a 1024 sample buffer the sfzt start is pretty prominent, but other than that, the JTheremin runs fine. So I'm assuming there is something about how I start up the sound that needs improving more than anything else.

Neil, the routine which receives from the GUI (RTESmoother) only gets a double. It then adds a time stamp. [Hmmm. Maybe it would be more correct to issue the time stamp immediately and pass it in as a second parameter.] What I've done is to get rid of the LinkedBlockingQueue and put in two arrays, one a double[] for the GUI values and the other a long[] for the time stamps. The add() method and the block of code where the value is read are both enclosed by a "lock" Object and synchronized. Neither occur very often relative to how short they both are, so I think this should be okay.

I KNOW the GUI add() calls are not causing the starting sfzt via blocking, because I can prevent any add() calls, and the sfzt still is audible, is unchanged.

I'll post the "improved" RTESmoother one its thread in the "Shared Code" area, for the curious.

You echo code looks interesting. I can't totally imagine how it sounds (I'm not the best at reading code) but I see the interpolation happening.

I had this idea for an echo array that allows detuning the echo: let the "read-head" progress incrementally by 1's, but allow the "write-head" to lag behind by a variable increment. One can hold onto the previous write value and its location and the current write value and its location, and interpolate to post into all the intervening array slots.

I suppose this could be combined with a read-head that can progress a varying amount as well. Not sure what one gains that way, though. Seems like one can do one or the other, no need to do both. I can get my head around the varying write-head model a little easier than a varying read/write-head. (Dating myself, using a tape deck metaphor?)

I remember once using a digital echo VST that allows pitch-bending, but it was written in C++ I'm pretty sure. I can't recall what I did with it though, and I miss the effect. My analog units are rather noisy and colored. So I'm pretty motivated to make one for myself. Another good learning project. Whoopee!

[nsigma]

With a 1024 sample buffer the sfzt start is pretty prominent, but other than that, the JTheremin runs fine. So I'm assuming there is something about how I start up the sound that needs improving more than anything else.

Are you starting the line each time the sound starts?  You'd be better holding the line open and writing silence to it.

Neil, the routine which receives from the GUI (RTESmoother) only gets a double. It then adds a time stamp. [Hmmm. Maybe it would be more correct to issue the time stamp immediately and pass it in as a second parameter.] What I've done is to get rid of the LinkedBlockingQueue and put in two arrays, one a double[] for the GUI values and the other a long[] for the time stamps. The add() method and the block of code where the value is read are both enclosed by a "lock" Object and synchronized. Neither occur very often relative to how short they both are, so I think this should be okay.

I owe you a big thank-you here, as you've inadvertently pointed me to a bug I introduced in refactoring Praxis a while back.  I was about to write and tell you that you've probably made this slower by adding in a lock, but actually to be lock-free you should have been using ConcurrentLinkedQueue and not LinkedBlockingQueue anyway.  I'm always getting those two mixed up for some reason.  You could try the previous code you had with a ConcurrentLinkedQueue and see what the performance is like then - locking is possibly more than the object overhead here.

EDIT: Actually, scratch the previous paragraph.  Looking again at LinkedBlockingQueue it uses two locks - put and take.  There shouldn't be much thread contention at all, so it is likely to be better than the locking strategy you just implemented.

I think there's a subtle bug in your code as well (though I'm no good at reading code either!   ) in that you should poll() the queue in a while loop to ensure it's drained on each tick - not that it's likely to get swamped by the GUI.

I had this idea for an echo array that allows detuning the echo: let the "read-head" progress incrementally by 1's, but allow the "write-head" to lag behind by a variable increment. One can hold onto the previous write value and its location and the current write value and its location, and interpolate to post into all the intervening array slots.

I suppose this could be combined with a read-head that can progress a varying amount as well. Not sure what one gains that way, though. Seems like one can do one or the other, no need to do both. I can get my head around the varying write-head model a little easier than a varying read/write-head. (Dating myself, using a tape deck metaphor?)

I think it's better to let the write-head progress normally (by 1) and let the read-head read from a variable moment back in time.  This is closer to an actual tape-delay, I think.  The write-head is recording the present and the read-head is playing back some moment in the past.

PS. I'm old enough to be perfectly happy with the tape-deck metaphor.  

[fruitmaze]

Thats awesome! Works really nice and fun to play with. Are you planning on using this in another project, like a game or something else?

Games published by our own members! Check 'em out!

[davedes]

The echo effect is really cool, but it stops as soon as you let go of the mouse.

[philfrei]

@davedes

The echo effect is really cool, but it stops as soon as you let go of the mouse. Sad

Mickelukas had the same suggestion, and I agree that would be nice to have. I am thinking I will try and implement Neil's suggestion to keep the Theremin "running" but silent even if the mouse is released, and include that feature then as well as some sort of volume ratio or independence between the source and the echo.

Maybe the mouse position should drive the overall echo volume even when the mouse is up.
Or the echo setting could be static, on the control panel, rather than tracking the mouse.

@fruitmaze

Thats awesome! Works really nice and fun to play with. Are you planning on using this in another project, like a game or something else?

Thanks! Yes in terms of using it in "another project" but I don't have any concrete plans yet. Any suggestions?

I'm still in the learning-project stage. Right now, I'm working on another sound app for a friend for a few days, that plays a "tree" of sine waves, where I am learning about how to create and use envelopes (got a simple Attack-Release working so far), and about using a JTable in the GUI for holding/editing the info used to configure the sines. Am very pleased that I figured out how to play multiple sine waves all from the same WaveTable.

On the queue for the Theremin: vibrato. Which as a learning-project means I get to implement a bit of FM! (FM is my main synth, via DX-7 and Native Instruments FM7 [FM8 if I upgrade]. I've done a lot of high level FM programming (musician user level).)

Also on wish list: ability to record, save & playback the data currently generated by the GUI, as this is much lighter than raw audio.

Also on wish list: implement a filter to get rid of the aliasing! I think if you go down SteveShannon's links below you will find a demo where you can hear how important that is.

Also on wish list: have this light and fast enough that it can be used/integrated into a game as a SF/X source, for example, with tracking the motions of some object moving on a display. The results could be more varied and expressive of game action, potentially, than canned sounds, if done right. Though at the moment, the simplest (conceptually) would be if you had a use for a slide-whistle or trombone slide that could be tied to game state, or game events.

But there is also the potential for some nice, sinister "industrial" background sounds that have more expressive variability than a prerecorded loop. Try this:
     100% Sawtooth
     Lowest possible pitch setting
     99% Echo feedback
     Echo delay setting in the range 10msec to 50msec.
This could be very cool if variable echo delay rates get programmed.

[philfrei]

Turned out to be really simple to make the Echo continue independently of the Theremin volume.
Done.
Everything still goes silent if you let go of the mouse. But if you drop down to the volume floor, the Theremin is silent, but the echo (assuming it is on, of course) will linger.

[fruitmaze]

@fruitmaze

Thats awesome! Works really nice and fun to play with. Are you planning on using this in another project, like a game or something else?

Thanks! Yes in terms of using it in "another project" but I don't have any concrete plans yet. Any suggestions?


Well as a game maybe something surrealistic and atmospheric, thats the feeling I get when I hear the sounds. Or a game about a bee Another idea could be to combine graphics and sound, like when you move the mouse to create different sounds the background changes as well.