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

Library Design #15

Open
julmb opened this issue Sep 20, 2023 · 1 comment
Open

Library Design #15

julmb opened this issue Sep 20, 2023 · 1 comment

Comments

@julmb
Copy link

julmb commented Sep 20, 2023

I have recently started using this library and I like how simple it is, and I think it is great that it works across all major operating systems.

However, I think the library design has some shortcomings.

  1. Some functions that can fail will not indicate this at all and just fail silently. For example, loading a sample using sampleFromFileSource on a file which does not exist will not fail, but just result in no sound being played. This makes it very difficult to find issues. Calling initAudio twice should maybe also cause an error, but it does not.
  2. Many of the functions that can fail will just return IO Bool. If they return False, it is impossible to know what went wrong.
  3. The library does not protect the user from executing commands in the wrong order. I was really surprised to find out that the function loaderAvailable could not be called before initAudio. Additionally, it only returns IO Bool (see point 2) so there is no indication that lack of initAudio was the problem. If initAudio were to return something like an opaque AudioContext that is needed to use loaderAvailable, then the user could not use loaderAvailable before initializing the audio system.
  4. Maybe as an even stronger version of point 3, it might be good to provide a bracket-like version of handling the audio system. Something like withAudio :: (AudioContext -> IO a) -> IO a that initializes the audio system, runs the given function, and then cleans up the audio system. This would make it impossible to forget to clean up the audio system. Similar logic would maybe apply to Sample.
  5. It is difficult to get information back out of the system.
    • The types Sample and Sound are opaque and do not have Eq or Ord instances.
    • There is no way to find out which Sample corresponds to a given Sound.
    • There is no way to find out which channel a given Sound is playing on.
    • There is no way to find out which Sample or Sound is playing on a given channel.
    • There is no way to find out if a given channel is currently playing.
    • There is no way to find out if a given channel is currently playing or looping.
    • There is no way to find out what volume a given channel is playing at.

I know this is a lot of criticism, but I am really not trying to be rude. Instead, I want to make suggestions because I think this library is important and I want to help make it better.

It is also very possible that there are good reasons for why things are the way they are or that I am mistaken, so please let me know what you think.

@csabahruska
Copy link
Owner

Hi, thanks for the feedback. Could you write down the type signatures of your API design please? Something similar to this: https://github.com/csabahruska/proteaaudio/blob/master/chs/Binding.chs

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

No branches or pull requests

2 participants