On 5 July 2010 08:18, Philipp Überbacher <hollunder@xxxxxxxxxxx> wrote: > Excerpts from James Morris's message of 2010-07-02 15:37:33 +0200: >> On 2 July 2010 11:46, Philipp Überbacher <hollunder@xxxxxxxxxxx> 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 > > _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
