Krodal:
(1) The code increased a little (just a little) which is always a problem for the ATmega8
Great pains have been taken to keep the code as small as possible. I'm a huge believer in running as much as possible in the background so around 150 additional bytes I believe are important. It's still much smaller than the tone library. I show the Arduino Uno code to be 1604 bytes with Arduino v1.0.2 not 1670. And with the ATmega8 I have it as 1398 instead of 1472 (again v1.0.2). As a test I created a toneACmini() function that only has a frequency and duration (automatically runs in the background). With toneACmini() instead of toneAC() it went down to 1488 bytes on the Uno. But, not sure if 116 bytes is worth confusing people.
Krodal:
(2) The ISR uses millis(), so a roll-over of the millis is possible. The length is no longer fail-safe, so using the delay() function with noToneAC() is preferrable for critical situations.
It uses unsigned long int, so it's about a 50 day range. That should be good for almost any situation. The rollover of micros is critical, but ms hardly ever happens in the real world. Although, I am working on a project right now that I'm trying to get it to run virtually forever.
Krodal:
(3) You don't use the 'L' for long values. I don't mind about it in the sketch, but you could use it in your library. I prefer to use 0L, 256L, - 1L and so on, when long integers are involved.
If there's an advantage I'm not aware of let me know. Most of my longs are unsigned longs. Not sure if that makes a difference.
Krodal:
(4) The examples have the extension *.pde. I would prefer *.ino
They need to be .ino for a library so old versions of Arduino can find them. I'm running only v1.0.2 so everything is a .pde. I change them to .ino just for the library. Other library creators told me to use .ino
Krodal:
(5) In the example you use '/* .... */' for comment, but everwhere else '//'.
I hardly ever use '/* .... */'. I use it in that particular case to try and identify that you can do a bunch of stuff there, not just one line.
Krodal:
(6) In the example, you use a potmeter. But for a small test with the library, a very quick result (showcase) would be needed. And a potmeter will make it unnecessary complicated.
The library is designed for sound, not LEDs. The sample is "toneAC_demo" which doesn't use a pot. The one you're talking about is an advanced one that I don't mention anywhere as it's only for more advanced users that may want to use toneAC for other purposes.
Krodal:
(7) You made 10 volume steps, which is great. But for a 'ping' sound, a smooth decrease of the volume is needed. Or am I asking too much for the library ? Are there open source examples of tunes with volume ?
You're asking too much. I got out my SPL meter and it was HARD to get even 10 volume levels. A square wave just doesn't work well for creating a true volume level. I had to cheat to get even 10, there was really only 9 but that would just be confusing.
Krodal:
( 8 ) Why is the sound different for this example ?
They're very close. But, the first loop is inferior because it uses the foreground method and therefore there's a short period of time where there's no sound, producing a non-constant sound and clicking. This way is designed for a laymen who who isn't too comfortable with programming but they can still generate sound using this method and would probably be totally happy with that. The second way is a more proper way that a higher level programmer would use, knowing that the first way would have a very slight but still noticeable gap between notes reducing quality. I would only ever use the second loop, as I did with the original tone() library as well.
The idea that something runs in the background is very foreign to many novice programmers. They love delay statements, or a command that just does something for as long as they specify and then returns to them when it's done. So, toneAC makes it easy for the masses, but still powerful for those who better understand an interrupt/timer driven paradigm.
Tim