Gathering /sound's channels

ID:1762132
 
Jan 13 2015, 11:47 pm
Keywords: channel, gather, sound, system
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
Currently when you assign a /sound datum a channel value of -1 (and 0 I guess though I haven't tried), so it assigns the first available channel, the /sound 's channel var is still -1.

What I request is that that variable updates once the channel has been assigned.

proc/outputSound(client/client)
        var/sound/sound = sound('somesound.wav')
        sound.channel = -1
        sound.repeat = 1
        client << sound
        return sound

client/proc/test_theThing()
        var/sound/sound = outputSound(src)
        sound.environment = 6
        sound.status |= SOUND_UPDATE
        src << sound


Since channel is set to -1, executing test_theThing() will produce two sounds playing at the same time, which is awkward.

If right after assigning a channel, that datum's channel var is set to the channel assigned, the next time you update said datum, it will update as expected.

I think I have correctly exposed the fact there, if something needs clarification please tell.
Jan 14 2015, 12:10 am
Wait, -1 isn't a valid sound channel. What's going on?
Jan 14 2015, 12:12 am
Wait, it isn't a channel. xD

When you set channel to -1, it assings the first available channel when the /sound datum is sent to the client.

Directly from the reference:

For sound effects, set to 1 through 1024 to choose a specific sound channel. For values of 0 or less, any available channel will be chosen. If you play a null sound (no file) on channel 0, the settings for the datum will affect all channels.
Jan 14 2015, 12:24 am
In response to Fushimi
Ugh. The entry for sound() says 0 (not 0 or less) or 1-8 (not 1 to 1024) and I didn't check the entry for channel. My bad...?
Jan 14 2015, 12:33 am
I know that sound stated 1-8 and 0, but it is as true as that channel states 1-1024 and 0 or less.

We can get out of doubts by doing a small test, let me edit on a few.


EDIT: Verified, there are 1024 channels, or at least it automatically sets to the 8th channel, I cannot tell.

Small environment: https://www.dropbox.com/s/d81q9nknj6nj3cn/test.zip?dl=0
Jan 14 2015, 6:13 am
Updating the var requires the client to send some info back once the sound starts playing, which isn't necessarily feasible. Plus, when you output a sound you effectively output a copy of the datum, not the actual datum itself; you can reuse the same datum and make changes to it and send it again to do something completely different. Because of this, there's no clear way to tell which datum should be updated.

Also if we weren't using the copy system, that means that if you set channel=0 and output a sound, and the datum's channel var got changed, subsequent outputs of that same datum would then be locked into that same channel--not a desirable outcome.
Jan 14 2015, 9:58 am
I imagine that sending the sound to multiple players at once could potentially result in the sound being played on different channels for each player, depending on what other sounds are playing for each at the time.
Jan 14 2015, 10:20 am
So basically when channel=-1 the channel is actually assigned on the client side.
For some reason I thought it would be assigned internally before it was sent, seems it is not the case.

However I expected such scenario and did a workaround for what I had in mind, it's just that this feature could have done it much more easier.

Anyways, request apart, could you clarify how many channels there are? (As Kaio and I where wondering on how the documentation contradicts itself)

I'd stick with the part that says 1024 channels, but not sure to be honest, either that or one from 1-8 is picked when value is higher than 8.
Jan 14 2015, 10:58 am
In response to Fushimi
Fushimi wrote:
So basically when channel=-1 the channel is actually assigned on the client side.
For some reason I thought it would be assigned internally before it was sent, seems it is not the case.

It could never be that way, because 0 means any free channel. The server has no way of knowing which channels are free; only the client knows.

Anyways, request apart, could you clarify how many channels there are? (As Kaio and I where wondering on how the documentation contradicts itself)

I'd stick with the part that says 1024 channels, but not sure to be honest, either that or one from 1-8 is picked when value is higher than 8.

The 8 is from an older setup and is no longer valid; not changing it was an oversight. 1024 is correct. Although truth be told, the true limit on channels depends on the sound card and such. Our code simply maps from a user-defined channel number to whatever the sound engine chooses.
Jan 14 2015, 12:07 pm
It sounds like you could do something very similar to what was done for the mouse procs, and have some kind of client.Listen() proc that gets called whenever a sound is output to a user. The Listen() proc's arguments would hold in some form, the values of the actual live sound datum's vars. This means you could override client.Listen() to determine what channel any given sound is being played on, and do something based on that.

Is this a good idea? I'm sure it could have all kinds of other uses.
Jan 14 2015, 1:18 pm
In response to Multiverse7
The mouse procs are all input; they're built around sending data to the server. The sound foo is currently strictly output, and isn't intended to send anything back. The client would have to send back info, and there'd really be no way to correlate it to what was output--which would be far, far more trouble than it was worth.

Interestingly though, I think allowing the webclient to hook various sound events is a pretty good idea. It would be fairly simple to setup hook functions that could be overridden in a control or by JS in the skin, and that could be of use to people. I suppose in those cases a developer could always decide whether they want anything back or not. A hook setup might also be good in case the sound format is one that the browser can't use or that isn't recognized by our external libraries, which might allow the developer to handle it with a fallback.