New subject: opinions from (potential) user perspectives wanted

5 Jul 2010

On 5 July 2010 08:18, Philipp Überbacher &lt;hollunder(a)lavabit.com&gt; wrote:
...
  Excerpts from James Morris's message of 2010-07-02
15:37:33 +0200:
  On 2 July 2010 11:46, Philipp Überbacher
&lt;hollunder(a)lavabit.com&gt; wrote:
  Excerpts from Gabriel M. Beddingfield's
message of 2010-07-02 01:57:17 +0200:

 On Thu, 1 Jul 2010, James Morris wrote:

 > It's like a sequencer in that the user will be able to create rhythmic
 > patterns which lack pitch and velocity data, and almost like an
 > arpeggiator in that it will automatically generate the pitch and
 > velocity data from an algorithm - and unlike either a sequencer or
 > arpegiattor, it uses a 2d window-placement like algorithm to generate
 > pitch/velocity (mapping these to x/y).

 The more I think about this... the more fun it sounds.

 Have you considered doing an MDI interface?  This way you
 can go back to spamming windows... but it stays contained in
 your applications MainWindow. 
 Since most window managers support a 'workspace' concept I guess it's
 not a big deal. But who uses xterm? :) And fixed size? What about tiling
 window managers? 
 The window placement algorithm is done, and I spent quite some time
 getting it working satisfactorily performance-wise, within real time
 constraints. The idea is based upon window-manager window-placement,
 but in the distant future - when the app is up and running with a nice
 shiny GUI - the user might not ever care nor need to care, that the
 boxes that appear simultaneously as notes are played is based upon
 window-manager window-placement. I don't think it will be necessary to
 place much emphasis on it's origins. It's only that way right now
 because I've not evolved my thinking about how to describe it further
 than "it's like a window-manager's window-placement" :-)

 And what are you referring to as fixed size?

 Cheers,
 james. 
 Quote:
 "It's currently in the "i demand an xterm at least 128 x 128 in size
    but i still can't do anything you might want me to do" stage."

 As I don't really understand the concept I have no idea whether the
 terminal window size matters or not, it just seems like it would be
 large for windows that are placed for placements sake. As said before,
 I've no idea what I'm talking about since I don't know how window
 placement translates to anything musical. 

I've tried to be as clear as possible here:
http://wiki.github.com/jwm-art-net/BoxySeq/at-a-glance

xterm is used only because writing to a terminal is the simplest
method for a program to provide a user with information about what is
happening. size of the xterm matters only if you want to make any
sense of what boxyseq is displaying - it won't affect the behaviour of
boxyseq in any way.

forget any ideas in your mind about boxyseq placing windows on your
desktop - this won't happen. all i've done is written some code which
emulates the window-placement strategy of the fluxbox window
manager... and used it for other purposes. with boxyseq, the "window
placement" is just a scanning of bits followed by a manipulation of
bits which happens within a data array.

the basis of the idea is best represented by the following single line of text:

"window-manager window-placement".

the simplest way to represent the data that results from this idea is
by creating a textual representation of that binary data and
displaying it in a terminal. (then i can watch in real time what is
happening :-) and see if it's working properly :-)

i don't want to implement a complex way (GUI) of representing the data
until i have a solid foundation to build upon.

really it is far too early for users to take any interest in this
program. but sometimes I just need some feedback about some of the
ideas i have before I can proceed further in its development.

Cheers,
James.

...
  --
 Regards,
 Philipp

 --
 "Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen
offen." Bertolt Brecht, Der gute Mensch von Sezuan

Re: [LAU] opinions from (potential) user perspectives wanted