freenode/#clim - IRC Chatlog
Search
3:15:53
ck_
As suspected there's not much immediate opportunity for Common Lisp, but it also doesn't seem to be totally out of the question.
4:01:27
beach
What I asked jackdaniel to do was the user interface, i.e., panes, menus, maybe "butcons" for different music elements. But I am still going the implementation of the model, and also the exact layout of the symbols.
4:04:11
beach
I also need to give some more thought to the input. Gsharp had a very efficient input technique, but I don't think it is adapted to a wide audience.
4:05:43
beach
I remove one painful aspect by a key innovation in Gsharp, namely not enforcing the meter.
4:06:57
beach
It is strange that other score editors have not figured that one out, especially since composers are known to use notation that does not enforce the meter. I guess it's because these editors were not written by composers or music engravers.
4:18:48
beach
One basic problem is that the duration of music elements varies a lot, so the user ends up having to select a different kind of music element for each new entry.
4:19:23
ck_
have you thought about using the time used for keyboard presses or mouse clicks for this?
4:21:50
ck_
I was thinking about entering notes by clicking on the staff, and -- for example -- holding the mouse button down and observing it cycle through eights, quarters, halfs and so on, then letting go at the right one
4:22:18
ck_
or using the scroll wheel [ or multi-finger gestures on a tablet ] to scroll through the times
4:24:09
beach
Maybe some pointer icon changes with the wheel, before the user clicks on the position.
4:24:37
beach
That would avoid this necessity of changing the mouse position and eye focus between each note.
4:29:55
beach
The other thing I have been thinking is to have two different presentation modes. One would be "preview" mode that presents the score as it would be printed. The other one would be "edit mode" in which there is additional information shown that is useful to the user, but that won't show up in the printed score.
4:31:22
beach
Preview mode could have lots of presentations on the screen that trigger different actions, so that the user doesn't have to move the eye focus to much to butcons, menus, and the like.
4:31:54
ck_
oh yes, I think a mode split like that is very prudent. Maybe one could call it even necessary
4:33:31
ck_
I'd like to talk with you about this some more, user interfaces are an interest of mine. Maybe on the weekend, or when you pick it back up
4:33:34
beach
So, I think we have identified a main goal, namely that the user should not have to move the pointer too far away from the place where music elements are currently inserted or altered.
6:08:30
jackdaniel
ck_: I did, I wrote a class hierarchy, some basic application frame and utilities (like computing offsets between notes and converting a note to either frequency or a midi key)
6:22:29
jackdaniel
n.b, I mean this question: https://irclog.tymoon.eu/freenode/%23clim?around=1568834687#1568834687
6:26:36
jackdaniel
so it is a progress compared to emacs which indeed likes to hang up on me from time to time too
6:30:58
jackdaniel
I'm sure there are irssi plugins for that, but I'm not much into that so I can't tell for sure (I'm using "vanilla" version)
6:32:00
beach
... i.e. a CLIM-based desktop where things like the spell checker, the abbrevs, etc. could be easily shared between applications.
6:32:54
jackdaniel
I know it doesn't account for a spell checker, but I wrote checkers! ;-) http://hellsgate.pl/files/ac973b5d-checkers.png
6:35:17
jackdaniel
they are basically ready to be commited, but my followup pull request fix-drag-and-drop waits for a better time, so I'm not making another one
7:18:05
jackdaniel
we have clime:draw-glyph (which is basically a single-character variant of draw-text), I plan to eradicate it as undocumented and unnecessary along with medium-draw-glyph from climi package