A couple suggestions

[GraphicsWhale]

In hope that this is still a discussion and not an argument...

I don't consider this an argument. Maybe a debate. But that isn't exactly a bad thing.

for their usage, this should at least be sf::OpenGlTexture, right?

As I said, I'm not for unreasonably "correct" names.

I have no problem with sprite. I think you again misunderstood what I was saying.

You were trying to make a point by giving a slightly extreme example, yes?

Thanks 

The source does not compile (dependencies on missing headers). Could only "play" via looking at the code and imaging what could've been. 2/10

[select_this]

I think we've got all the mileage we can get over potential name changes for audio classes; I'm sure the SFML team have enough pro and con arguments to make a final decision and close the matter.

It's good that many people are taking such a keen interest in the development of the library itself, and it's clear that there's a lot of passion for it.

[Hapax]

I'm not for unreasonably "correct" names.

This is what I would consider sf::StreamedAudio to be when used for music.

Thanks 

The source does not compile (dependencies on missing headers). Could only "play" via looking at the code and imaging what could've been. 2/10

I don't think you should vote for something you haven't tried 
Missing headers? These?
https://github.com/Hapaxia/Dev
https://github.com/Hapaxia/Plinth
https://github.com/Hapaxia/Kairos

I think we've got all the mileage we can get over potential name changes for audio classes

I beg to differ:
sf::SampledSound, sf::Sample, sf::Soundtrack, sf::SoundEffect, sf::AmbientSound, sf::Ambience, sf::Ambulance

[GraphicsWhale]

I beg to differ:
sf::SampledSound, sf::Sample, sf::Soundtrack, sf::SoundEffect, sf::AmbientSound, sf::Ambience, sf::Ambulance

To be perfectly honest, if you came up with a name for every single possible usage, I wouldn't even be upset. I'd be a bit like: "do I want a sound track? sf::SoundTrack.. what about sad music? sf::SadMusic, maybe even throw a bit of sf::JustinBieber in the hell level". 

[Hapax]

How's this?

namespace sf
{
    using StreamedAudio = Music;
    using SoundTrack = Music;
    using SadMusic = Music;
    //using JustinBieber = Music; // this would be just plain wrong
}

[Tank]

maybe even throw a bit of sf::JustinBieber in the hell level]maybe even throw a bit of sf::JustinBieber in the hell level

Hehe.

The discussion about sf::Sound/sf::Music is quite interesting. I'd like to propose to merge sf::Sound and sf::Music into one class, e.g. sf::Audio. GraphicsWale mentioned the LÖVE2D example, and I think they are going into the right direction.

Take a look at the APIs of sf::Sound and sf::Music, and you'll see that they are very similar to each other. But more importantly, they do the same thing: Loading and playing audio samples. If those samples are streamed or buffered is at most an implementation detail and class property.

However, thinking more about it, and also in relation to the sf::Window/sf::Graphics thing (which I completely like, because it would probably also mean that context creation is explicit rather than implicit, unlike currently), the case for sf::Audio could be incredibly easy to understand and use:

sf::SoundStream music_source("music.ogg");
sf::SoundBuffer sound_source("effect.ogg");

sf::Audio background_music(music_source);
sf::Audio effect(sound_source);

For sf::Sound/sf::SoundBuffer, it already works exactly like in the code above. For sf::Music, it could work similar. This does greatly split areas of responsibility and thus enhance modularity: sf::Audio shouldn't be bothered with the source. It's just the class that takes samples from an arbitrary input and processes them for playback.

We'd be left with one class that plays any audio, and two classes for possible sound sources. As both are sources, different names than "SoundBuffer" and "SoundStream" (e.g. AudioBuffer, AudioStream, StreamedSource, BufferedSource, BufferedAudio, StreamedAudio) might be chosen.

[Nexus]

Tank, that sounds like an interesting approach; I'm glad we're back to a useful discussion again after that page-long naming debate It would also get rid of the inconsistent sf::Music design which is currently both resource and resource user in one class.

However, it's probably not as easy as it first sounds. Unlike sf::Texture, sf::Font, sf::SoundBuffer and sf::Shader, the sf::SoundStream class (proposed by you, not the current one) is not a real resource, because it carries state about audio playback. That is, you have an implicit (thus subtle) circular coupling between a sf::Audio instance and the sf::SoundStream it is using.

In particular, you cannot reuse a sf::SoundStream instance for multiple sf::Audios, which negates a main advantage of splitting the classes. In addition, you cannot const-qualify sound streams.

What might be possible is that a sf::SoundStream is merely an abstract description of a sound source (file, memory, ...), and for each sf::Audio instance that uses it, it internally creates an actual stream carrying the state of the sound. On the other hand, I wonder whether this is useful in practice, as streams are primarily used for music, and usually, only one music theme is played at a time.

[Tank]

because it carries state about audio playback

I thought about this, but I think that wouldn't be the case. Wouldn't the state be in sf::Audio? The SoundStream would just be told to deliver X samples from position Y.

I haven't thought very deeply in terms of implementation, so this might have flaws. Just giving out ideas right now.

[Hapax]

Would it not be possible to just add on sf::Audio as a wrapper for sf::Sound or sf::Music? That way, it could abstract away the concept of the different types but would still allow direct usage of sf::Sound and sf::Music, which wouldn't break any current code. It could then be implemented before v3.

[Tank]

For me, that sounds like an unnecessary hack.

[Laurent]

The SoundStream would just be told to deliver X samples from position Y.

It already exists: sf::InputSoundFile.

However, if a single stream / sound file is shared among multiple musics, it will have to seek a lot, which can be very slow (or even impossible) depending on the underlying stream. Currently, only sequential reading is used by sf::Music. It would also have to be thread safe, but that's a different story

[GraphicsWhale]

However, if a single stream / sound file is shared among multiple musics, it will have to seek a lot, which can be very slow (or even impossible) depending on the underlying stream.

Maybe have a max amount of "clients" for the stream, depending on the platform's limitations (or some fixed number)? Probably not the best solution, but an idea.

Speed shouldn't be a concern. There's nothing stopping anyone from creating a million sf::Musics and streaming them all to the same file with the current system. Just like how you should warn against creating loading a really large file into an sf::SoundBuffer, you could simply warn against having too many sound instances trying to stream from the filesystem.

[Tank]

However, if a single stream / sound file is shared among multiple musics, it will have to seek a lot

There's nothing stopping anyone from creating a million sf::Musics and streaming them all to the same file with the current system

Nothing more to add.

It already exists: sf::InputSoundFile.

Yeah, I was aware of that, but I don't know how good it'd fit into my proposal, so I came up with something generic instead.

[Laurent]

There's nothing stopping anyone from creating a million sf::Musics and streaming them all to the same file with the current system

But with the current implementation, each music will create its own instance of the stream and read it sequentially.

[Nexus]

There's nothing stopping anyone from creating a million sf::Musics and streaming them all to the same file with the current system.

I'm not sure if the file access is thread-safe.

And I'm pretty sure that memory and sf::InputStream access is not -- simply because the user doesn't explicitly declare shared resources, and the implementation can't know.


A sequentially reading implementation sounds good to me. As Laurent says, seeking is expensive or impossible (for custom input streams)... If the same resource is played multiple times concurrently, SFML may allocate some overlapping samples, but that's not a concern in my opinion, especially since it happens really rarely for big files. As I mentioned earlier, one possibility would be an abstract stream with multiple clients, one per sf::Audio instance using it.