Volume control about cassette

[pablopaul]

Yeb, I woud like it. Thanks for looking into it 👍

[benwiley4000]

Seems like this is something worth supporting since @RageMaster14 has also requested it in #30.

One of my hesitations in building this straight into the player component is that I want the use of this player to be flexible, and I'd like to not lock users into one particular look/style.

That said, I'm considering make each button/interactive piece its own React subcomponent, which can be overridden if another is specified. Each component would accept relevant props passed from the AudioPlayer render method, like paused and onTogglePause for a PlaybackControl, or volume and onVolumeChange for the proposed VolumeControl. Any component implementing these props could fully control a function of the player in a custom fashion.

A subcomponent approach would also give us the opportunity to let the user specify a custom button order.

Example:

import React from 'react';
import ReactDOM from 'react-dom';
import AudioPlayer from 'react-responsive-audio-player';

const playlist = [/* ... */];

const VolumeControl = ({ volume, onVolumeChange }) => (
  <div className="volume-control">
    <input
      type="number"
      value={volume}
      onChange={e => onVolumeChange(e.target.value)}
    />
  </div>
);

ReactDOM.render(
  <AudioPlayer
    playlist={playlist}
    volumeControl={VolumeControl}
    controlOrder={['playback', 'forward', 'track', 'volume']}
  />,
  document.getElementById('audio_player_container')
);

Any thoughts?

[RageMaster14]

@benwiley4000 I like your approach on coding every component to be as flexible as possible.
I also like the idea of the user to be able to use his own button order.
As well as the custom button configuration.
That in mind what you are going to achieve is not only a responsive design but also the ability for users to craft their very own unique designs.
Will be keeping an close eye and hoping you finish it soon fingers crossed.

[benwiley4000]

@RageMaster14 I think I'd prefer to stick with just one default component, but give users the option to provide a different component suiting their needs. The component should be stateless, depending on the parent. I think the props it should receive are:

• volume (number from 0 to 100)
• muted (boolean, independent of volume but will be changed to false if volume slider dragged during mute)
• onVolumeChange (function, called whenever volume slider is dragged with new volume value)
• onToggleMute (function, called whenever mute toggle button is clicked, except on mobile when the click event is being interpreted as a hover to open the slider. no arguments)

I think the YouTube slider component you shared is a good model to go off of, though that particular implementation definitely needs some work for mobile (it should support dragging, not just clicking, since it's virtually impossible to bring the volume back up to 100% on a mobile device without dragging).

P.S. If you'd like to try out an implementation go for it!

[benwiley4000]

Good question - I had thought about it but hadn't "made plans" yet. If it's a feature you'd like I can try to get to it in the next week. 😃

[benwiley4000]

Just to update - since all UI buttons are CSS-based, I'm probably going to use a variation on the volume icons here: http://saeedalipoor.github.io/icono/

My initial thought was to have click-to-toggle-mute, and hover-to-show-volume-slider. The volume slider would appear vertically above the icon. The trouble with that is that it wouldn't be totally responsive - making crucial UI elements active only on hover is inherently non-responsive since it won't work with a touch device.

One option would be to make clicking the button activate the slider, and to eliminate the ability to mute without moving the slider. I don't particularly like this, because I like the ability to mute.

Another option is to make the button ONLY mute, and avoid having the volume slider, which is how a lot of players work, but it might be less control than you're looking for.

Finally, we could decide we're ok with mobile users not having access to a volume slider, but I don't like interfaces that offer expanded functionality on particular platforms.

What do you think? @pablopaul

Feel free to offer examples of interfaces you like on mobile and desktop.

[benwiley4000]

@pablopaul wanted to ping you again for feedback, since this was your request.

[pablopaul]

@benwiley4000 I think just a "mute" control is not really enough, I often tend to adjust volumes of audio / video.

I really like the dead simple approach Vimeo takes on the topic:

Please note that I moved away from using react-responsive-audio-player since my current implementation somehows interferes with how react-responsive-audio-player implements props updates.

[benwiley4000]

@pablopaul Sorry for not seeing your response earlier. I like Vimeo's approach - thanks for sharing it!

Could you elaborate on the problem you describe with prop updates?

[pablopaul]

@benwiley4000 I can try to reproduce the problem and I cant not guarantee any time frame 😸

[benwiley4000]

@pablopaul Sure - but in the meantime would you be able to describe the problem in general terms? I'm just trying to understand what you mean when you refer to implementing prop updates. React should be re-rendering the component whenever you change prop values - which is up to your parent component.

[pablopaul]

@benwiley4000 you are right, in this was somehow interfering with the audio player and I cant remember any helpful details at the moment because i did not understood the problem totally… sry.

[benwiley4000]

If you were somehow able to provide a code example from an older commit -
even an excerpt though a working project would be great - I would be very
appreciative.
On May 19, 2016 12:02 PM, "Paul Vincent Beigang" [email protected]
wrote:

@benwiley4000 https://github.com/benwiley4000 you are right, in this
was somehow interfering with the audio player and I cant remember any
helpful details at the moment because i did not understood the problem
totally… sry.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1 (comment)

[benwiley4000]

Adding hacktoberfest label - if anyone feels like offering a solution, please discuss your plan before submitting your PR. 😄

[benwiley4000]

@RageMaster14 I think it would be worth providing a default implementation. I'm still not sure what it would look like, but what do you think of the options I discussed earlier in the thread? Also, I'm open to other suggestions. If you know of any great desktop and mobile friendly solutions out in the wild, please flag them for me. 😄

[RageMaster14]

@benwiley4000 From a responsive stand point there are a few designs you could go for. The very popular one is the (side-to-side upon hover). Kind of the one Youtube has at the moment. (a link to the design and functionality: https://codepen.io/garethdweaver/pen/EjqNxO ). It is responsive and it goes well with the design. But if you prefer for multiple types and for the user to pick one and or create their own I could whip something up. Basically the functionality would be like the link above with a few designs matching your current player styling.

[benwiley4000]

@pablopaul, I think the issue you mentioned about prop updates may have been resolved by #10, now that I think about it.

[RageMaster14]

@benwiley4000 I cant wait till you implement the volume. This is by far one of the most interesting projects on GitHub and it's worth the wait.

[benwiley4000]

@RageMaster14 haha, thank you. I've been working on converting the controls to separate components this weekend.. you can see the work in progress in the modularize-controls branch. There will be some breaking changes requiring a new major release.

[benwiley4000]

@RageMaster14 see: the ongoing work in #42.

[benwiley4000]

The volume control is now available to try in the next branch. It will ship with 2.0. Note that a volume control is not rendered by default - 'volume' must be passed in the controls array prop to AudioPlayer.