Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not autoplay audio dweets #394

Open
joeytwiddle opened this issue Sep 8, 2018 · 10 comments
Open

Do not autoplay audio dweets #394

joeytwiddle opened this issue Sep 8, 2018 · 10 comments

Comments

@joeytwiddle
Copy link
Collaborator

@joeytwiddle joeytwiddle commented Sep 8, 2018

We can detect an audio dweet if:

  • It has been tagged #audio
  • It contains code Audio or SpeechSynthesis or ...
  • (It looks like it has a compressor, and the uncompressed code contains the above)
    But just the hashtag would get us 99% of the way

Behaviour: An audio dweet should just start off paused. There will be a 'Play' button the user can click if they want to start the dweet running.

Optional extra:

  • A 'Pause' or 'Stop' button that can stop all started audio.
    One way to achieve this might be to override the Audio and SpeechSynthesis` constructors with our own functions that call the original functions, but also keep a copy of the constructed object in a global array, so that we can stop them when the button is pressed.
    This might also be an advantage when someone is editing an audio dweet. When they change the dweet, our reset function can stop all the existing audio output, to provide a clean slate for the new version.
@kipkat

This comment has been minimized.

Copy link
Contributor

@kipkat kipkat commented Sep 8, 2018

That's easy to implement in js. Just get the comments using the api, check if "#audio" is there and delete the iframe autoplay attribute.

@lionleaf

This comment has been minimized.

Copy link
Owner

@lionleaf lionleaf commented Sep 8, 2018

Using #audio would definitely get us pretty close, as if the author forgets to add it somebody else could. However, I worry we could then get people tagging random dweets as "#audio" as to disable autoplay.

Regex matching on the dweet would also get us pretty far, it will catch most normal audio dweets, but if somebody wants to they could always evade it.

We could override the Audio and SpeechSynthesis constructors with something that automatically mutes the sounds and presents an 'unmute' button somehow?

@kipkat

This comment has been minimized.

Copy link
Contributor

@kipkat kipkat commented Sep 8, 2018

I suggest #pause instead of #audio. That will be good for massive dweets too!

@lionleaf

This comment has been minimized.

Copy link
Owner

@lionleaf lionleaf commented Sep 8, 2018

The more I think about it I don't want this to be tied to a normal hashtag. If it is manually tagged I think it should only be the author + moderators that can tag such dweets (with a report button for the rest). If not you might get people who aggressively add #pause/#audio to other people's dweets against the will of the author in cases were it's not needed.

Also, @kipkat, slow dweets already time out :)

@kipkat

This comment has been minimized.

Copy link
Contributor

@kipkat kipkat commented Sep 8, 2018

we can create a new concept, ##onlyCreatorHastag that prevents griefers from spamming #pause if you ##pause

@joeytwiddle

This comment has been minimized.

Copy link
Collaborator Author

@joeytwiddle joeytwiddle commented Sep 9, 2018

If we want to do everything through hashtags:

  • We could make #pause/#audio work automatically only if the comment was from the dweet author, or from a moderator.
  • If other users comment #pause/#audio then that could act as a report.

There are actually multiple reasons we might not want to autostart a dweet:

  • Pre-pausing #audio dweets (except I think we should just do that with #audio, more semantic)
  • Pre-pausing #heavy dweets (although the loopbuster does help with this now)
  • Pre-pausing flashy dweets, to assist epilepsy sufferers (default to true for Xen of course)
  • Pre-pausing dweets so the viewer does not miss the start of the animation. (I can think of a couple of dweets where that might apply, for example a dweet with a story which runs only once, requires full attention.) Although a restart feature would make that redundant.
@kipkat

This comment has been minimized.

Copy link
Contributor

@kipkat kipkat commented Sep 9, 2018

Another trick is to use

c.onmousemove=e=>{X=e.x};X;

to make the dweet play only when mouseover.

@joeytwiddle

This comment has been minimized.

Copy link
Collaborator Author

@joeytwiddle joeytwiddle commented Oct 17, 2018

Anyway I don't mind if this is a checkbox for authors and a report button for users, instead of hashtags. But that would require touching python and adding some new things to the DB! 😱

How should we arrange the DB fields? Here are some possible alternatives:

  • autoplay: true
    Defaults to true. We would need to migrate older dweets, or inject a default on retrieval.

  • autopause: false
    Will create double negatives, but it may be convenient to have a falsey default.
    Alternative name: pauseAtStart

  • autopauseReason: 'audio'
    A field to record why we pause it. In this case we won't need a boolean field.

  • autopauseReasons: ['audio', 'heavy', 'flashy']
    An alternative if we want to record multiple reasons why.

Should user reports be kept in a separate table? I guess so.

report: {
  reporter: 'u/katkop',
  date: 13431413,
  dweetId: 123,
  concerns: ['audio', 'flashy', 'heavy', 'made_by_xen'],
  status: 'accepted', // or 'pending' or 'rejected'
}

If we do require a reason not to autoplay, then we might also want a generic reason, for any cases we haven't considered.

@KilledByAPixel

This comment has been minimized.

Copy link
Collaborator

@KilledByAPixel KilledByAPixel commented May 28, 2019

This would be good, because I'd like to see more audio dweets. I started to address this issue from within Dwitter by creating a small audio libary called DOMP.

https://www.dwitter.net/h/domp

@KilledByAPixel

This comment has been minimized.

Copy link
Collaborator

@KilledByAPixel KilledByAPixel commented May 28, 2019

Domp handles starting and stopping audio when clicked on as well as some other handy stuff.

Would it be possible to have Dwitter create an default audio context the same way it creates a canvas context? It's basically the same thing as the canvas but for audio. This could give dwitter more control while also allowing more space for audio code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.