Thanks erikd.

I'm a little troubled by not being able to find anything similar that anyone else has done - it seems like such an obvious thing to do that its absence makes me wonder if there's some good reason why it won't work right...!

Hello,

 Does anyone have any experience with visualising sounds based on microphone input (or CDs, or whatever), preferably in an applet? I'm just trying to figure out where to start, really. It doesn't need to do anything complicated in terms of analysing the signal, I mostly just want to grab bits of the waveform and use them to make a display. I might also want to do something with the overall volume of the incoming sound.

 I thought I'd surely be able to find some sample code somewhere to get an idea how it can work, but I can't seem to find anything remotely similar! This may be because I'm being dense, I just don't know.

 Anyway - any thoughts or helpful links would be much appreciated - I'm okay for general-purpose documentation of Java Sound, I just have nothing about using sound to make anything besides more sound!

 Is Java Sound pretty much my only option for this, without expecting my visitors to download a plugin? I will soon be wanting to output sound, as well, if that makes a difference.

Cheers

 - f.

I should have specified that I only get this weird behaviour for the settings where super.paintComponent doesn't get called - that is, it's fine except for the 'with trails' settings (in the 'history' menu). Does it still seem okay on the Mac?

I am realising that Swing implementations are not quite as consistent as I had been led to believe, in any case... :/

Harrum... well, I did some more re-reading, and thought maybe overriding the method so that it does nothing but call would help... and it kinda does, except that I now get any Swing component I interact with drawn in the top left-hand corner of the drawing area.

What?!

Here's a link to the weirdly broken version of the applet , so you can see what I'm talking about. The GUI is supposed to be in a separate JPanel from the drawing, in the east border of the main contentPane...

Thanks - I think I read the tutorial you're talking about, which is probably one of the places I got the idea that overriding paintComponent without super.paintComponent in it ought to do the trick - it suggests calling the super version to clear the component, but in practice it still seems to get cleared even when you don't. I was surprised that setDoubleBuffered(false) doesn't seem to help either. :-/

I'll try re-reading the java docs for that, anyway, maybe I missed something... cheers!

Before I go ahead and implement this - is there really no way to convince Java to just not clear my JPanel? I used to use that strategy to avoid significant amounts of processor use when double-buffering really wasn't necessary and I wanted to leave trails. Granted, not so many people have processors slow enough for it make an enormous difference these days, but still...

(I thought from what I'd read that simply not calling super.paintComponent() from my paintComponent() method would do it, but no, and neither does turning double-buffering off...    )