Author Topic: _SNDLIMIT Behavior (not a bug)  (Read 4706 times)

0 Members and 1 Guest are viewing this topic.

Offline TerryRitchie

  • Seasoned Forum Regular
  • Posts: 495
  • Semper Fidelis
    • View Profile
_SNDLIMIT Behavior (not a bug)
« on: April 27, 2020, 05:55:18 pm »
_SNDLIMIT behaves differently from what it used to. This code:

Code: QB64: [Select]
  1. DIM WilliamTell&
  2. DIM Count%
  3.  
  4. WilliamTell& = _SNDOPEN("WilliamTell.ogg")
  5. PRINT " The first five seconds of the William Tell Overture"
  6. _SNDLIMIT WilliamTell&, 5
  7. _SNDPLAY WilliamTell&
  8. FOR Count% = 1 TO 5
  9.     _DELAY 1
  10.     PRINT Count%; "..";
  11. NEXT Count%
  12. _SNDCLOSE WilliamTell&

Behaves very strangely. Not only does _LIMIT not work, the _SNDCLOSE statement does not stop the sound from playing. However simply placing the _SNDLIMIT line after the _SNDPLAY line clears everything up and the code works as expected.


oops...hold on...

After switching these two lines around a few times _SNDLIMIT isn't working in either case now?? Maybe a bug?

« Last Edit: April 28, 2020, 12:05:35 pm by TerryRitchie »
In order to understand recursion, one must first understand recursion.

Offline TerryRitchie

  • Seasoned Forum Regular
  • Posts: 495
  • Semper Fidelis
    • View Profile
Re: _SNDLIMIT Behavior (bug?)
« Reply #1 on: April 27, 2020, 06:25:15 pm »
I thought maybe it had something to do with OGG files so I tried it with an MP3 as well. Same outcome.
In order to understand recursion, one must first understand recursion.

Offline Dav

  • Forum Resident
  • Posts: 792
    • View Profile
Re: _SNDLIMIT Behavior (bug?)
« Reply #2 on: April 27, 2020, 07:11:27 pm »
I get the same results no matter where _SNDLIMIT is placed.  Just a guess here, but I suspect the DELAY routine is completing just a wee bit before the 5 sec SNDLIMIT is reached.  When I increase the delay to 1.01 it stops.

EDIT: Perhaps theres a very slight delay after calling _SNDPLAY before the the system actually starts playing it...So it actually starts playing while already in the delay loop?   Your recording brings back alot of memories for me - I use to play trumpet in an orchestra and have very fond memories of that Rossini piece.  Do you know which orechestra is playing in your recording?
 

- Dav
« Last Edit: April 27, 2020, 07:46:28 pm by Dav »

Offline TerryRitchie

  • Seasoned Forum Regular
  • Posts: 495
  • Semper Fidelis
    • View Profile
Re: _SNDLIMIT Behavior (bug?)
« Reply #3 on: April 27, 2020, 09:26:03 pm »
No idea which orchestra, sorry. I too have good memories. I was once a concert violinist (2nd violin) and that was always a challenging piece. I was with a local community orchestra that played at benefits and for the community theater.
In order to understand recursion, one must first understand recursion.

Offline Dav

  • Forum Resident
  • Posts: 792
    • View Profile
Re: _SNDLIMIT Behavior (bug?)
« Reply #4 on: April 28, 2020, 09:25:10 am »
That's cool, Terry!  Yes, violins have a lot of fireworks in it.  The trumpet part isn't particularly difficult, other than being just a big blow.  Community orchestras are great.  Although I played professionally, I enjoyed playing with community orchestras more.  The people participate more for joy of music, and being civic minded (wish I could say there are less egos, but big egos are everywhere in the trumpet world).

I was looking at the _SNDCLOSE in the wiki, and it doesn't appear calling it stops the sound from playing, just releases the handle.  The sound will play out until the end.  I didn't realize that.  Still, I'm surprised the mp3 keeps playing even after the program ends.  Maybe that should be looked at...

- Dav

 

FellippeHeitor

  • Guest
Re: _SNDLIMIT Behavior (bug?)
« Reply #5 on: April 28, 2020, 10:07:41 am »
After the program ends *and is closed* or after END displays "Press any key..."? Cause that doesn't mean it ended, really. Not as in DOS days.

A sound playing has been buffered to the sound card and that's why it doesn't matter that you close its handle. The "play" operation had already been performed.

If the intended result is to stop it at END, then _SNDSTOP should be used first.

Offline Petr

  • Forum Resident
  • Posts: 1720
  • The best code is the DNA of the hops.
    • View Profile
Re: _SNDLIMIT Behavior (bug?)
« Reply #6 on: April 28, 2020, 11:36:39 am »
This led me to the following idea: If you want to make music, then you can only play a part of the music file, you can repeat only one section, which does not have to start at the beginning of the music track. As it shows, the following quick program, which needs to be improved if you want to play multiple tracks this way at the same time. But when using fields it is not a problem. The same can be done again for _SNDRAW (if anyone is interested). Try it on any MP3 music track longer than 15 seconds.


Code: QB64: [Select]
  1. music = _SNDOPEN("test.mp3")  
  2.  
  3.     SNDLIMITPLUS music, 10, 15
  4.  
  5. SUB SNDLIMITPLUS (handle AS LONG, StartTime AS SINGLE, EndTime AS SINGLE)
  6.     _SNDSETPOS handle, StartTime
  7.     _SNDPLAY handle
  8.     DO UNTIL _SNDGETPOS(handle) >= EndTime
  9.         LOCATE 1
  10.         PRINT "Time position in file:"
  11.         PRINT _SNDGETPOS(handle)
  12.     LOOP
  13.     _SNDSTOP handle
  14.  
« Last Edit: April 28, 2020, 11:37:45 am by Petr »

Offline Dav

  • Forum Resident
  • Posts: 792
    • View Profile
Re: _SNDLIMIT Behavior (bug?)
« Reply #7 on: April 28, 2020, 11:49:56 am »
Neat Idea, Petr.  Now I could pack many program SFX sounds into one file.   

- Dav

Offline TerryRitchie

  • Seasoned Forum Regular
  • Posts: 495
  • Semper Fidelis
    • View Profile
Re: _SNDLIMIT Behavior (bug?)
« Reply #8 on: April 28, 2020, 11:57:07 am »
Ok, this code works. It appears my use of _SNDCLOSE before exactly 5 seconds elapsing may be causing this issue.

Code: QB64: [Select]
  1. DIM Will&, Count%
  2.  
  3. Will& = _SNDOPEN("williamtell.ogg")
  4.  
  5. _SNDLIMIT Will&, 5
  6. _SNDPLAY Will&
  7.  
  8. Count% = 0
  9.     _DELAY 1
  10.     Count% = Count% + 1
  11.     PRINT "playing for"; Count%; "seconds now."
  12. _SNDCLOSE Will&
  13.  

Get the OGG file from the original post.
In order to understand recursion, one must first understand recursion.

Offline Petr

  • Forum Resident
  • Posts: 1720
  • The best code is the DNA of the hops.
    • View Profile
Re: _SNDLIMIT Behavior (not a bug)
« Reply #9 on: April 28, 2020, 12:27:51 pm »
Quote
Neat Idea, Petr.  Now I could pack many program SFX sounds into one file.   

- Dav

Dav, that depends a lot on how audio files are processed. The concept, as I put it here, would have the following problem if you put many audio tracks into one. It would use the SNDGETPOS command to move a pointer in the same file, so it could only be used for instruments that can only play independently. To avoid this problem, you would have to open a large audio file in multiple copies with the SNDOPEN command, and this would be memory-intensive and unnecessary. So if I insert multiple music files into one file, then yes, but I would use one binary file for multiple music files. I've dealt with that here: https://www.qb64.org/forum/index.php?topic=910.msg101177#msg101177  but that's out off this topic, of course.
The concept as it is here is something I caught while studying the MOD format. There are samples (WAV, 8 bit, mono) and this way this WAV can be used to create many music samples. The mono format is perfect for MOD because it allows for great stereo effects, for example, if you put mono sound in the left speaker and in 200 milliseconds put the same pattern in the right speaker, you get a pseudo-stereo effect. However, since we do not have access to RAW audio data, this cannot be done with the MP3 format, but still it is possible with WAV audio samples.
« Last Edit: April 28, 2020, 12:29:18 pm by Petr »

Offline Dav

  • Forum Resident
  • Posts: 792
    • View Profile
Re: _SNDLIMIT Behavior (not a bug)
« Reply #10 on: April 28, 2020, 12:55:30 pm »
Interesting, Petr.  Thanks for the information.  Also, thank for the link to the add files to EXE thread.  That's something I've been interested in.  What I ended up doing is marking the compiled EXE with its file size, in a usable/safe area of it's header.  Then have the program get its EXE name when running and read itself to get its EXE size so it can know where the attached DATA files begins. I could post that if anyone's interested.   

- Dav

Offline Petr

  • Forum Resident
  • Posts: 1720
  • The best code is the DNA of the hops.
    • View Profile
Re: _SNDLIMIT Behavior (not a bug)
« Reply #11 on: April 28, 2020, 01:07:25 pm »
The link is to a more advanced program, for music purposes it would be enough to use only DO_PMF and EXTRACT_PMF, it is a kernel that copies many files into a single file with a PMF extension and then it can be unpacked while preserving the file names. I'm definitely interested in your concept, but probably in to a new thread, because  we're  here too off topic.