From strandh at labri.fr Wed Aug 2 18:07:05 2006 From: strandh at labri.fr (Robert Strandh) Date: Wed, 2 Aug 2006 20:07:05 +0200 Subject: [gsharp-devel] suggested change of terminology Message-ID: <17616.59849.133545.359933@serveur5.labri.fr> Hello, In private email, Magnus Johansson told me that a "treble clef" is a "G clef" on line 2 (in Gsharp terminology) and a "bass clef" is an "F clef" on line 6 (idem). This is not the terminology that Gsharp uses at the moment. In the book by Ross, I can't find any support for what Magnus told me, but on the other hand, it is consistent with it. Ross simply says that the treble clef and the bass clef never move. Having thought about it for a while, I am now suggesting a change in the behavior of Gsharp, and a corresponding change to the documentation. My suggestion is partly based on the difficulty for an end user to know the number of each staff line. I suggest changing the "Insert Staff Above/Below" commands so that they do not prompt for a line number for the clef, and instead just use the default staff line for each clef. Furthermore, I suggest that "f" and "bass" be equivalent choices and that "g" and "treble" be equivalent choices. Finally, I suggest adding commands to move the clef of a staff up or down one line. Internally, I suggest changing the names of the clefs to :g, :f, and :c. Comments? -- 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 Aug 2 18:07:38 2006 From: strandh at labri.fr (Robert Strandh) Date: Wed, 2 Aug 2006 20:07:38 +0200 Subject: [gsharp-devel] "bar" or "measure" Message-ID: <17616.59882.171949.845353@serveur5.labri.fr> Hello, Magnus Johansson has suggested that Gsharp use the term "bar", rather than "measure" in the user documentation to indicate the music material between two barlines. The book by Ross uses "measure" rather than "bar" but it uses "barline", and not "measure line" (which I have never heard). What do other authors use? Internally, of course, there is still a distinction between "bar", which is the music material between two barlines within a layer, and "measure" which is the music material between two barlines of every layer, but this fact does not necessarily influence our choice of user-level terminology. On the other hand, we might want to make that distinction to the user as well, in which case we might as well use the same one internally and to the user. Comments? -- 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 eolin at telia.com Wed Aug 2 19:03:12 2006 From: eolin at telia.com (Eolin KB) Date: Wed, 2 Aug 2006 21:03:12 +0200 Subject: [gsharp-devel] suggested change of terminology References: <17616.59849.133545.359933@serveur5.labri.fr> Message-ID: <002d01c6b666$4d9e57a0$6538e551@eolinc1> Hello Robert, Christophe and others! In my reply below EMJ are my initials (Erik Magnus Johansson) ----- Original Message ----- From: "Robert Strandh" To: Sent: Wednesday, August 02, 2006 8:07 PM Subject: [gsharp-devel] suggested change of terminology > Hello, > > In private email, Magnus Johansson told me that a "treble clef" is a > "G clef" on line 2 (in Gsharp terminology) and a "bass clef" is an "F > clef" on line 6 (idem). This is not the terminology that Gsharp uses > at the moment. In the book by Ross, I can't find any support for what > Magnus told me, but on the other hand, it is consistent with it. Ross > simply says that the treble clef and the bass clef never move. EMJ: But they can indeed move and they also get distinct names at each position: F clef on the fifth line is called sub-bass clef, on the fourth line bass clef, and on the third line baritone clef; a G clef on the second line is called treble clef, and on the first line french violin clef. > Having thought about it for a while, I am now suggesting a change in > the behavior of Gsharp, and a corresponding change to the > documentation. My suggestion is partly based on the difficulty for an > end user to know the number of each staff line. > > I suggest changing the "Insert Staff Above/Below" commands so that > they do not prompt for a line number for the clef, and instead just > use the default staff line for each clef. Furthermore, I suggest > that "f" and "bass" be equivalent choices and that "g" and "treble" > be equivalent choices. EMJ: See my first comment why "g" (clef) and "treble" are not equivalent. > Finally, I suggest adding commands to move the clef of a staff up or down > one line. EMJ: Good! > Internally, I suggest changing the names of the clefs to :g, :f, and > :c. EMJ: Good! > Comments? > -- > 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. > --------------------------------------------------------------------- > _______________________________________________ > gsharp-devel site list > gsharp-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/gsharp-devel > From csr21 at cam.ac.uk Wed Aug 2 19:45:24 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 02 Aug 2006 20:45:24 +0100 Subject: [gsharp-devel] suggested change of terminology In-Reply-To: <17616.59849.133545.359933@serveur5.labri.fr> (Robert Strandh's message of "Wed, 2 Aug 2006 20:07:05 +0200") References: <17616.59849.133545.359933@serveur5.labri.fr> Message-ID: Robert Strandh writes: > In private email, Magnus Johansson told me that a "treble clef" is a > "G clef" on line 2 (in Gsharp terminology) and a "bass clef" is an "F > clef" on line 6 (idem). This is not the terminology that Gsharp uses > at the moment. In the book by Ross, I can't find any support for what > Magnus told me, but on the other hand, it is consistent with it. Ross > simply says that the treble clef and the bass clef never move. This is true. There are other names for other clef/line combinations (e.g. "tenor", "alto" and "soprano" for various positions of the C clef). > Having thought about it for a while, I am now suggesting a change in > the behavior of Gsharp, and a corresponding change to the > documentation. My suggestion is partly based on the difficulty for an > end user to know the number of each staff line. Heh, yes, this has bitten me several times. > I suggest changing the "Insert Staff Above/Below" commands so that > they do not prompt for a line number for the clef, and instead just > use the default staff line for each clef. Furthermore, I suggest > that "f" and "bass" be equivalent choices and that "g" and "treble" > be equivalent choices. Finally, I suggest adding commands to move > the clef of a staff up or down one line. Up or down n lines, maybe? Ideally with the numeric prefix argument, so that I can do C-u 2 C-c C-u (or whatever) when I want a tenor clef instead of a viola / alto clef... Incidentally, there's a tricky terminological issue. Moving a clef higher means lowering the pitch of the lines: so naming the command should aim to be clear; maybe Move Clef Up? > Internally, I suggest changing the names of the clefs to :g, :f, and > :c. Fine by me, though it gets more complicated, again. Firstly, there's the issue of the 8va treble clef, which has a (slightly) different glyph. Secondly, there's the issue that several orchestral instruments have transposing clefs -- that is, a clef where the pitches played sound a constant interval away from the notated pitch. (Normal examples: trumpets and clarinets, the latter having the additional amusement that there are several instruments and several transpositions). This should probably be handled by the clef object rather than the name for the glyph, but it does add to the complexity. Cheers, Christophe From csr21 at cam.ac.uk Wed Aug 2 19:47:10 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 02 Aug 2006 20:47:10 +0100 Subject: [gsharp-devel] "bar" or "measure" In-Reply-To: <17616.59882.171949.845353@serveur5.labri.fr> (Robert Strandh's message of "Wed, 2 Aug 2006 20:07:38 +0200") References: <17616.59882.171949.845353@serveur5.labri.fr> Message-ID: Robert Strandh writes: > Magnus Johansson has suggested that Gsharp use the term "bar", rather > than "measure" in the user documentation to indicate the music > material between two barlines. > > The book by Ross uses "measure" rather than "bar" but it uses > "barline", and not "measure line" (which I have never heard). What do > other authors use? I believe that the UK uses "bar" with the same meaning as the US uses "measure", and ... > Internally, of course, there is still a distinction between "bar", > which is the music material between two barlines within a layer, and > "measure" which is the music material between two barlines of every > layer, but this fact does not necessarily influence our choice of > user-level terminology. > > On the other hand, we might want to make that distinction to the user > as well, in which case we might as well use the same one internally > and to the user. ... sadly neither "bar" nor "measure" really has the nuance that is visible here. Cheers, Christophe From strandh at labri.fr Thu Aug 3 02:39:09 2006 From: strandh at labri.fr (Robert Strandh) Date: Thu, 3 Aug 2006 04:39:09 +0200 Subject: [gsharp-devel] suggested change of terminology In-Reply-To: References: <17616.59849.133545.359933@serveur5.labri.fr> Message-ID: <17617.25037.270407.688282@serveur5.labri.fr> Christophe Rhodes writes: > > > In private email, Magnus Johansson told me that a "treble clef" is a > > "G clef" on line 2 (in Gsharp terminology) and a "bass clef" is an "F > > clef" on line 6 (idem). This is not the terminology that Gsharp uses > > at the moment. In the book by Ross, I can't find any support for what > > Magnus told me, but on the other hand, it is consistent with it. Ross > > simply says that the treble clef and the bass clef never move. > > This is true. There are other names for other clef/line combinations > (e.g. "tenor", "alto" and "soprano" for various positions of the C > clef). OK, so instead of my initial suggestion, I now make the following one: I suggest changing the "Insert Staff Above/Below" commands so that they initially prompt for a clef. The only choices possible will be names of clef/line combinations (treble, bass, soprano, tenor, alto) and no question about the line will be asked. Finally, I suggest adding commands to move the clef of a staff up or down n lines according to a numeric argument. > Incidentally, there's a tricky terminological issue. Moving a clef > higher means lowering the pitch of the lines: so naming the command > should aim to be clear; maybe Move Clef Up? Sure, that's fine. > Fine by me, though it gets more complicated, again. Firstly, there's > the issue of the 8va treble clef, which has a (slightly) different > glyph. Right. I guess that could be one of the choices. > Secondly, there's the issue that several orchestral > instruments have transposing clefs -- that is, a clef where the > pitches played sound a constant interval away from the notated pitch. > (Normal examples: trumpets and clarinets, the latter having the > additional amusement that there are several instruments and several > transpositions). This should probably be handled by the clef object > rather than the name for the glyph, but it does add to the complexity. I agree. I suggest introducing a "transpose interval" to a clef that will handle that, and that will initially be 0 (is it possible to indicate it with a numeric value?), and that can be altered. It would probably be nice if the input method could either take that interval into account (for people who think about pitch rather than notation) or not (for the others). -- 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 Thu Aug 3 02:41:06 2006 From: strandh at labri.fr (Robert Strandh) Date: Thu, 3 Aug 2006 04:41:06 +0200 Subject: [gsharp-devel] suggested change of terminology In-Reply-To: <002d01c6b666$4d9e57a0$6538e551@eolinc1> References: <17616.59849.133545.359933@serveur5.labri.fr> <002d01c6b666$4d9e57a0$6538e551@eolinc1> Message-ID: <17617.25154.345729.807543@serveur5.labri.fr> Eolin KB writes: > EMJ: But they can indeed move and they also get distinct names at each > position: F clef on the fifth line is called sub-bass clef, on the fourth > line bass clef, and on the third line baritone clef; a G clef on the second > line is called treble clef, and on the first line french violin clef. Excellent! We just have to add those to our menu choices. > > I suggest changing the "Insert Staff Above/Below" commands so that > > they do not prompt for a line number for the clef, and instead just > > use the default staff line for each clef. Furthermore, I suggest > > that "f" and "bass" be equivalent choices and that "g" and "treble" > > be equivalent choices. > > EMJ: See my first comment why "g" (clef) and "treble" are not equivalent. OK, see my modified proposal in my previous message. -- 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 Thu Aug 3 02:45:10 2006 From: strandh at labri.fr (Robert Strandh) Date: Thu, 3 Aug 2006 04:45:10 +0200 Subject: [gsharp-devel] "bar" or "measure" In-Reply-To: References: <17616.59882.171949.845353@serveur5.labri.fr> Message-ID: <17617.25398.31880.33486@serveur5.labri.fr> Christophe Rhodes writes: > > The book by Ross uses "measure" rather than "bar" but it uses > > "barline", and not "measure line" (which I have never heard). What do > > other authors use? > > I believe that the UK uses "bar" with the same meaning as the US uses > "measure", and ... OK. > > Internally, of course, there is still a distinction between "bar", > > which is the music material between two barlines within a layer, and > > "measure" which is the music material between two barlines of every > > layer, but this fact does not necessarily influence our choice of > > user-level terminology. > > > > On the other hand, we might want to make that distinction to the user > > as well, in which case we might as well use the same one internally > > and to the user. > > ... sadly neither "bar" nor "measure" really has the nuance that is > visible here. The only alternative, then, seems to be to invent new terminology to emphasize that nuance, perhaps something along the lines of "partial bar" and "complete measure"? -- 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 eolin at telia.com Thu Aug 3 06:53:40 2006 From: eolin at telia.com (Eolin KB) Date: Thu, 3 Aug 2006 08:53:40 +0200 Subject: [gsharp-devel] "Bar" or "measure" Message-ID: <003b01c6b6c9$8df62b80$6538e551@eolinc1> Hello! ----- Original Message ----- From: "Robert Strandh" To: Sent: Wednesday, August 02, 2006 8:07 PM Subject: [gsharp-devel] "bar" or "measure" > Hello, > > Magnus Johansson has suggested that Gsharp use the term "bar", rather > than "measure" in the user documentation to indicate the music > material between two barlines. > > The book by Ross uses "measure" rather than "bar" but it uses > "barline", and not "measure line" (which I have never heard). What do > other authors use? EMJ: I believe "bar" is being used more and more, and "measure" becoming obsolete. "Measure" is heard more often in the USA than elsewhere. > > Internally, of course, there is still a distinction between "bar", > which is the music material between two barlines within a layer, and > "measure" which is the music material between two barlines of every > layer, but this fact does not necessarily influence our choice of > user-level terminology. > > On the other hand, we might want to make that distinction to the user > as well, in which case we might as well use the same one internally > and to the user. EMJ: Yes, absolutely. I would like to suggest: "system bar" instead of "measure". > Comments? > -- > 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. > --------------------------------------------------------------------- > _______________________________________________ > gsharp-devel site list > gsharp-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/gsharp-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eolin at telia.com Thu Aug 3 09:49:15 2006 From: eolin at telia.com (Eolin KB) Date: Thu, 3 Aug 2006 11:49:15 +0200 Subject: [gsharp-devel] suggested change of terminology References: <17616.59849.133545.359933@serveur5.labri.fr> <17617.25037.270407.688282@serveur5.labri.fr> Message-ID: <007601c6b6e2$150c2760$6538e551@eolinc1> ----- Original Message ----- From: "Robert Strandh" To: "Christophe Rhodes" Cc: Sent: Thursday, August 03, 2006 4:39 AM Subject: Re: [gsharp-devel] suggested change of terminology > Christophe Rhodes writes: > > > > > In private email, Magnus Johansson told me that a "treble clef" is a > > > "G clef" on line 2 (in Gsharp terminology) and a "bass clef" is an "F > > > clef" on line 6 (idem). This is not the terminology that Gsharp uses > > > at the moment. In the book by Ross, I can't find any support for what > > > Magnus told me, but on the other hand, it is consistent with it. Ross > > > simply says that the treble clef and the bass clef never move. > > > > This is true. There are other names for other clef/line combinations > > (e.g. "tenor", "alto" and "soprano" for various positions of the C > > clef). > > OK, so instead of my initial suggestion, I now make the following one: > > I suggest changing the "Insert Staff Above/Below" commands so that > they initially prompt for a clef. The only choices possible will > be names of clef/line combinations (treble, bass, soprano, tenor, > alto) and no question about the line will be asked. EMJ: The possibility of having a staff without a clef is desirable. > Finally, I suggest adding commands to move the clef of a staff up or > down n > lines according to a numeric argument. > > > Incidentally, there's a tricky terminological issue. Moving a clef > > higher means lowering the pitch of the lines: so naming the command > > should aim to be clear; maybe Move Clef Up? > > Sure, that's fine. > > > Fine by me, though it gets more complicated, again. Firstly, there's > > the issue of the 8va treble clef, which has a (slightly) different > > glyph. > > Right. I guess that could be one of the choices. > > > Secondly, there's the issue that several orchestral > > instruments have transposing clefs -- that is, a clef where the > > pitches played sound a constant interval away from the notated pitch. > > (Normal examples: trumpets and clarinets, the latter having the > > additional amusement that there are several instruments and several > > transpositions). This should probably be handled by the clef object > > rather than the name for the glyph, but it does add to the complexity. > > I agree. I suggest introducing a "transpose interval" to a clef that > will handle that, and that will initially be 0 (is it possible to > indicate it with a numeric value?), EMJ: Yes, for example in semitone steps, e.g. clarinet in Bb would have -2. Some scores have this number (2) written below the clef; it is not to be considered a standard, though, as is the case of octave transposing instruments. > and that can be altered. It would probably be nice if the input method > could either take that interval > into account (for people who think about pitch rather than notation) > or not (for the others). EMJ: Normally not, if I understand you right. When you are working on a transposing score and want to input notes in a part for e.g. trumpet in Bb, you usually want to input the tranposed notes and not the sounding ones. That is, you want to type c for getting a written C inserted though it will sound a Bb when played. But if the mentioned feature is optional, why not? Some may perhaps become very happy with it. Regards, Magnus > > -- > 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. > --------------------------------------------------------------------- > _______________________________________________ > gsharp-devel site list > gsharp-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/gsharp-devel > From eolin at telia.com Thu Aug 3 11:01:06 2006 From: eolin at telia.com (Eolin KB) Date: Thu, 3 Aug 2006 13:01:06 +0200 Subject: [gsharp-devel] Clefs Message-ID: <000801c6b6ec$1ec28740$6538e551@eolinc1> Hello! While we are at clefs, I suggest the handling of the following in Gsharp: French violin clef (= G clef on the first staff line) Crotales clef (= G clef on the second staff line with the number 15 above) Xylophone clef (= G clef on the second staff line with the number 8 above) Treble clef (= G clef on the second staff line) Guitar clef (= G clef on the second staff line with the number 8 below) Soprano clef (= C clef on the first staff line) Mezzosoprano clef (= C clef on the second staff line) Alto clef (= C clef on the third staff line) Tenor clef (= C clef on the fourth staff line) Baritone C clef (= C clef on the fifth staff line) Baritone F clef (= F clef on the third staff line) Bass clef (= F clef on the fourth staff line) Sub-bass clef (= F clef on the fifth staff line) Modern celesta clef (= F clef on the fourth staff line with the number 15 above) Old celesta clef (= F clef on the fourth staff line with the number 8 above) Contrabass clef (= F clef on the fourth staff line with the number 8 below) Unpitched percussion clefs (at least the "two-bars clef" and the "box clef") Regards, Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From strandh at labri.fr Thu Aug 3 19:15:54 2006 From: strandh at labri.fr (Robert Strandh) Date: Thu, 3 Aug 2006 21:15:54 +0200 Subject: [gsharp-devel] suggested change of terminology In-Reply-To: <007601c6b6e2$150c2760$6538e551@eolinc1> References: <17616.59849.133545.359933@serveur5.labri.fr> <17617.25037.270407.688282@serveur5.labri.fr> <007601c6b6e2$150c2760$6538e551@eolinc1> Message-ID: <17618.19306.264144.868042@serveur5.labri.fr> Eolin KB writes: > > EMJ: The possibility of having a staff without a clef is desirable. Currently, there must at least be a virtual one that determines the placement of a notehead as a function of the pitch, since the pitch is what is intrinsic to notes. I suggest making this a rendering option instead. > > I agree. I suggest introducing a "transpose interval" to a clef that > > will handle that, and that will initially be 0 (is it possible to > > indicate it with a numeric value?), > > EMJ: Yes, for example in semitone steps, e.g. clarinet in Bb would have -2. > Some scores have this number (2) written below the clef; it is not to be > considered a standard, though, as is the case of octave transposing > instruments. I guess you are right. If we restrict ourselves to key signatures with up to 6 alterations, then with the exception of F# and Gb, a given piano key has a unique key signature. > > and that can be altered. It would probably be nice if the input method > > could either take that interval > > into account (for people who think about pitch rather than notation) > > or not (for the others). > > EMJ: Normally not, if I understand you right. When you are working on a > transposing score and want to input notes in a part for e.g. trumpet in Bb, > you usually want to input the tranposed notes and not the sounding ones. > That is, you want to type c for getting a written C inserted though it will > sound a Bb when played. But if the mentioned feature is optional, why not? > Some may perhaps become very happy with it. I would be one of those. Otherwise, I would have to first transpose in my head, only to have the software undo it. But I can see how players of such transposed instruments think "C" when the sound of a Bb is heard. That must be a nightmare for people with perfect pitch, though. -- 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 eolin at telia.com Thu Aug 3 20:15:50 2006 From: eolin at telia.com (Eolin KB) Date: Thu, 3 Aug 2006 22:15:50 +0200 Subject: [gsharp-devel] suggested change of terminology References: <17616.59849.133545.359933@serveur5.labri.fr><17617.25037.270407.688282@serveur5.labri.fr><007601c6b6e2$150c2760$6538e551@eolinc1> <17618.19306.264144.868042@serveur5.labri.fr> Message-ID: <000301c6b739$9e2fcef0$6538e551@eolinc1> ----- Original Message ----- From: "Robert Strandh" To: "Eolin KB" Cc: Sent: Thursday, August 03, 2006 9:15 PM Subject: Re: [gsharp-devel] suggested change of terminology > Eolin KB writes: > > > > EMJ: The possibility of having a staff without a clef is desirable. > > Currently, there must at least be a virtual one that determines the > placement of a notehead as a function of the pitch, since the pitch is > what is intrinsic to notes. I suggest making this a rendering option > instead. EMJ: In the way of say an invisible treble clef then? > I guess you are right. If we restrict ourselves to key signatures > with up to 6 alterations, then with the exception of F# and Gb, a > given piano key has a unique key signature. EMJ: Apropos of key signatures: I would like to see at least 7 sharps or flats so C#- and Cb major together with A#- and Ab minor are feasible. > > > It would probably be nice if the input method > > > could either take that interval > > > into account (for people who think about pitch rather than notation) > > > or not (for the others). > > > > EMJ: Normally not, if I understand you right. When you are working on a > > transposing score and want to input notes in a part for e.g. trumpet in > > Bb, > > you usually want to input the tranposed notes and not the sounding ones. > > That is, you want to type c for getting a written C inserted though it > > will > > sound a Bb when played. But if the mentioned feature is optional, why > > not? > > Some may perhaps become very happy with it. > > I would be one of those. Otherwise, I would have to first transpose > in my head, only to have the software undo it. EMJ: Wouldn't you be satisfied with inputting the notes in an untransposed score (a so called score in C) or part instead, like a trumpet in Bb part written at sounding pitch? From anders at kandav.com Wed Aug 23 06:10:24 2006 From: anders at kandav.com (Anders Davidsson) Date: Tue, 22 Aug 2006 23:10:24 -0700 (PDT) Subject: [gsharp-devel] Installing Gsharp Message-ID: <20060823061024.83899.qmail@web504.biz.mail.mud.yahoo.com> Hi, my name is Anders Davidsson and I wonder if someone can help me to install Gsharp on my system. I'm running Fedora 5 with CMUCL 19c as my Lisp. According to Gsharp documentation, CLIM and MK:DEFSYSTEM must be part of the core image. I need help to get CLIM and MK:DEFSYSTEM into my image. I have downloaded CLOCC to get DEFSYSTEM but not managed to compile it. I've also downloaded CLIM mcclim-0-9-2 but I need help to get it into my Lisp image. Regards Anders Davidsson -------------- next part -------------- An HTML attachment was scrubbed... URL: From strandh at labri.fr Wed Aug 23 08:53:50 2006 From: strandh at labri.fr (Robert Strandh) Date: Wed, 23 Aug 2006 10:53:50 +0200 Subject: [gsharp-devel] Installing Gsharp In-Reply-To: <20060823061024.83899.qmail@web504.biz.mail.mud.yahoo.com> References: <20060823061024.83899.qmail@web504.biz.mail.mud.yahoo.com> Message-ID: <17644.6046.118532.467184@serveur5.labri.fr> Anders Davidsson writes: > Hi, > my name is Anders Davidsson and I wonder if someone can help me to > install Gsharp on my system. I'm running Fedora 5 with CMUCL 19c as my > Lisp. Actually, most Gsharp developers probably use SBCL rather than CMUCL. I don't know how well maintained CMUCL is these days with respect to things like CLX, McCLIM, etc. I am not saying it is not maintained; I just don't know. > According to Gsharp documentation, CLIM and MK:DEFSYSTEM must be > part of the core image. That is no longer true. In fact, ASDF is probably preferable to MK:DEFSYSTEM these days. > I need help to get CLIM and MK:DEFSYSTEM into > my image. I have downloaded CLOCC to get DEFSYSTEM but not managed to > compile it. I've also downloaded CLIM mcclim-0-9-2 but I need help to > get it into my Lisp image. Once you have ASDF, you should be able to install both McCLIM and Gsharp easily. -- 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. ---------------------------------------------------------------------