:: BEAST :: :: Better Audio System ::

Beast Use Cases

From Testbit Wiki

Jump to: navigation, search

Use cases for Beast_Features and Beast_Feature_Requests

After some discussions in the mailing list about Usability of beast, GUI design and usage scenarios(which didn't exist in written form for Beast at the time of this writing),we decided, to get started analyzing, designing and documenting BeastFeature and UseCases for Beast to steer development in a user-centered way- so here we are.

This place is not meant to be a perfectly designed place, we can have Ideas and thoughts as well as really worked out plans and documentation. For now it's only a start for doing application design from a new perspective than just listing features, say by analyzing what tasks people want to get done in which ways.

If anybody has ideas, comments or proposals about any existing or missing UseCase, please send an email to the beast Mailing list or contact Henning via email: henning_sprang\at\gmx.de or add comments here.


The cases

  • Using Beast as a GUI beatbox or drum machine/sequencer like "hydrogen" or freebirth - including the ability to add filters/effects between arbitrary inputs and outputs and have them time-controlled
  • Using Beast as a modular synthesizer that is
    • usable
    • has a GUI
    • has realtime capabilities
    • can be controlled by an internal note editor or external via the alsa midi interface
  • using beast a sample player/tracker with an easy and intuitive GUI including arbitrary filters/effects
  • using beast to control external devices or software through alsa midi interface


Links

some links related to software modeling techniques based on use cases that might contains some help to get the tasks here accomplished:


Questions:

  • how should a use case be documented? What questions must the information therein answer? maybe write these rules down here, so it's more clear what is the way we describe our things on this page
    • basically, a use case is a short description of valid tasks, people should be able to accomplish with a program. More detailed explanations can be found in the links section or in other documentation on object oriented design and UML, which is often used as a tool to document use cases in OO-development
  • if i have a UseCase, do i have everything documented that is needed to start writing the code that makes it happen?
    • no, a comlete chain needed for a comlete design is something would like this (while we voted to concnetrate first on completing our feature list and do use cases for the most important things first:
      1. feature list
      2. UseCases
      3. Story Board
      4. GUI mockup
      5. implementation plan
  • what is the difference between a requirements document, a use case collection and a "storyboard" for sequences of actions users want/need to perform to accomplish their tasks?
    • no, see above question for what is needed for a full fledged design documentation


TODO:

  • hs: refine the "beatbox" use cases
  • hs: have a look at the sequencer plugin - how could it be transformed to get a beatbox? what would needed to be done?
  • hs: refine the "modular synthesizer" usecase
  • hs: translate FeatureRequests and BeastFeatures to use cases
  • hs: translate use cases from www.sprang.de audiocomposer/beast/usevases to english and put them in here
  • hs: get together with people making music with computers (maybe using other software) and analyze what tasks they need and want to get accomplished, what is the easiest and most inuitive way for them to get their work done? Note: we do not want to copy other software, we only want to find out how people would like to work or are actually working, as long as this is the best way, to professionally produce sound with beast.
  • hs: read all available beast docs relevant for this topic


  • This page was last modified on 20 January 2011, at 02:23.
  • This page has been accessed 2,760 times.
Support Us

Flattr this