With QB64PE V3.3 having new parameters for _SNDPLAYCOPY, I wondered if building a sound and saving it was possible. I mean in the same sort of way that you can build an image by using pset, line, circle etc and then saving it into an image using _PUTIMAGE. I assume there's no way but I thought I'd ask here, just in case.
For example, here is a sort of doppler/fading beep routine:
Code: (Select All)
Dim blip&
blip& = _SndOpen("G025.mp3")
v1 = 0
switch = 0
Do
_Limit 8
If switch = 0 Then
v1 = v1 + .499
If v1 > 1 Then
v1 = 1
switch = 1
End If
Else
v1 = v1 - .1
If v1 < 0 Then
v1 = 0
switch = 0
_Delay 2.
End If
End If
_SndPlayCopy blip&, v1
Loop
If you were making a game and wanted to repeat this overall routine, would you just repeat the routine or try to capture it into a sound file and just use that? Hope I'm making sense. Just curious what a good strategy would be.
I haven't looked into this new addition yet. Old school would be to use the Windows Voice Recorder to capture it via the mic as either a .wav or mp3 file and then go to some online site to convert it to .ogg format. Then you'd have a sound file you could call with QB64.
10-12-2022, 09:54 PM (This post was last modified: 10-12-2022, 09:58 PM by a740g.)
(10-12-2022, 09:04 PM)james2464 Wrote: If you were making a game and wanted to repeat this overall routine, would you just repeat the routine or try to capture it into a sound file and just use that? Hope I'm making sense. Just curious what a good strategy would be.
I think I get what you are saying. Well, there are multiple ways to do this.
You can do it with static sounds and then programmatically change the sound parameters on-the-fly like you are doing in the example. This obviously is not too flexible and does not allow you to do advanced effects. You'll be limited to position, volume, and panning effects.
You could also programmatically generate the sound waveform yourself and play it using SNDRAW. This allows you to do very advanced audio effects. However, it requires you to "run" your sound generating code that is pushing the samples to SNDRAW whenever you want to play the sound. This may be processor intensive (especially on low spec. hardware).
Personally, to store a sound, I like to use _SNDPLAY. In the setup area of my program, I check for the sound file and if it is in the directory, the program loads it, and assigns it to a variable like mysound&. When I want it played, I just code: _SNDPLAY mysound&
Looking forward to the upcoming sound buffer effects, too.
(10-12-2022, 09:04 PM)james2464 Wrote: If you were making a game and wanted to repeat this overall routine, would you just repeat the routine or try to capture it into a sound file and just use that? Hope I'm making sense. Just curious what a good strategy would be.
I think I get what you are saying. Well, there are multiple ways to do this.
You can do it with static sounds and then programmatically change the sound parameters on-the-fly like you are doing in the example. This obviously is not too flexible and does not allow you to do advanced effects. You'll be limited to position, volume, and panning effects.
You could also programmatically generate the sound waveform yourself and play it using SNDRAW. This allows you to do very advanced audio effects. However, it requires you to "run" your sound generating code that is pushing the samples to SNDRAW whenever you want to play the sound. This may be processor intensive (especially on low spec. hardware).
(10-12-2022, 09:29 PM)Pete Wrote: I haven't looked into this new addition yet. Old school would be to use the Windows Voice Recorder to capture it via the mic as either a .wav or mp3 file and then go to some online site to convert it to .ogg format. Then you'd have a sound file you could call with QB64.
Pete
I haven't tested it, but the "new" audio-sound library could play FLAC. The "flac" program is rather easy to get for Windows. But this is if the user has plenty of disk space and MP3 or OGG isn't acceptable.
Note "OGG" could cause ambivalence for what it really is. "OGG" is really just a container format. "OGG FLAC" is possible; it's PCM data in FLAC format with OGG "header". Could probably do it with a wave file and any other format. A file with extension of "OGG" is really "OGG Vorbis". This is not to be confused with "Opus" format and both are not the same. There are also "OGA" and "OGV" that could be created by some apps on Linux which tends to add to the confusion. "OGA" is "OGG Vorbis", what they tried in vain to change file extension for files which are audio only. There is a video editor that I had used called Openshot which, confusingly insists in "OGG" extension for export to video and the system doesn't work properly if the suffix were changed to "OGV" to be more appropriate.
The "Vorbis utilities" are getting old, but "Opus" wasn't intended to be a replacement. One really doesn't have an advantage over the other. However, for the same variable bitrate (VBR), "OGG Vorbis" is better than MP3 although produces slightly larger files.
On Linux could acquire "ffmpeg" to convert to any of those formats indicated above in this post, although for audio it's a bit difficult to use.
(10-12-2022, 09:29 PM)Pete Wrote: I haven't looked into this new addition yet. Old school would be to use the Windows Voice Recorder to capture it via the mic as either a .wav or mp3 file and then go to some online site to convert it to .ogg format. Then you'd have a sound file you could call with QB64.
Pete
I haven't tested it, but the "new" audio-sound library could play FLAC. The "flac" program is rather easy to get for Windows. But this is if the user has plenty of disk space and MP3 or OGG isn't acceptable.
(10-13-2022, 02:49 PM)Spriggsy Wrote: I have code somewhere for recording the microphone in QB64 using the Win32 API but I'd have to do some digging.
Please share.
Actually, the miniaudio library we are using can do this in a platform independent way. Hopefully, sometime in the future we can add audio capture capability to QB64-PE too. Just thinking out loud.
You may want to check the date on that code, if found, as I believe Windows moved from the "Sound" Recorder app to the "Voice" Recorder app in Win 10. Maybe that would make a difference in API accessibility?