calebmer / decode-universe Goto Github PK

Sometimes it may take a bit for a peer to start recording. Let the host know if a peer is not recording, or timeout a peer who is taking too long to start.

This, of course, should be done after #6.

We should be recording the chat room if the host has started a recording! This will allow users to create live show notes. For example, if the guests need to let their editor know something then they can add a message in the chat which will be exported with the audio.

When exported we should add a timestamp to every single chat message to know exactly when it was sent.

This means adding assets like fonts as dependencies and shopping polyfills to not depend on http://polyfill.io/.

Add marks for whether the user is hot or cold to this meter. The worst a user can be is 0 dB. -12 dB is right where the user should be. -24 dB is the lowest that a user should be (cold). See the levels/gain meter in Garage Band and Logic for an example.

The key m should toggle whether or not the guest is muted.

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because we are using your CI build statuses to figure out when to notify you about breaking changes.

Since we did not receive a CI status on the greenkeeper/initial branch, we assume that you still need to configure it.

If you have already set up a CI for this repository, you might need to check your configuration. Make sure it will run on all new branches. If you don’t want it to run on every branch, you can whitelist branches starting with greenkeeper/.

We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

This will require some kind of room state that the host can control.

As a part of this we should also provide a timer that counts up after the recording has started.

Allowing users to communicate by text while recording is incredibly powerful!

We need UI for users to select the audio they want to export and to listen back to a recording. Currently I do this manually. While doing this I also want to refactor the file system storage code.

Make it look pretty.

One high leverage thing we can do to provide a better audio quality is give users a preparation checklist before they can connect to a recording room. We want to give users a reason behind each item so that they will be more motivated to listen.

While a user is going through the checklist we should tell the other hosts and guests in the room that they have connected, but are currently setting up.

Some ideas for the items on that checklist:

• Check for clipping. Ask the user to read from a script and watch their audio visualization. If they are too high or too low they should either adjust their volume or their distance from the mic. We should also let the user know when they are clipping while they are recording. NOTE: if possible the user should be changing the gain on their mic!!! Not the gain slider we provide.
• Check for cross talk. Ask the user to play some audio. If that audio shows up on their audio visualization then ask them to configure different settings. Some ways to stop cross talk are to enable echo cancellation (Chrome only), lower the volume on your computer, or put in headphones. Headphones are the best option!
• Check if there is any background noise. This will show up as some constant movement on the user’s audio visualization. If the user can easily turn off that noise (fans, air conditioning) this will help them know that.
• Silence your phone and computer.
• Turn off Dropbox or anything else that is hogging bandwidth.
• Make sure you have enough space on your computer to record (host only).

We want to report any errors that happen to users which we can’t handle. This keeps us honest and gives the user words for any weird things that happens in the app.

This means creating something an ExceptionReporter singleton and call that wherever we call console.error(). When replacing console.error()s with better exception reporting we should also do an audit of all points where there may be an error.

Some of the default audio filters that we should apply. These filters are optimized for users recording at -12 dB otherwise they won’t work very well. All of these options should be toggled with a single click before exporting.

• Highpass filter to remove frequencies below 80hz.
• Compressor. See below for Aaron Dowd’s compressor settings. Use those.
• Limiter. Output ceiling -0.8

I’ve played around with enabling and disabling echo cancellation. This option should be configurable. Let the user decide! By default it, perhaps, should be disabled.

Sometimes it is useful for a host to generate a room URL that they can give their guests before an interview. Instead of generating a new room on the fly every single time.

This will need some kind of host to guest “command” system. Or we can use room state to implement this.

This happens when we have connected to a peer over the signaling server, but may have never established an RTCPeerConnection. We should probably look for ways to timeout those peers who we send offers to, but never hear answers back.

We need an answer to this question.

If a user connects with a browser that is not supported then we should let them know instead of providing a cryptic blank screen or error message.

We use polyfill.io for standard library features in ES2015+, but there are some DOM APIs which we just can’t polyfill.

Things that we should check support for:

• AudioContext: We need the web audio APIs for audio recording and playback.
• RTCPeerConnection: We need this for peer-to-peer realtime activity.
  • RTCPeerConnection#addStream(): Some browsers don’t support addStream() for an addTrack() based API instead.

Especially in beta we need to be able to update the desktop app without requiring users to reinstall.