From azervopoulos at gmail.com Wed Feb 1 09:28:03 2006 From: azervopoulos at gmail.com (Thanassis Zervopoulos) Date: Wed, 1 Feb 2006 11:28:03 +0200 Subject: [gsharp-devel] Connecting portmidi with gsharp... Message-ID: I'd like to connect my midi keyboard with gsharp so that i'll be able to write a song with midi and not with the keyboard of my computer. With wich files should i mess to create that? I know that there are a lot of problems yet, but i'd like to work on this feature and add it on gsharp, if it doesn't exist yet. Thanx in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From strandh at labri.fr Thu Feb 2 01:37:16 2006 From: strandh at labri.fr (Robert Strandh) Date: Thu, 2 Feb 2006 02:37:16 +0100 Subject: [gsharp-devel] Connecting portmidi with gsharp... In-Reply-To: References: Message-ID: <17377.25164.397980.667370@serveur5.labri.fr> Thanassis Zervopoulos writes: > I'd like to connect my midi keyboard with gsharp so that i'll be able to > write a song with midi and not with the keyboard of my computer. Sounds like a good idea to me. > With wich files should i mess to create that? I know that there are a lot of > problems yet, but i'd like to work on this feature and add it on gsharp, if > it doesn't exist yet. It does not exist yet. There are several problems that need to be solved: * You need to inject the MIDI events into the CLIM event queue. Alternatively, you could start a separate thread to read from the MIDI device, but then you get potential synchronization problems. I would think the easiest thing to do is to use the X server to resolve such synchronization problem. You might have to define a new subclass of `event' (midi-event) in CLIM, but that's easy. * You need to create a command table that can handle midi events (easy). The hard part is to know what to do with the events. Specifically, do you take into account things like duration. I suggest that you don't and that you use only pitch information. There are still some things to consider though: * If you receive an event that has the same pitch as one of the notes in the scale which is current at the cursor (which we know from the key signature), then insert the corresponding note. * If you receive an event that does not have the same pitch as one of the notes in the scale which is current at the cursor, then what to do? I think the answer is that you should search the key signatures in both directions (more flats, more sharps) from the current one, until you reach a scale that has a note with the pitch of the event, and insert that note. To obtain chords, you would create a new cluster only when you receive the first note-on MIDI message. When receiving a note-on message and there are already keys for which you have received a note-on message but no corresponding note-off message, you would instead add the note to the previous cluster. If you want to avoid having to use both the MIDI keyboard and the computer keyboard (which you would have to use (sometimes with both hands) for things like changing the note head, the duration, the flags, the dots, etc., you could map some other keys on the MIDI keyboard to the Gsharp commands that accomplish this. It is probably not terribly important what files you put things in at the moment, but you probably need a bunch of commands and a command table that you might put either in gui.lisp or in a new file midi-input.lisp. The modes.lisp file contains key bindings, but you might as well put the new bindings in midi-input.lisp as well. Feel free to ask some more questions on this list if you get stuck, and feel free to comment on my suggestions above. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Sat Feb 4 20:39:37 2006 From: strandh at labri.fr (Robert Strandh) Date: Sat, 4 Feb 2006 21:39:37 +0100 Subject: [gsharp-devel] I am considering changing the external format of buffer objects Message-ID: <17381.4361.901021.346212@serveur5.labri.fr> Hello, In order to make it easier to introduce new buffer objects, I was thinking of changing the external format so that it would be more modular. This was provoked by the imminent introduction of a key-signature object. Currently, the left bracket character `[' is a dispatch macro character, and the character following it determines the type of object, in a rather arbitrary way. After that follows a list of keyword-value pairs to be passed to MAKE-INSTANCE. I was thinking of making the left bracket an ordinary macro character, and to have it followed by a symbol that corresponds to the name of the class to pass to MAKE-INSTANCE. This modification would also potentially greatly simplify the code for reading a writing buffer objects. I would appreciate any comments on this idea before starting the modification. Thanks, -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Wed Feb 8 01:19:20 2006 From: strandh at labri.fr (Robert Strandh) Date: Wed, 8 Feb 2006 02:19:20 +0100 Subject: [gsharp-devel] Key signatures Message-ID: <17385.18200.691872.779262@serveur5.labri.fr> Christophe, Perhaps we can work in your patch piecewise. I suggest starting by creating the class for key signatures, making the :initarg for fiveline-staff create an instance of that class, making an :after method of initialize-instance on fiveline-staff check whether the slot contains an array, and if so, change it to an instance of the new class containing that array (this way we don't have to change the input format yet again). I can do this if you do not intend to work on it any time soon, and if you don't think it would make your merge more complicated later. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Wed Feb 15 18:35:38 2006 From: strandh at labri.fr (Robert Strandh) Date: Wed, 15 Feb 2006 19:35:38 +0100 Subject: [gsharp-devel] Gsharp progress report Message-ID: <17395.29818.281647.102837@serveur5.labri.fr> Dear mailing list member, As promised, here is another Gsharp progress report, again mainly for those who follow neither the CVS mailing list nor the #lisp IRC channel. I have worked on several different things since the last progress report: * Key signatures are now Gsharp objects (as opposed to just vectors) with their own protocol. I did not change the external format yet again, and instead made it possible for the current one to deal with either representation; * Gsharp can now handle elements with zero duration. That turned out to be a major reorganization of the code. This functionality will be used for elements such as key signature changes and clef changes; * I changed the class hierarchy of elements according to a suggestion by Christophe Rhodes, so that there is now an additional class `rhythmic-element' that represents elements with non-zero duration; * The external format for representing buffer objects has been modified, though Gsharp can still read the old format. The new format is easier to extend with new types of objects. Instead of using a dispatch macro character, there is now a single macro character `[', which is followed by a fully qualified symbol name that indicates the name of the class of the object; * I reorganized the command tables so that the one used by the command loop can be determined by the type of the current layer, and the type of the element preceding the cursor. This makes it easier to use the same key strokes for different kinds of elements and different kinds of layers; * I started implementing ties. The code for representing ties in the buffer seems to be working. However, rendering ties is hard, and requires access to the book by Ted Ross, which I have now ordered so that I can finish this work. Rendering ties turns out to be messy in other ways as well, since most rendering code at the moment works "vertically" by measures, whereas ties need to be processed "horizontally" by layers; * I introduced two new packages esa-buffer and esa-io (that I hope will become part of a separate ESA library one day) which contain code adapted from Climacs that manages buffer/file i/o in an application independent way. I made Gsharp take advantage of these new packages to behave more like an editor application should, with named buffers and Emacs-style file i/o (C-x C-s, C-x C-w, etc); * Gsharp now has an `info pane' (what Emacs calls "mode line") that shows the name of the buffer, whether it needs saving, etc. Documentation changes: * I updated the documentation to reflect an old change from using a CLIM interactor pane to using an ESA minibuffer. The documentation is still not fully up-to-date, nor is it complete, but it is better than it was. New score: * There is a new, partially-completed score in the Scores directory. It is a tune used in a commercial on NZ TV. Minor fixes: * Fixed a bug that made Gsharp crash for empty clusters. These were used in one of the scores in the Scores directory, but I had not used that particular score to test Gsharp for a while. Now, all the scores in the Scores directory should work; * Fixed a bug that ignored the explicit x-offset of elements. This bug was introduced when the spacing algorithm was altered. One of the scores in the Scores directory needs explicit x-offsets in order to avoid overlaps of elements in crossing voices; * The temporary midi file generated by the `play' commands is not put in /tmp. It is still not uniquely named, nor is it cleaned up; * Fixed a bug that did not recognize modifications to lyrics elements so did not invalidate the corresponding element. Related fixes: * I modified the font viewer in the Fonts directory (another CLIM application) to play nicely with the others, and not destroy the port. Now the viewer can be used from the CLIM Desktop. That's all for this time. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From csr21 at cam.ac.uk Mon Feb 27 18:36:04 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 27 Feb 2006 18:36:04 +0000 Subject: [gsharp-devel] Re: Key signatures In-Reply-To: <17385.18200.691872.779262@serveur5.labri.fr> (Robert Strandh's message of "Wed, 8 Feb 2006 02:19:20 +0100") References: <17385.18200.691872.779262@serveur5.labri.fr> Message-ID: Robert Strandh writes: > I can do this if you do not intend to work on it any time soon, and if > you don't think it would make your merge more complicated later. Following your work on the key signature element, I attach a merge of my functionality (still with the bugs previously identified: namely too much invalidation and failure to find the right key signature when there are multiple layers on one staff) with the new stuff. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: keysigN.diff URL: -------------- next part -------------- Cheers, Christophe From csr21 at cam.ac.uk Tue Feb 28 15:14:10 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 28 Feb 2006 15:14:10 +0000 Subject: [gsharp-devel] rotate-notehead on rests Message-ID: Hi, At some point in the reorganization, C-r stopped working on rests. Attached is a patch which gets it working again. (My tree is otherwise mutant from too many key signatures, so please apply :-) People might also be interested to compare a screenshot I took this morning, , with the opening of the lilypond score I produced a few years ago, . Entering the notes for this was a true breeze; the lyric entry mode needs some more work (and so does lyrics display, actually), but overall I think it's promising. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rotate-rests.diff URL: -------------- next part -------------- Cheers, Christophe From csr21 at cam.ac.uk Tue Feb 28 15:42:25 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 28 Feb 2006 15:42:25 +0000 Subject: [gsharp-devel] playing ties Message-ID: Hi, The attached patch makes ties render properly in midi output. It doesn't do any kind of error checking; if that's acceptable, please apply it. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: play.diff URL: -------------- next part -------------- Cheers, Christophe From csr21 at cam.ac.uk Tue Feb 28 17:01:12 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 28 Feb 2006 17:01:12 +0000 Subject: [gsharp-devel] saving ties Message-ID: Hi, Attached is a patch which allows ties to be saved. It optimizes for the common case of no ties. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: save-ties.diff URL: -------------- next part -------------- Cheers, Christophe From csr21 at cam.ac.uk Tue Feb 28 17:11:38 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 28 Feb 2006 17:11:38 +0000 Subject: [gsharp-devel] 8va treble clef Message-ID: Hi, Attached is a patch implementing a treble8 clef (which is a treble clef with implicit octaviation). I'm not really proposing this for direct inclusion; I haven't designed a glyph for it, for a start. However, the patch indicates quite well where things could afford to be abstracted a little, and I also needed it so that I could get midi output for les Cris de Paris in the right octave. * MIDI output * Gsharp score (requires patches) * pretty screenshot . -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: treble8.diff URL: -------------- next part -------------- Other things that I've noticed but haven't fixed while playing around today include that making a note be tied (or presumably untied) doesn't mark the buffer as having changed, and that the ties are drawn after the bar lines (causing some damage to the barlines where they intersect with the bounding rectangle of the tie glyphs.) Cheers, Christophe From strandh at labri.fr Tue Feb 28 23:50:15 2006 From: strandh at labri.fr (Robert Strandh) Date: Wed, 1 Mar 2006 00:50:15 +0100 Subject: [gsharp-devel] playing ties In-Reply-To: References: Message-ID: <17412.57783.555988.801640@serveur5.labri.fr> Christophe Rhodes writes: > > The attached patch makes ties render properly in midi output. It > doesn't do any kind of error checking; if that's acceptable, please > apply it. I applied it. It is better than it was before. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. ---------------------------------------------------------------------