Soundboard

In the last post I described my requirements for Soundboard app. Now it is time to decide what can be considered the minimum viable product.

Milestones – first try

Milestone is a specific point of high importance or impact in a project. Taking into account the requirements I wrote down in the last post, I would split them into the following categories:

Audio processing

Play a sample

Stop a sample

Stop all samples

Loop a sample

Mix multiple samples

Set volume for a sample

Option to stop a sample, if another is started

Option to lower volume of a sample, if another’s is gained

Sample sources

Play a sample from an mp3 file

Play a sample from an acc file

Play a sample from a flack file

Play a sample from an internet stream

Soundscapes

Group samples

Group scenes

Save soundscape’s metadata to an archive

Save soundscape’s metadata and samples to an archive

Save soundscape’s samples in order

Load a soundscape from an archive

Load soundscape’s samples in order

Scenes

Save samples’ play state

Load samples’ play state

Save samples’ volume

Load samples’ volume

Save samples’ correlations

Load samples’ correlations

User interface

Touch events served

Soundscapes list

Soundscape view

Scenes list in a soundscape

Text label for a sample

Text label for a soundscape

Text label for a scene

Image label for a sample

Image label for a soundscape

Image label for a scene

From now on, the highest hierarchy items could be milestones all by themselves. In my opinion though, although completing such a milestone would mark a significant step in the application development process, it does not represent a high impact functionality leap, as the application after reaching such a milestone is not usable at all.

Milestones – MVP

The first milestone in the project I write will be met, when I will be able to use my application at the RPG session. That first testable version of an application is called the minimum viable product. It has all the necessary features implemented, so it may already be used in the target environment. In my project that would mean, that considering the audio processing, the app is capable of playing/stopping a sample and looping a sample. For a sample source I choose the file source, as I think that it will be easier to implement. Also, for my MVP I will limit myself to one file type, the mp3 should do the work for now. Saving the samples will be required later when I implement the soundscapes. I completely do not care for soundscapes and scenes . For now, all I need is to be able to play samples, even ungrouped. Last but not least, the user interface I need for now is limited to samples grid, play/stop buttons for the samples and text labels for the samples.

Summary

That is all for today, the first milestone is defined. Now I will add it the Gitlab issue tracking and I am ready for the development.

In the next post I will describe the project set-up and project structure.

I can’t imagine the world without music. I listen to it all day round and everywhere I go.

The need

Most recently I started an RPG campaign in which I am playing the role of the game master. In the myriads of things to prepare, the music was one of the first I though of. I’ve searched the web for a suitable piece of software and found out, that there is none that is touch friendly. In my opinion it’s crucial to have one, because during the session you have to switch the background music in a blink of an eye. There is no time to waste on searching for the mouse, then moving the cursor to a small play icon. On the other hand, although all the apps I found could be interacted with by touch interface, they were not designed for that purpose. So again, too small icons require the precision that is not achievable during the session and on the touch screen itself. What I need then, is an app that displays large sample icons that may be easily triggered by finger.

Requirements

The piece of software I write has to meet some requirements to be functional and operable.

First of all, as an audio processing app it has to be able to play single sounds, then to mix them. For shorter samples it has to be able to loop them. Also, some samples such as birds singing or water droplets falling from the cave vault must be much quieter than others for example the river or heavy traffic so the app is required to set volume for each sample. At first, I though that the app should have a master volume control but then I decided that every modern operating system already has a built-in master control so implementing it in my app would be a waste of time. The next thing to do would be to add a correspondence options between the sounds. What I mean is that, if one sound is played, the other should be turned off, or if you gain the volume of one, the volume of the other should be lowered.

Regarding the source of the sounds, I decided that my app should be able to play samples from an attached data storage and internet streams. Supported formats would be mp3, acc and flack.

In an RPG game players often change their location, let’s say they start in the forest, then get to the city where they find that the villain they are chasing has a secret base in a closed mine. Each of these sceneries has different background sounds. For example, in a cave you can hear bats squeaking, water drops and rocks sliding, but in a village there should be some crowd noises, a hammer hitting an anvil and sometimes a carriage riding on a paved street. I call these sceneries soundscapes. A soundscape is a group of samples that fit a scene. There should be a way to save and load a soundscape. While saving, there should be an option to save only which samples are used (metadata) or both the soundscape’s metadata and samples in one archive. While loading soundscape, samples should be positioned in the same place where they were during saving. There should also be a way of saving actually played sounds in a soundscape as scenes. For example, the soundscape is ‘the city’, the scene is ‘harbour’, ‘marketplace’, ‘administration building’ or ‘night’. They all share a set of samples used, but with some small differences in volume. Also, not all samples are active in a scene, but they are the same in the majority of scenes in a soundscape.

Last thing to discuss is the UI. As I wrote earlier, I want to use the app on a touch-enabled device, so I decided that the app’s interface will be using tiles for samples and tabs for soundscapes. Both the soundscape and the sample button should have a text name and an optional image. I am not yet sure how to orchestrate the scene interface so this topic will be considered later in development.

What’s next?

The requirements above are a mix of obligatory and ‘nice to have’ functions. In the next post I will create the vision of the minimum viable product – the very basic functionality the app has to offer to be considered done and usable.
Image: Sombre by Philippe Rouzet