Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: "Mike Williams" Newsgroups: comp.lang.basic.visual.misc Subject: Re: The Beep Function. Date: Sun, 8 Jan 2012 11:19:15 -0000 Organization: A noiseless patient Spider Lines: 86 Message-ID: References: <491f49f4-a678-4420-b0e4-935b398adc7b@a40g2000vbu.googlegroups.com> <7b72a5b5-5662-4632-b3b9-9f45a985c9fd@z12g2000yqm.googlegroups.com> <7b75dfb9-f79d-4fd1-a1de-a966b58cbc36@v13g2000yqc.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Injection-Date: Sun, 8 Jan 2012 11:18:32 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="CZKYexsZ91tHDdhgm9pJtw"; logging-data="12143"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19j9ekLm2uwERJruSoyfIdSOGqhxYzAXUI=" In-Reply-To: <7b75dfb9-f79d-4fd1-a1de-a966b58cbc36@v13g2000yqc.googlegroups.com> X-Newsreader: Microsoft Windows Mail 6.0.6002.18197 Cancel-Lock: sha1:FndlLm+XT/imnf71OmJMxcTW5qM= X-Priority: 3 X-MSMail-Priority: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 Xref: x330-a1.tempe.blueboxinc.net comp.lang.basic.visual.misc:620 "Peter Nolan" wrote in message news:7b75dfb9-f79d-4fd1-a1de-a966b58cbc36@v13g2000yqc.googlegroups.com... > Hello Mike. Both blocks of code you gave me worked > first time. I will now implement the code and study it till > I understand what each line actually does. You're welcome. There is one thing I'd like to point out though and that is the fact that both blocks of code were written in such a way that the main loop which generates the sample data for the waveform does it a fairly simple way (by that I mean the easiest way to understand), and not in the fastest way. You won't notice this for most of the wav files you generate (your short one second or so wav files) but you will definitely notice it if you decide, for example, to generate a wav file lasting one minute, in which case even when run as a compiled exe the code would take about a quarter of a second (depending on the speed of your machine) to generate the one minute wav file. So if you were generating the wav file from scratch (rather than playing a previously generated wav file) there would be a noticeable delay between pressing the button and hearing the sound. To see what I mean, have a look at the main loop in the second example, which is as follows: For n = 0 To totalsamples - 1 d1 = Amplitude * Sin(k) wavfile(n + 23) = d1 k = k + dAngle Next n The value of totalsamples represents the total number of voltage samples in the entire wav file being generated, and it uses the relatively slow Sin function on variables of the Double data type to calculate each one of them (and there are also some relatively slow "under the hood" conversions from integer to floating point going on, because d1 is currently a Long and the result of Amplitude * Sin(k) is a Double). For a wav file that is one minute long and that uses a sample rate of 44100 samples per second the above loop would need to generate something approaching three million samples, which is why it takes about a quarter of a second to generate the data (on my own machine). For the time being you might like to leave it that way, but if you ever get to the stage where you need to use it to generate long wav files then you might like to look at ways of speeding it up. There are all sorts ways of performing the task in a faster way. For example with your own background you will almost certainly realise that when generating a continuous tone where each cycle is mathematically described, such as a sine wave, you really only need to generate a block of cycles of such length that when you join a large number of those blocks together (in order to create the full wav file) there will not be a "glitch" between the end of one block and the start of the next block. Since the first block starts at a zero voltage level and is rising then you just need to ensure the length of the block is such that it ends at a point where the final sample of the block is also at (or at least very close to) a rising zero crossing point. The cycle length of this block of course will depend on the relationship between the sample rate (44100 Hz CD rate in this case) and on the frequency of the tone you are generating, but it can readily be calculated, and the block will in virtually all cases be extremely small compared to the overall length of the entire wav file data. You can then write a bit more code to simply "stitch lots of these small blocks together" to produce the total wav file. This will be orders of magnitude faster for long wav files. Another way would be to continue to use the existing "generate all the possibly millions of samples for the whole wav file" method but to modify the code so that it can readily use a lookup table rather than using the Sin function, although you would still be using floating point and you would still have either explicit or "under the hood" relatively slow floating point to integer conversions, so it would probably only be two or three times faster. You can carry this technique further though by modifying the code so that it both uses a lookup table and also uses only integers in the loop (this would require more significant modification). This method, even though it still generates all the possibly millions of samples, would be very much faster than the existing method, probaby an order of magnitude faster. In fact although the first suggestion would be the fastest I think I would prefer to use this method myself on the grounds that it would be readily suitable for producing wav files in which the waveform required is more complex than a simple Sine wave, one with perhaps lots of harmonics. Don't get me wrong, I am not by any means an expert in wav file generation or in musical sounds in general. In fact what I know about thse things can be written on the back of a postage stamp (!) but I do have a passing interest in such stuff. I was actually going to address some of the other points in the rest of your message at this point, but I think I've waffled on enough already! Mike