Excerpts from James Morris's message of 2010-08-17 03:17:01 +0200:
On 17 August 2010 00:54, Philipp Überbacher
<hollunder(a)lavabit.com> wrote:
Excerpts from James Morris's message of
2010-08-15 03:21:38 +0200:
On 5 July 2010 09:27, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
On 07/05/2010 06:15 PM, James Morris wrote:
>
> 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.
>
>
>
I think LAU/LAD are good for that until a project gets a large enough user
base to warrant it's own list.
Ok, after some considerable time it's now in the first steps of having
consequences of user interactions...
Meaning, you can drag a blue square around and the events in the
pattern are sequenced into it (when you release the mouse button that
is). As you should by now know, the position of the events is
translated into pitch and velocity.
It's enough to play around with for a few minutes :)
I recommend Will J Godfrey's 'Sweep Saw' Zyn/Yoshi patch.
Try it out:
git clone
git://github.com/jwm-art-net/BoxySeq.git && cd BoxySeq &&
make && ./boxyseq
Just don't expect too much. You cannot edit the pattern unless you're
willing to experiment with C code (lines 63 to 84 of main.c for event
pattern, lines 87 to 105 for boundary settings) and recompile and
restart the program.
you'll need jack, glib, and gtk development packages installed beforehand.
still very early days here.
Cheers,
James.
Hey James.
I'm just giving it a try, and it's fun. I found a feature you didn't
tell us about, rightclick+drag to resize/reshape the box.
I gave three different zynaddsubfx/yoshimi patches a try, and it's fun
with all of them. I can imagine that it's already useful, at least for
adding random bleeps or whatever to pieces.
Nice work so far.
Regards,
--
Philipp
Hi, thanks for your comments. Yes I added the resize the following day.
The CPU usage of the graphics has been bothering me. It was using
Cairo which can do some funky stuff, but it comes at a price. My
latest commit has removed the Cairo code and replaced it with GDK. GDK
is 'closer to xlib' and is less funky, but performance is much better.
Indeed. I noticed that it took about 30% here, even when not running.
Now it runs at about 3%.
This version is using two boundaries fed by a single
pattern.
Did you read my mind? I thought some more boxes would make it
more interesting.
I need some ideas about the user interface. The way
you can manipulate
the boundary box positions and dimensions around is good. But I'd like
the user to also be able to change the scale and key of the events
placed within the boundary with as much ease.
Being able to make selections will be important too.
Though I imagine there's going to be a whole lot of icons with boxes on them!
An icon to make selections
An icon to define a boundary
An icon to redefine a boundary (repositon+redimension in one foul swoop)
An icon to define a block (a block blocks events from being placed where it is)
I'm no big fan of icons, buttons and clicking around in general.
How about using modifier keys+mouse? You could place a listing of
available commands somewhere, so the user sees it at one glance. Yes,
the Traverso GUI influenced me *slightly*.
very boxy indeed.
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