Re: FYI: UsabilityGuidelines handbill - supplement: Usage Designdocument

[Henning Sprang <henning_sprang gmx de>]

Tim Janik wrote:
 > [...]
> 
> heh, beast is subject to OO-design or modern user-interface-design.
> so the term "use case" is more than appropriate here.
> the problem with that is that i'm like completely overloaded already,
> so you're pretty unlikely to see me produce usage cases inthe near
> furutere. i'd however much apprechiate if someone else started out on
> creating some, and i'd certainly comment on them / discuss them.

I'm on it. Should we start here or should we start a new Wiki Page 
"UseCases"? I'd like to have a central public place to store the results 
of these discussions while the discussions can take place here.

> 
> if in succession of that user interface improvements are being developed,
> i can also provide technical guidance to get those implemented in beast.

I don't know if we talked about it, i cannot code C for now, but have 
some years of experience in Java and wanna learn C since some time, just 
didn't have some interesting project to get started.

> 
> 
>>But there is no really quick and easy access to all that, like for
>>example to get a job done like "i wanna get some drum loops together by
>>starting a programm, choosing some drums, and clicking a drum pattern
>>from the different drum samples together, and underly some drum tracks
>>with some effects" which is a pretty simple basic reason task one can
>>get done in reason within minutes even as a first time user - and beast
>>isn't lacking anything to be able to do it, in it's actual state one
>>would only need about 2 hours when already having some knowledge of
>>beast, and maybe 2 days or weeks without knowing beast.
> 
> 
> well, make a suggestion to improve beasts GUI, what should change for it
> to provide easy access in the way you outlined?

I think this special case is less only the GUI, but the way and/or 
possibilities to connect some beast elements together. I mean I'd like 
to see something like rebirth, reason's predecessor, or if you know them 
the free tools "freebirth" and "hydrogen" - you have 16 quarter beats 
where you can place a marker that some drum sample should be activated 
there, either by having a knob or buttons to chose which track you're 
actually working with (rebirth, freebirth) or you have all available 
tracks in an overview just like beasts note editor, with the difference 
that you don't have different notes of the same instrument for each line 
in the edit view, but just a hit of another drum sample for each line in 
the edit view - that would already be it. as I said, i can even imagine, 
that one could create a custom synthesizer that would do something like 
that - translating different notes into actions that trigger wave 
oscillators with different drum samples. but even if one could do that, 
it would take a good while, even if one already knows beast a bit in 
terms of having done first steps and got first sounds out of it, and 
then it would not be pretty easy usable, adding filters and effects to a 
drum or chosing another sample, adding a new sample would be a lot of 
clicks.

> [...]
> nope, you're right. it just takes someone to step up and start working
> on use cases, story boards and general interface design planning ;)
> 

I get started right here and now, when we've decieded where 
documentation will take place, I'll be taking my AudioComposer UseCases 
translated to english and ask the people on the list in a public call to 
send me their own ideas of how they want to use beast, ask my friends 
who make music (using mainly reason and some other things), document all 
that and work it out. You will be required to tell if and how all that 
can be solved in the application development area. And, of course, we 
will allow you to add your own use cases, too - you might have had some 
idea of what you need and want when you started doing beast?! :)

Henning