11-27-2022, 02:54 AM
I'm having a devil of a time getting that straight in my head.
Is SOUND synchronous or asynchronous ?
|
11-27-2022, 02:54 AM
I'm having a devil of a time getting that straight in my head.
11-27-2022, 06:51 AM
(This post was last modified: 11-27-2022, 06:57 AM by mnrvovrfc.
Edit Reason: I'm the master at modifying my posts LOL
)
Let's see if I know what I'm talking about.
"PLAY" and "SOUND" could play in the background, but one tone at a time, however. A few exceptions were IBM PCjr and Tandy1000 in which was possible to play up to three voices at a time with those commands, plus pink and white noise. "Synchronous" means more than one voice at a time, right? It's possible with "_SND" commands in QB64(PE) but the programmer will have to manage it. https://qb64phoenix.com/qb64wiki/index.php/SNDOPENRAW Erm, just checked out this example but please lower the volume to a very low level before running it because it could get harsh. The problem with "SOUND", specifically, is that the programmer must provide a duration. If the programmer is interested in changing the sound to react to user input or some other event, cannot do it only with "SOUND", might have to invest in "ON PLAY" ancient mechanism while programming in Q(uick)BASIC. Way back then 16-bit was incapable of playing back any kind of single-cycle waveform in high quality or any other sound that was much more complex, and even less on more than one voice at a time. Could do arpeggios easily with "PLAY" but that's all with Q(uick)BASIC.
11-27-2022, 07:26 AM
(11-27-2022, 02:54 AM)CharlieJV Wrote: I'm having a devil of a time getting that straight in my head. SOUNDwaits for the duration of the sound, so it's synchronous. Note however that if you use PLAY "MB"at some point to play sounds in the background that also impacts SOUNDcommands, so it's possible to have them play in the background (potentially by accident). That behavior was recently fixed in QB64-PE v3.2.0, so if you use a version older than that SOUNDwon't respect the PLAY "MB"setting and will always wait for the sound to finish.
11-27-2022, 03:29 PM
(11-27-2022, 07:26 AM)DSMan195276 Wrote:(11-27-2022, 02:54 AM)CharlieJV Wrote: I'm having a devil of a time getting that straight in my head. Let's see if I get it. SOUND is asynchronous in the sense that a SOUND statement does not cause the entire program to pause until the statement finishes. SOUND is synchronous in the sense that a SOUND statement cannot start until a previous SOUND statement completes. Is that right? Both asynchronous AND synchronous? (11-27-2022, 06:51 AM)mnrvovrfc Wrote: ...snip... Sorry, by synchronous, I mean is the SOUND statement synchronous or asynchronous vis-à-vis the remaining sequence of statements in a running program? i.e. synchronous operation requires that one operation (operation b) must wait for another (operation a) to complete before it (operation b) can begin. I'm thinking SOUND is:
Because I haven't seen that written anywhere, I'm not super-confident I've understood all of that correctly. (My understanding of things heavily depends on seeing the words and visual cues that help me relate back to things I'm familiar with.) |
« Next Oldest | Next Newest »
|