it's the C::B tuto code with the example code of sound+music tuto
This (http://www.sfml-dev.org/tutorials/2.3/start-cb.php) and this (http://www.sfml-dev.org/tutorials/2.3/audio-sounds.php)?
Providing the exact combined code you used would help here.
Are you getting any errors in the console?
Make sure that the files can be found and loaded (the correct format).
Are you destroying the soundbuffer? It needs to stay alive as long as any sounds use it.
One other thing that is quite common:
Make sure that you're not just playing the sound in the main loop. This attempts to start the sounds every frame (play starts the sound from the beginning).
Solutions:
Start it based on an event,
Play it before the main loop,
or this:
if (sound.getStatus() != sf::Sound::Playing)
sound.play();
first tutorial (http://www.sfml-dev.org/tutorials/2.3/start-cb.php)
[...]
"Playing sounds and music tutorial" (http://www.sfml-dev.org/tutorials/2.2/audio-sounds.php).
I don't know why you're using one tutorial for 2.3 and one for 2.2. If you're using 2.3, use the 2.3 tutorials (there may be no differences but at least you can be reasonably sure that it'll match the version you are using if there are) as linked in my above post.
One other thing that is quite common:
Make sure that you're not just playing the sound in the main loop. This attempts to start the sounds every frame (play starts the sound from the beginning).
Solutions:
Start it based on an event,
Play it before the main loop,
or this:
if (sound.getStatus() != sf::Sound::Playing)
sound.play();
It looks like your code does exactly this. It tried to start the sound from the beginning every frame.
However, as shadowmouse pointed out, it's much worse here. You're actually creating the soundbuffers and loading the sounds in from the file every frame/cycle/tick.
It loads creates the soundbuffer, loads the sample, creates a sound, starts the sound playing and then immediately destroys all of those objects and does it all over again..
If you'd like to have a look at a (simple) working game with (few) sounds and music, feel free to have a look at my entry for the last game jam. Here's the main.cpp (https://github.com/Hapaxia/BringItBack/blob/master/main.cpp). It may be quite long and uses a separate class to load into the sound buffer (the sound is called "activate") but you should be able to see that it does all of the loading completely before the main loop. A sound can then just be play()-ed when necessary.
I apologize if this post appears to not consider your last response, Hapax, you're so kind but I must paste prewritten posts on the run...OK I know my next stop is the system (window maybe more) module.
The biggest error was to be mistakenly convinced that due to the presence of the 'if (!buffer.loadFromFile("..."))' the buffer of the sound wouldn't be not only damaged but also repeated or born from zero.
That is precisely the reason
"if (sound.getStatus() != sf::Sound::Playing)
sound.play();
"
that brillantly was suggested gets its purpose defeated
I don't know why I was using 2,2 tuto but the only difference to 2.3 is that it doensn't specify the list of supported formats
Having read the system module, etc. I tend to think that the position of the main loop is for facilitate, among other things, space for events (through the event loop itself) and that's the reason you must not integrate the bulk of the code into the main loop.
But then it arises the question of what about the supervisor ( ...is that the name for the loop in wich the course of the game takes place? ).
Anyways, I want to think that if the buffers are not destroyed, the sound variables are available, and not only that, if there is playing any music, it arrives to the end if no method interrupts it. Another question is if you include all this in a thread and that thread is affected by something.
Am I in the right track?.
..so many thanks, I hope this solves initial doubts of mine and can focus on the provided links by Hapax
The biggest error was to be mistakenly convinced that due to the presence of the 'if (!buffer.loadFromFile("..."))' the buffer of the sound wouldn't be not only damaged but also repeated or born from zero.
That is precisely the reason
"if (sound.getStatus() != sf::Sound::Playing)
sound.play();
"
that brillantly was suggested gets its purpose defeated
Not really.
Your biggest error (to use your own words) here is to not realize a very basic C++ fact; that objects created in a scope, on the stack, get destroyed when that scope (in this case, the game loop) ends. This is very fundamental C++ knowledge and, had you had that knowledge, it would/should have made it obvious that the "sound" object would not live for more than a single frame. The if statement testing whether or not the sound is currently playing is completely irrelevant in that context.
Having read the system module, etc. I tend to think that the position of the main loop is for facilitate, among other things, space for events (through the event loop itself) and that's the reason you must not integrate the bulk of the code into the main loop.
But then it arises the question of what about the supervisor ( ...is that the name for the loop in wich the course of the game takes place? ).
The main "game" loop is what (in most games) drives everything. It is responsible for processing events, updating game state and rendering the current state of the world. It's what makes the game "tick".
The main game loop repeats over and over - every frame - and it's where you do all your processing. But, that doesn't mean that you need to create all objects within the loop. Long lived objects usually get created before the loop and persist for the entire lifetime of the application. Objects that need to be dynamically created (but need to live more than a single frame) are usually created on the heap and stored as std::unique_ptr or std::shared_ptr objects - commonly in STL containers like std::vector or similar.
Anyways, I want to think that if the buffers are not destroyed, the sound variables are available, and not only that, if there is playing any music, it arrives to the end if no method interrupts it.
You may think what you want. But that's just not good enough. You need to know how the lifetime rules for objects in C++ work.
As long as your sound object is alive and there's something to play in its buffer and play() has been called on it, it will play. But if you destroy the object (for example; by letting it go out of scope) or destroy the buffer it's playing from, then - surprise, surprise - it will stop playing.
Another question is if you include all this in a thread and that thread is affected by something.
Music already plays in its own thread. You don't need to worry about that... Please, please don't even consider threads until you have a much firmer grasp of C++ (I'd say at least 5 more years of experience or so).
Am I in the right track?.
Personally, I'd say no.
You seem to be guessing randomly and making assumptions that you have no basis for.
You should attempt to get a firmer grasp of the C++ language before proceeding or you'll only get yourself into trouble that you'll have no idea how to dig yourself out of.