This naming scheme was garbage and always tripped me up. In favor of
having a more intuitive (and less _technically_ correct) interface,
we'll swap the name up.
Previously the signal for when BufferedOpusEncoderPlayable was
completed, was when the encoding process finished. However considering
we buffer the encoding, this would cause the playable to complete 4096
frames before it was actually done. We now properly just enqueue a None
(aka complete signal) when encoding is done, so that playback will
complete fully.
- Use print function for nacl library warning
- Use BufferedIO instead of StringIO on Python3, we're dealing with
bytes here
- Fix MRO issue w/ BufferedOpusEncoder
- Fix race condition on loading url information within YoutubeDLPlayable
Its valid for a user mention to be sent and parsed when a nickname
mention is expected. As such we should filter both from the message
contents to avoid message processing issues.
There where various oddities and bugs here, namely:
- Guild kept its initial `presences` list even though this is basically
useless, and was never kept up-to-date
- State did not properly use all the fields of presence_update, and was
creating some annoying recursive oddities w/ user and presence binding
* First pass at voice sending
* more voice
* Refactor playables a bit, general fixes n stuff
* Cleanup
* Voice encryption, dep version bump, etc fixes
* Remove debugging, don't open a pipe for stderr
* Refactor playables
This is still a very lose concept, need to think about what the actual
differences between encoders and playables are. Also some rough edges in
general with the frame/sample calculations.
However, this still feels miles ahead of the previous iteration.
* Properly reset state when resuming from a pause
* rework playables/encoding/etc a bit
* Add a proxy, allow for more pipin'
* Cleanup, etc
* Fix resuming from a pause lerping music timestamp
* Fix some incorrect bounds checks, add MemoryBufferedPlayable
GUILD_UPDATES are cool and special and of course they are partial.
Although this is logical, our type/models autoinitialize some fields by
default (which is actually fairly sane). However when this happens, we
smash these new blank mappings over the previously updated state.
Instead we should just ignore fields that don't come in GUILD_UPDATEs,
and save our state.
Andrei
Andrei Zbikowski
Jamie Bishop