A couple of people have reported that this isn't working in the new version 3.1 in QB64-PE. As I explained there, the glitch is two-fold:
First, the old version of QB64-PE was glitched. The OpenAL backend *always* converted things down to mono-sound, so this program was always running under the 'integer mono TYPE 0 block of the IF statement in it. The new audio backend doesn't have that glitch (we fixed it), and now you get your stereo sound and such to play, whereas it never did before! YAY!!
Second, this program has a slight glitch in how it checks against the mem.TYPE values.
Here, it checks to see if the mem.TYPE = 1 or if the mem.TYPE = 4.
This isn't what the values actually are. MEM values are built upon the various parts of the flags which make up the type which the mem block contains.
For example, if the data length is 4 bytes, then it sets the 3rd bit to TRUE. (which &B100 has a value of 4)
Now, if this data is an INTEGER TYPE, then it sets bit 7 to TRUE. (which &B1000000 has a value of 128)
If the data is a FLOATING POINT TYPE, then it sets bit 8 to TRUE. (and &B10000000 has a value of 256)
So, if our data type is a LONG, it'd have a value of 132. (bit 3 set and bit 7 set, making it an integer type which takes uses 4 bytes of memory)
If the data type was a SINLGE, it'd have a value of 260. (bit 3 set and bit 8 set, making it a floating point type which uses 4 bytes of memory
So the values you're looking for here isn't EQUAL 1 or EQUAL 4 -- they're AND 128 (integer type) or AND 256 (floating point type)...
It's a minor glitch in the code which was never triggered or found because the old audio backend was glitched itself and only ever produced a TYPE 0 response. To work properly with the new backend, and to have stereo sound playing and all, these checks need to be ANDed instead of EQUALed.
First, the old version of QB64-PE was glitched. The OpenAL backend *always* converted things down to mono-sound, so this program was always running under the 'integer mono TYPE 0 block of the IF statement in it. The new audio backend doesn't have that glitch (we fixed it), and now you get your stereo sound and such to play, whereas it never did before! YAY!!
Second, this program has a slight glitch in how it checks against the mem.TYPE values.
Here, it checks to see if the mem.TYPE = 1 or if the mem.TYPE = 4.
Code: (Select All)
If (sz = 4 Or sz = 2) And SampleData.TYPE = 1 Then ' integer stereo or mono
...stuff
ElseIf (sz = 8 Or sz = 4) And SampleData.TYPE = 4 Then ' floating point stereo or monoThis isn't what the values actually are. MEM values are built upon the various parts of the flags which make up the type which the mem block contains.
For example, if the data length is 4 bytes, then it sets the 3rd bit to TRUE. (which &B100 has a value of 4)
Now, if this data is an INTEGER TYPE, then it sets bit 7 to TRUE. (which &B1000000 has a value of 128)
If the data is a FLOATING POINT TYPE, then it sets bit 8 to TRUE. (and &B10000000 has a value of 256)
So, if our data type is a LONG, it'd have a value of 132. (bit 3 set and bit 7 set, making it an integer type which takes uses 4 bytes of memory)
If the data type was a SINLGE, it'd have a value of 260. (bit 3 set and bit 8 set, making it a floating point type which uses 4 bytes of memory
So the values you're looking for here isn't EQUAL 1 or EQUAL 4 -- they're AND 128 (integer type) or AND 256 (floating point type)...
Code: (Select All)
If (sz = 4 Or sz = 2) And (SampleData.TYPE AND 128) Then ' integer stereo or mono
...stuff
ElseIf (sz = 8 Or sz = 4) And (SampleData.TYPE AND 256) Then ' floating point stereo or monoIt's a minor glitch in the code which was never triggered or found because the old audio backend was glitched itself and only ever produced a TYPE 0 response. To work properly with the new backend, and to have stereo sound playing and all, these checks need to be ANDed instead of EQUALed.