Speaker polyphony not working as expected
miiichael opened this issue ยท 8 comments
Hello, cc-tweaked-1.12.2-1.84.0 user here.
While attempting to play a chord, I noticed that my computercraft programs are only able to initiate one sound per tick, despite the impression that max_notes_per_tick (untouched from the default value of 8) gave me. ๐ค
Example program:
speaker=peripheral.wrap("left")
n=5
s=nil
for i = 1,n do
p=0.5+1.5/(n-1)*(i-1) -- span full working pitch range
if not speaker.playSound('minecraft:block.note.pling',1,p) then
print ("playSound",i,"failed!")
end
if s then sleep(s) end
end
For me, this program outputs:
playSound 2 failed!
playSound 3 failed!
playSound 4 failed!
playSound 5 failed!
Generally, adding any sleep() at all seems to largely eliminate any polyphony limits, though I notice I do occasionally see random playback failures in single player mode.
So the problem here is that the max_notes_per_tick
option refers to notes (those played with playNote
), rather than sounds. While you can have 8 notes per tick, you can only play a single sound.
In this case, switching the call to playNote("pling", 1, p)
should work.
Oh, you're right! I had assumed one was just a simple wrapper around the other. Lucky the warning sounds I wanted my reactor to make are in the notes directory...
Should I assume the lack of playSound polyphony is a forge/Minecraft limitation rather than a CC limitation? If not, I have a feature request...
Should I assume the lack of playSound polyphony is a forge/Minecraft limitation rather than a CC limitation? If not, I have a feature request...
It's an intentional design decision. Because you can play arbitrary sounds with the speaker (including jukebox songs, which last several minutes), there's a very limited form of rate limiting, namely the one-sound-per-tick limit.
I'll be the first to admit that it's not perfect, however I don't think we've ever found a more satisfactory solution :/.
Is there a way to find the length of a sound and prevent the speaker from playing too many at once?
Not on the server, no. IIRC, resource packs allow you to change sounds too, so they're not guaranteed to be a specific length.
We could add a client specific limit - so you don't receive an error on the server, but it stops the oldest sound if you have more than "n" playing at a time.
The limitation seems not unreasonable, which I guess makes this a documentation update request. Hmm, there are no plans to fork the wiki as well as the code, are there? :P
There are! Documentation is a bit of a mess right now (see #133), but there's a couple of versions of the wiki:
- On GitHub: It looks like it doesn't actually mention the rate limits at all - it just describes the API. It'd definitely be worth expanding that.
- On computercraft.cc: This is a copy of the above, so same applies :).
I've updated the documentation on GitHub, which hopefully clarifies things a little. Let me know if there's anything else you'd like me to change.