Author Topic: Continuing on from the "test the release candidate" thread on .net  (Read 5654 times)

0 Members and 1 Guest are viewing this topic.

Offline luke

  • Administrator
  • Seasoned Forum Regular
  • Posts: 324
    • View Profile
The bug relating to multiple sounds not playing properly should now be fixed. I'll look into the_SNDRAW matters soon, but I can't promise anything there - the code behind sndraw is sufficiently messy that I don't fully understand what it's doing yet.

As for C++ compilation errors, we're looking at adding some logging to make it more practical to investigate such matters. Hopefully this should be ready in time, but there seems to be some issues with it on windows XP.
« Last Edit: February 24, 2018, 03:00:18 am by luke »

Offline Petr

  • Forum Resident
  • Posts: 1720
  • The best code is the DNA of the hops.
    • View Profile
Re: Continuing on from the "test the release candidate" thread on .net
« Reply #1 on: October 22, 2017, 01:48:46 pm »
Hi. I just sent Fellippe another bug at the sound, I could not save attachment here...

FellippeHeitor

  • Guest
Re: Continuing on from the "test the release candidate" thread on .net
« Reply #2 on: October 22, 2017, 05:21:56 pm »
I've already passed it along to Luke, thanks again for reporting.

FellippeHeitor

  • Guest
Re: Continuing on from the "test the release candidate" thread on .net
« Reply #3 on: October 23, 2017, 02:31:08 pm »
Our next release candidate is now build 20171024/79

Note: Although you may see this build number listed at www.[abandoned, outdated and now likely malicious qb64 dot net website - don’t go there]'s homepage, due to the recent outage you won't be able to get the right build from there, as it won't have been recompiled properly. If you wish to continue to help beta testing, grab it from www.qb64.org for now.

Changelog:

New:
  • when a C++ compilation error occurs, the IDE will now offer a link to a log file containing the error messages output by the compiler, so it's easier to track down those nastier bugs.

Fixed:
  • loading two sound files sequentially would prevent playback if their bitrates didn't match.
  • setup would fail in macOS due to recent changes in Xcode.
  • a C++ compilation error would occur if you called a function with a missing parameter (like a& = _RGB32(255, , 255)).

Removed:
  • due to its hacky nature, loading 256-color (8-bit) images has been again disabled until a better solution comes up.

The more feedback we get, the better the next release will be.
« Last Edit: October 24, 2017, 08:13:14 am by FellippeHeitor »

Offline Petr

  • Forum Resident
  • Posts: 1720
  • The best code is the DNA of the hops.
    • View Profile
Re: Continuing on from the "test the release candidate" thread on .net
« Reply #4 on: October 23, 2017, 05:39:38 pm »
Thank you very much for your work. I'm just playing _SNDRAW, I'm a little surprised. The following program will play WAV 16 bit / stereo, but ..... as soon as I add SCREEN my&, the playback starts lags. Yes, it's a mistake to play directly from a harddrive without creating a CACHE. Did I feel like it should go? According to the measurement, none of the components are overloaded so as to cause the sound to chop. I wanted to do a few things on the basis of this command. Notice the huge difference in memory usage when using the 300-megabyte WAV with the _SNDPLAY and _SNDOPEN command, and a few kilobytes with that program.

The use of the program: + and - works as SNDVOL (for SNDRAW), so I had to reduce the internal CACHE program via SNDRAWLEN because without the other volume writing somewhere in the internal memory depending on which position is currently loaded and can not be checked. (if yes, I'm asking for a demo). It's today's experimental program.
1, 2 for balance for left speaker,  3, 4 for right speaker,   . and >   or , and < for shift in WAV file.  M for sound speed :-D

Code: QB64: [Select]
  1. 'my& = _NEWIMAGE(640, 480, 256)
  2. file$ = "ab.wav"
  3. DIM left AS INTEGER, right AS INTEGER, skip AS _UNSIGNED LONG, bps AS SINGLE, BalLeft AS SINGLE, BalRight AS SINGLE, m AS SINGLE, bpos AS SINGLE, posins AS SINGLE
  4. volume = .5: spd = 1
  5. position = 0 'start WAV location after Head
  6. a = volume: BalLeft = 1: BalRight = 1
  7. OPEN file$ FOR BINARY AS #1
  8. SEEK #1, 45 + position 'skip wav head, position is the same as _SNDSETPOS, but not in seconds, but in bytes
  9. 'screen my&
  10.     GET #1, , left
  11.     GET #1, , right
  12.  
  13.     i$ = INKEY$
  14.     SELECT CASE i$
  15.         CASE "+"
  16.             IF a >= 0 THEN a = a + .1
  17.             IF a < 0 THEN a = a - .1
  18.             IF a > 1 THEN a = 1
  19.             IF a < -1 THEN a = -1
  20.         CASE "-"
  21.             ' IF ABS(a) < 0.01 THEN _CONTINUE
  22.             IF a > 0 THEN a = a - .1
  23.             IF a < 0 THEN a = a + .1
  24.         CASE ">", "."
  25.             skip = SEEK(1) + 4 ^ 10
  26.             IF skip < LOF(1) THEN SEEK #1, skip
  27.         CASE "<", ","
  28.             skip = SEEK(1) - 4 ^ 10
  29.             IF SEEK(1) > 4 ^ 10 THEN SEEK #1, skip
  30.         CASE "1"
  31.             BalLeft = BalLeft + .1
  32.             IF BalLeft > 1 THEN BalLeft = 1
  33.         CASE "2"
  34.             BalLeft = BalLeft - .1
  35.             IF BalLeft < 0 THEN BalLeft = 0
  36.         CASE "3"
  37.             BalRight = BalRight + .1
  38.             IF BalRight > 1 THEN BalRight = 1
  39.         CASE "4"
  40.             BalRight = BalRight - .1
  41.             IF BalRight < 0 THEN BalRight = 0
  42.         CASE "m", "M"
  43.             spd = spd + 1: IF spd > 3 THEN spd = 1
  44.     END SELECT
  45.  
  46.     bps = _SNDRATE * 16 * 2 / 1000 '_SNDRATE is standard sampling frequency per 1 second, is used by 16 bits (1 INTEGER (2 BYTES) for channel), contains 2 channels (channels and sampling frequency are writed in WAV head)
  47.     '                               and i need this in kilobytes, so divide 1000. SO ONE second for music and one channel need 44100 INTEGERS = 44100 * 16 bites if sampling rate is 44100.
  48.  
  49.  
  50.     bpos = SEEK(1)
  51.     posins = INT(SEEK(1) - 45) / bps / 100
  52.  
  53.     LOCATE 1, 1: PRINT "Esc for end, + or - for volume, 1,2 for balance left, 3,4 for balance right     Press < and , or > and .  for shift"
  54.     LOCATE 3, 1: PRINT "SNDRAW Volume:"; INT(ABS(a) * 100); "%"; "   " '; "Byte position:"; bpos                                     'This outputs are commented, because for unknown reasons, cause sound jamming
  55.     LOCATE 4, 1: PRINT " Position in seconds:" '; posins; "        "
  56.     LOCATE 5, 1: PRINT "balance LEFT:"; BalLeft; "balance RIGHT:"; BalRight; "                   "; "Effect (press M)"; spd; "        "
  57.     '-------------- konec SNDRAW bloku hlasitosti --------------------------------------
  58.     '    DO WHILE _SNDRAWLEN > .2 AND _SNDRAWLEN < 0.5: LOOP
  59.     FOR e = 1 TO spd
  60.         _SNDRAW BalLeft * a * left / _SNDRATE, BalRight * a * right / _SNDRATE 'here is diference. If i use this method, is playback speed correct. If i use _SNDRAW a * left / _SNDRATE , 0 in one line and in next _SNDRAW 0, a * right / _SNDRATE in second, then is playback speed slow. Why? (without FOR NEXT e loop)
  61.     NEXT e
  62.     'multiply "a * left / _SNDRATE" or a * right / _SNDRATE" by zero for simulating _SNDBAL, it work not. Output is in both cases for both speakers.
  63.  
  64.  

Offline Petr

  • Forum Resident
  • Posts: 1720
  • The best code is the DNA of the hops.
    • View Profile
Re: Continuing on from the "test the release candidate" thread on .net
« Reply #5 on: October 23, 2017, 05:49:02 pm »
Try comment all LOCATE / PRINT statements in previous program for correct sound, and uncomment  DO WHILE _SNDRAWLEN > .2 AND _SNDRAWLEN < 0.5: LOOP   please.

Offline Bert22306

  • Forum Regular
  • Posts: 206
    • View Profile
Re: Continuing on from the "test the release candidate" thread on .net
« Reply #6 on: October 24, 2017, 03:16:47 pm »
I was wondering, is there any reason why the updates cannot be posted to this site, same as they are posted on the .net site? I've downloaded dirty builds from the .net site, and then recompiled qb64.exe after what Fellippe said, but I was wondering why the extra hassle of having to run a script if downloading from this site?

Of course, as long as the dirty builds are available from the .net site, even if qb64.exe has to be recompiled, no big deal! Easy enough to do that.

Thanks!
« Last Edit: October 24, 2017, 03:19:39 pm by Bert22306 »

FellippeHeitor

  • Guest
Re: Continuing on from the "test the release candidate" thread on .net
« Reply #7 on: October 24, 2017, 03:29:51 pm »
I was wondering why the extra hassle of having to run a script if downloading from this site?

Our server (.org) is Linux-based, whereas .net's server is Windows-based, which allows building the .exe before packing the zip/7z.

Until Galleon solves the disk quota issues at .net, even if you grab it from there you are likely still fetching an old build (I didn't try). Guaranteed updates are available from our homepage (www.qb64.org) and from the GitHub repository directly (https://github.com/Galleondragon/qb64/archive/master.zip). In both cases, you will still need to run setup_win.bat.

Offline luke

  • Administrator
  • Seasoned Forum Regular
  • Posts: 324
    • View Profile
Re: Continuing on from the "test the release candidate" thread on .net
« Reply #8 on: February 19, 2018, 07:30:46 am »
I should mention that nowadays the windows version of QB64 from qb64.org comes precompiled, so there's no need to run the setup script anymore.