Seeking function in sf::Music

[Laurent]

Hi

I know that some of you are waiting for a Music::SetPlayingOffset function. I added it today to the sfml2 branch, so I'd be happy to get some feedbacks

Important for Linux users
This version requires at least libsndfile 1.0.18, which might not be in the official Linux repositories (1.0.17 seems to be the latest), so you might have to download it and compile it.

[Tank]

Great to hear that. I'll check that out later.

Oh, btw, for the developers using Debian testing:

Code: [Select]

Package: libsndfile1
Version: 1.0.18-2

[alaterale]

I know this is an older thread, but I figured it would be better than starting a completely new one for my question which is directly related.

Is it possible to backport this SetPlayingOffset function into the svn trunk (what I think is referred to as 1.6)?  That's what I'm currently using at the moment, and so far I can't get 2.0 working.

I really need the functionality to seek in music files (well really at the moment all I need is a Reset() function that resets the current offset to 0, since I need to play, stop, and then play again from the beginning of a music file).  Maybe it would be easier to create a reset function than a random seek time one?  Either way, it would be a big help for me if I could find some way to do this.  Even a tutorial on how to port the audio code from 2.0 back into 1.6 and I can do it myself, or at least try  If somehow this feature already exists and I missed it.. sorry about that, I just don't see anything like it atm.

Any help in this would be greatly appreciated.  Thanks!

[Laurent]

Is it possible to backport this SetPlayingOffset function into the svn trunk (what I think is referred to as 1.6)?

No, I'm sorry. The features in trunk are frozen, I'm only making it more stable and robust until SFML 2 comes and replaces it. And this new feature requires many modifications to the code.

so far I can't get 2.0 working

What's your problem?

well really at the moment all I need is a Reset() function that resets the current offset to 0, since I need to play, stop, and then play again from the beginning of a music file

Why don't you call Stop() and then Play(), to reset your music?

[alaterale]

It chokes on the Window - Win32 compiling code, still trying to figure out if/how I can get it to compile here.  Here's a quick excerpt:

Code: [Select]

In file included from c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Backend.cpp:36:
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/Joystick.cpp:29:1: warning: "_WIN32_WINNT" redefined
In file included from c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/windows.h:48,
                 from c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/ContextWGL.hpp:32,
                 from c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/ContextWGL.cpp:28,
                 from c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Backend.cpp:35:
c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/windef.h:20:1: warning: this is the location of the previous definition
In file included from c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Backend.cpp:35:
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/ContextWGL.cpp: In member function 'void sf::priv::ContextWGL::CreateContext(sf::priv::ContextWGL*, unsigned int, const sf::ContextSettings&)':
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/ContextWGL.cpp:291: error: 'PFNWGLCREATECONTEXTATTRIBSARBPROC' was not declared in this scope


There's more, but I suspect it's because of some windows thing which I'm trying to figure out too.  Backend btw is just a small file to simplify compilation using the SFML system constants and #includes of the .cpp files.

Also, Play(), Stop(), and then Play() was what I was doing, since I figured that Stop reset the timer  Only, it does nothing to reset the current time, at least in the 1.6 trunk that I'm using (which is only a month old).  At first I noticed that after playing a music file, stopping it for a scene and then coming back, nothing was played.  It registers as status::playing, but if you print out the GetPlayingOffset() results it stays at the last known point.

I can understand wanting to keep the trunk feature frozen though.  Maybe there's a bug with Stop if it's apparently supposed to reset the counter?  I suppose it could just be my fault too (probably) and I'll double check my code again for playing too.

[alaterale]

Yeah, I just checked again, and it does indeed only play until the first stop, and the next time a music is played, I hear nothing.  Printing the offset directly after a Stop() is called has some interesting results too.  It's never 0 (except for the first time when the music actually plays), but it doesn't seem to be static either.  One music track I was testing with had the offset be from 60 to 90 and fluctuate.  At first I thought that was because it was looping and not playing, but I turned looping off for it and the same thing happened...

Maybe my best bet is to get 2.0-svn compiling I think.

[Laurent]

It chokes on the Window - Win32 compiling code

Do SFML and its samples compile?
If so, you should provide a minimal and complete example that reproduces the problem you get.

Only, it does nothing to reset the current time, at least in the 1.6 trunk that I'm using (which is only a month old). At first I noticed that after playing a music file, stopping it for a scene and then coming back, nothing was played. It registers as status::playing, but if you print out the GetPlayingOffset() results it stays at the last known point.

Looks like a bug in SFML

Yeah, I just checked again, and it does indeed only play until the first stop, and the next time a music is played, I hear nothing

Ok, I'll check this and let you know.

[alaterale]

Well, I couldn't get the svn 2.0 to compile via the Makefile, since I'm in windows/mingw not linux, and visual studio 2005 builds the library (but not the samples, though that's probably because I'm missing certain libraries like QT).

I fixed one of the error messages by adjusting the glext include to reference my existing glext files (which are more updated that the ones on sfml's svn), but I still get some errors relating to defines:

Code: [Select]

In file included from c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Backend.cpp:36:
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/Joystick.cpp:29:1: warning: "_WIN32_WINNT" redefined
In file included from c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/windows.h:48,
                 from c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/ContextWGL.hpp:32,
                 from c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/ContextWGL.cpp:28,
                 from c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Backend.cpp:35:
c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/windef.h:20:1: warning: this is the location of the previous definition
In file included from c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Backend.cpp:38:
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/WindowImplWin32.cpp: In member function 'void sf::priv::WindowImplWin32::ProcessEvent(UINT, WPARAM, LPARAM)':
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/WindowImplWin32.cpp:643: error: 'WM_XBUTTONDOWN' was not declared in this scope
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/WindowImplWin32.cpp:655: error: 'WM_XBUTTONUP' was not declared in this scope
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/WindowImplWin32.cpp: In static member function 'static sf::Key::Code sf::priv::WindowImplWin32::VirtualKeyCodeToSF(WPARAM, LPARAM)':
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/WindowImplWin32.cpp:753: error: 'VK_OEM_PLUS' was not declared in this scope
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/WindowImplWin32.cpp:754: error: 'VK_OEM_MINUS' was not declared in this scope
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/WindowImplWin32.cpp:757: error: 'VK_OEM_COMMA' was not declared in this scope
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/WindowImplWin32.cpp:758: error: 'VK_OEM_PERIOD' was not declared in this scope
make[2]: *** [CMakeFiles/gamestone.dir/Libs/SFML/Window/Backend.cpp.obj] Error 1
make[1]: *** [CMakeFiles/gamestone.dir/all] Error 2
make: *** [all] Error 2

Looks like it might be a problem with mingw's symbols for certain input types?  I'll look more into it later, now I need to get to bed (stayed up so late today )

[Laurent]

What's your version of MinGW / gcc?

SFML 2 compiles fine with MinGW, I think you have a problem with your compiler (maybe an old version, or bad settings).

[alaterale]

When you say it compiles fine with MinGW, how are you compiling?  I only see a regular Unix makefile (which if run in MinGW fails because I don't have X11 installed, which I obviously wouldn't have building for windows ), and then I see build scripts for visual studio, xcode, and codeblocks.  Is there a windows-mingw specific makefile somewhere in here?

My version of gcc is:

Code: [Select]

$ gcc -v
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.4.0/configure --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --disable-sjlj-exceptions --enable-shared --enable-libgcj --enable-libgomp --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --prefix=/mingw --with-gmp=/mingw/src/gmp/root --with-mpfr=/mingw/src/mpfr/root --build=mingw32
Thread model: win32
gcc version 4.4.0 (GCC)

Using TDM-MinGW from here:
http://www.tdragon.net/recentgcc/

Everything else seems to compile fine, and I haven't changed any settings for the compiler from the default install.  Still looking into it though, since visual studio apparently had no problem with that particular code.

[alaterale]

I commented out the WM_XBUTTONDOWN and such symbols in the WindowImplWin32.cpp file that were problematic, and everything compiled fine afterwards.  So I don't have access to mouse XButtons (what are xbuttons anyway?) on the mouse and a couple keys on the keyboard, but it compiled.

Did the Ogg reading code get removed from SFML audio in 2.0?  I have problems opening such files, saying they aren't implemented.  Also having problems with previously working opengl code for displaying sprites so it's not the only problem.

I guess for now I'll just go back to the 1.6 code (now that I have the latest svn downloaded I'll update to the latest 1.6 code, even though looking at the logs it doesn't seem that much has changed in the last month) and continue onward.  Maybe there's a simpler way to just get music files to reset in that, and like you said, sounds like a bug or something.

[Laurent]

When you say it compiles fine with MinGW, how are you compiling?

Currently with Code::Blocks. There's no direct makefile for MinGW.

I commented out the WM_XBUTTONDOWN and such symbols in the WindowImplWin32.cpp file that were problematic, and everything compiled fine afterwards. So I don't have access to mouse XButtons (what are xbuttons anyway?) on the mouse and a couple keys on the keyboard, but it compiled.

I don't know how they do but the Win32 API support (especially constants) is always incomplete in MinGW. Maybe you should try an official version of MinGW ? I know that a 4.x was (finally) released a few weeks ago.

Did the Ogg reading code get removed from SFML audio in 2.0? I have problems opening such files, saying they aren't implemented

You have to use the new libsndfile DLL provided with SFML 2.

Also having problems with previously working opengl code for displaying sprites so it's not the only problem.

Changes were made to this area. Until the documentation comes, you can read the corresponding topics on the forum and look at the samples (the OpenGL on,e in this case).

Maybe there's a simpler way to just get music files to reset in that, and like you said, sounds like a bug or something.

Yep
I'll look into that soon.

[alaterale]

When you say it compiles fine with MinGW, how are you compiling?

Currently with Code::Blocks. There's no direct makefile for MinGW.

I commented out the WM_XBUTTONDOWN and such symbols in the WindowImplWin32.cpp file that were problematic, and everything compiled fine afterwards. So I don't have access to mouse XButtons (what are xbuttons anyway?) on the mouse and a couple keys on the keyboard, but it compiled.

I don't know how they do but the Win32 API support (especially constants) is always incomplete in MinGW. Maybe you should try an official version of MinGW ? I know that a 4.x was (finally) released a few weeks ago.

Did the Ogg reading code get removed from SFML audio in 2.0? I have problems opening such files, saying they aren't implemented

You have to use the new libsndfile DLL provided with SFML 2.

Also having problems with previously working opengl code for displaying sprites so it's not the only problem.

Changes were made to this area. Until the documentation comes, you can read the corresponding topics on the forum and look at the samples (the OpenGL on,e in this case).

Maybe there's a simpler way to just get music files to reset in that, and like you said, sounds like a bug or something.

Yep
I'll look into that soon.

Ahh gotcha on the codeblocks thing, yeah I haven't used that in years.

I did see that they are starting to finally get around to GCC 4.0 in mingw, and I tried it a little while ago for a different issue.  Certainly that is a possibility.  Though with the other problems and changes to opengl and such I think I'll just stick with 1.6 for now since I know it works aside from the sound issue.  I have a class project that I'm working on, and there are plenty of other areas I can finish up in the meantime in the next 2 weeks, and I might be able to hack my code so that it reopens the sound file or something in case.

Also, I don't use DLLs (compile from source), so I know the ogg thing wasn't pertaining to that.  In fact, I keep tabs on the libraries like libsndfile and make sure they are up to date, so the libsndfile I am using is 1.0.20.  I noticed that in Audio/ there are no longer any Ogg specific source files like there are in 1.6, so that's why I was asking.  I thought maybe the ogg reader derived classes were moved elsewhere into a plugin or something.

Thanks for the help so far, I hope I can get this game finished well enough for this class, and then I can post up about it on the other forum board (along with the engine I'm writing).

[Laurent]

Also, I don't use DLLs (compile from source), so I know the ogg thing wasn't pertaining to that. In fact, I keep tabs on the libraries like libsndfile and make sure they are up to date, so the libsndfile I am using is 1.0.20

You have to use libsndfile as a DLL because of its licence.
On Windows, SFML currently uses version 1.0.18 so maybe it is incompatible with your 1.0.20. You should try to use the DLL provided in the SDK.

I noticed that in Audio/ there are no longer any Ogg specific source files like there are in 1.6, so that's why I was asking. I thought maybe the ogg reader derived classes were moved elsewhere into a plugin or something.

It was added to libsndfile, that's why I was able to remove a lot of ogg/vorbis specific stuff in the audio module

[alaterale]

Also, I don't use DLLs (compile from source), so I know the ogg thing wasn't pertaining to that. In fact, I keep tabs on the libraries like libsndfile and make sure they are up to date, so the libsndfile I am using is 1.0.20

You have to use libsndfile as a DLL because of its licence.
On Windows, SFML currently uses version 1.0.18 so maybe it is incompatible with your 1.0.20. You should try to use the DLL provided in the SDK.

I don't see how there would be a problem with licensing.  Libsndfile is LGPL, my project is LGPL, and SFML is zlib.  Is there a conflict between these that I haven't heard of?  Besides, I don't use dlls or anything related to shared libraries because I'm making the code as cross platform as possible (and easily usable on systems like the iphone).  So static linking from compiled sources is much much easier for me to do  I guess I'm also a bit of a purist in that I like to compile what I'm using unless it's a system library (like OpenGL or OpenAL)

I noticed that in Audio/ there are no longer any Ogg specific source files like there are in 1.6, so that's why I was asking. I thought maybe the ogg reader derived classes were moved elsewhere into a plugin or something.

It was added to libsndfile, that's why I was able to remove a lot of ogg/vorbis specific stuff in the audio module

Ah well that makes sense I guess about the 2.0 audio changes  Still for now I'm going to stick with 1.6 since it already works fine except for this strange bug.  I wonder if it activates the same on my macosx box... Hmm, I will check into that.