Neueste Beiträge

Seiten: [1] 2 3 ... 10
1
Gesang / Antw:Liedtext: Stumme bzw. nichtsilbische Präpositionen weiter links positionieren
« Letzter Beitrag von fabian am Donnerstag, 16. Januar 2020, 21:33 »
Hallo harm6,
herzlichen Dank für Deinen Beitrag! Ich denke, das ist genau das, was ich suche.

Vielleicht kannst du (oder jemand anderes) mir erklären, wie das funktioniert? Irgendwie verstehe ich die Logik dahinter nicht. Wahrscheinlich habe ich irgendwie einen falschen Denkansatz. Normalerweise würde ich den Befehl \set ignoreMelismata = ##t so verstehen:

  • Treffen zwei Silben (z. B. to-mu) normalerweise auf ein Melisma in den Noten, so wird nur die erste der Notenfolge zugeordnet. Die zweite kommt nach dem Melisma.
  • Wird der genannte Befehl (ignoreMelismata) benutzt, so kommt die erste Silbe (to) auf die erste Note, die zweite (mu) auf den Rest des Melismas.
  • Ich hätte die Textverbindung "k to" (bzw. k_to) intuitiv mit einer normalen Silbe gleichgesetzt, die sich so verhält wie die erste Silbe (to) in den Punkten 1 und 2.
  • Unter http://lilypond.org/doc/v2.19/Documentation/notation/stanzas#stanzas-with-different-rhythms steht explizit unter »Bekannte Probleme und Warnungen«, dass der Befehl \set ignoreMelismata nicht zusammen mit dem Befehl \once funktioniert. Vor einer normalen Silbe trifft das offenbar auch zu. Vor den hier diskutierten Zusammensetzungen scheint es zu funktionieren, nur ist das Resultat ein anderes. (Der erste Teil der Zusammensetzung steht zwischen der Vorgängernote und der ersten Note des Melismas, der Abstand zwischen diesen beiden Noten ist vergrößert.) Ist dieses Verhalten irgendwo beschrieben?

Auf jeden Fall nochmal ein herzliches Dankeschön! Die Frage kann als gelöst betrachtet werden.
2
Fragen und Probleme aller Art / Antw:Zeilenlängenbug (Windows-Exklusiv?)
« Letzter Beitrag von harm6 am Dienstag, 14. Januar 2020, 23:02 »
Zitat von: Arnold
Eventuell kannst Du dieses »Projekt« ja auch in Salzburg kurz ansprechen

Mach ich, falls sich die Gelgenheit ergibt.

Gruß,
  Harm
3
Fragen und Probleme aller Art / Antw:Zeilenlängenbug (Windows-Exklusiv?)
« Letzter Beitrag von Arnold am Dienstag, 14. Januar 2020, 12:58 »
Hallo Harm,

die Zeit ist kein Problem. Eventuell kannst Du dieses »Projekt« ja auch in Salzburg kurz ansprechen - vielleicht nur den folgenden Abschnitt »Hintergrund« weitergeben.

Und, wie Du wohl schon vermutet hast, der Code in main.cc würde das erledigen, was sonst die DLL noch nachträglich erledigen kann.
Dann ist also keine DLL und kein zusätzlicher SCHEME-Code mehr nötig.
Und manche »bugs due to floating point precision truncation on upredictable places« würden auch behoben.


Hintergrund:

Zitat aus main.cc:
x86 defaults to using 80-bit extended precision arithmetic. This can cause problems because the truncation from 80 bits to 64 bits can occur in unpredictable places. To get around this, we tell the x87 FPU to use only double precision. Note that this is not needed for x86_64 because that uses the SSE unit by default instead of the x87 FPU.

Unser LILYPOND-Problem unter Windows: In MINGW steht der zu diesem Zweck verwendete Aufruf _FPU_SETCW (und fpu_control.h) nicht (mehr) zur Verfügung. (Das ist ein Ergebnis der bisherigen Tests)
Ob der Text unter https://600800.xyz/software/gnulib/manual/html_node/fpu_005fcontrol_002eh.html#fpu_005fcontrol_002eh noch aktuell ist?
11.14 fpu_control.h
Handling of the FPU control word. Defines the fpu_control_t type, declares the __fpu_control variable, and defines the _FPU_GETCW, _FPU_SETCW macros.
Portability problems not fixed by Gnulib:
This header file is missing on all non-glibc platforms: Mac OS X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1, HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 11.4, Cygwin, mingw, MSVC 14, Interix 3.5, BeOS, Android 9.0.


Mein Lösungsansatz für Lilypond:
Wenn diese Include-Datei fehlt, dann (exclusiv für MINGW-32Bit-Übersetzung) diese Aktion in Assembler ausführen.


Arnold
4
Fragen und Probleme aller Art / Antw:Zeilenlängenbug (Windows-Exklusiv?)
« Letzter Beitrag von harm6 am Dienstag, 14. Januar 2020, 10:44 »
Zitat
Und jetzt noch eine Bitte an Dich, Harm!
Kannst Du nochmal eine verändere Windows-Version erstellen?
Entweder vom aktuellen Develop-Stand oder von der 2.19.83 ausgehend nur die zusätzlichen Zeilen in lily/main.cc wie in meinem vorigen Beitrag angegeben (die Zeilen, bei denen ein Plus-Zeichen vorangestellt ist) hinzufügen.

Kann ich machen, aber erst nachdem ich aus Salzburg zurück bin und Zeit dafür finde.
Realistisch gesehen also erst in 2 Wochen...

Noch ein paar Fragen: Nachdem lily/main.cc mit Deinem Vorschlag gepatched ist, braucht der windows user die DLL-Datei dann noch oder sollte sie irgendwo mit in den Installer gepackt werden?

Der Code, beginnend:
    #(let ((dynlib (dynamic-link "./x87mant53.dll"))) ...)
könnte ja auch nur bei Abfrage von
    (if (eq? PLATFORM 'windows)
ausgeführt werden.
Ist das sinnvoll oder macht das main.cc dann schon?

Wie Du aus den Fragen ersehen kannst, habe ich die geplanten Abläufe nicht wirklich verstanden ...


Gruß,
  Harm
5
Fragen und Probleme aller Art / Antw:Zeilenlängenbug (Windows-Exklusiv?)
« Letzter Beitrag von Arnold am Dienstag, 14. Januar 2020, 10:23 »
Hallo Harm,

die Beschreibung für Windows-Anwender, welche aus der Kommandozeile übersetzen:
  • ZIP-Datei (Anhang im 4. Beitrag) herunterladen, und die darin enthaltene Datei »x87mant53.dll« in das Verzeichnis extrahieren, aus dem heraus Lilypond gestartet wird.
  • In der LY-Datei, welche man übersetzen will, den 4-zeiligen SCHEME-Abschnitt hineinkopieren (oberste Ebene, am besten vor allen anderen Anweisungen)
  • Lilypondübersetzung wie gewohnt starten

Bei Frescobaldi-Anwendern (unter Windows natürlcih) weiß ich nicht, was als Arbeitsverzeichnis benutzt wird. So würde ich ausprobieren, die DLL-Datei sowohl in das in der Windows-Startverknüpfung angegebene Arbeitsverzeichnis, als auch in das Verzeichnis, wo die LY-Datei liegt, abzulegen.

Hier nocheinmal die entscheidenden SCHEME-Zeilen:
#(let ((dynlib (dynamic-link "./x87mant53.dll")))
  (ly:progress "\nGoing to set X87 mantissa length via DLL procedure ... ")
  (dynamic-call "X87mantissa53" dynlib)
  (ly:progress "done.\n"))
Wird die DLL-Datei nicht gefunden, dann wird ein allgemeiner SCHEME-Fehler von Lilypond angezeigt. Wenn alles durchlaüft, dann wird die Meldung »Going to set X87 mantissa length via DLL procedure ... done.« im Fortschritts-Protokoll angezeigt.

Man kann natürlich auch die DLL-Datei in ein beliebiges Verzeichnis ablegen, und diesen Pfad dann »absolut« angeben, aber bitte einen Pfad ohne Umlaute (und ohne andere nicht-US-ASCII-Zeichen) verwenden. z. Bsp.:
  • Es wurde ein Verzeichnis »C:\Programme_privat\Lilypond\myIncludes« erzeugt, in welchem eigene LY-Dateien mit Bibliotheks-Routinen-Charakter abgelegt wurden (mit der -I-Option beim Lilypondaufruf wird der Suchpfad für diese Dateien ergänzt). In das gleiche Verzeichnis wird die DLL abgelegt.
  • In der ersten Zeile der SCHEME-Anweisung wird der Pfad zur DLL entsprechend korrigiert, aber statt »\« verwendet man den normalen Schrägstrich »/«, also »#(let ((dynlib (dynamic-link "C:/Programme_privat/Lilypond/myIncludes/x87mant53.dll")))«

Als gobale Festlegung dieser »Anpassung« wäre es dann möglich, diese SCHEME-Zeilen (mit absolutem Pfad) in die Datei ».../ly/init.ly« der Lilypond-Installation zu ergänzen.



Und jetzt noch eine Bitte an Dich, Harm!
Kannst Du nochmal eine verändere Windows-Version erstellen?
Entweder vom aktuellen Develop-Stand oder von der 2.19.83 ausgehend nur die zusätzlichen Zeilen in lily/main.cc wie in meinem vorigen Beitrag angegeben (die Zeilen, bei denen ein Plus-Zeichen vorangestellt ist) hinzufügen.
Ich hoffe, daß sich kein Tippfehler eingeschlichen hat, und ich finde, daß diese Änderung dann so auch in die Produktiv-Version einfließen sollte. Wie beschrieben, wird durch diese Ergänzung (nur) bei einer MINGW-Windows-Compilation, falls _FPU_SETCW() nicht zur Verfügung steht, diese Aktion mit Assembler-Code realisiert.

Arnold
6
Fragen und Probleme aller Art / Antw:Zeilenlängenbug (Windows-Exklusiv?)
« Letzter Beitrag von harm6 am Montag, 13. Januar 2020, 23:59 »
Glückwunsch !!

Zitat
In den LY-Dateien mit den mutmaßlichen Precission-Missmatch-Seiteneffekten fügte ich hinzu, umd die DLL vom lokalen Arbeitsverzeichnis zu laden und die Prozedur darin auszuführen: [...]

Aber ich habe nicht verstanden was windows-user tun sollten/könnten.
Kannst Du eine Anleitung für dummies posten?

Ich werds auf LINUX nicht brauchen, aber vielleicht kann man ja auf der internationalen mailinglist den workaround dann posten.


Gruß,
  Harm



7
Fragen und Probleme aller Art / Antw:Zeilenlängenbug (Windows-Exklusiv?)
« Letzter Beitrag von Arnold am Montag, 13. Januar 2020, 08:58 »
HEUREKA! Workaround gefunden!

Ich fand:
  • Guile kann DLLs laden, darin eine Prozedur nach gegebenem Funktionsnamen suchen und ausführen
  • MINGW kann diese DLLs erstellen, und unterstützt in einer Prozedur Inline-Assembler-Code

So bildete ich das Initialisieren des X87-Controlwortes, zu dem die Bibliotheksfunktion _FPU_SETCW() in MINGW nicht mehr enthalten ist, als Prozedur im Assemblercode nach:
/* FILE: x87mant53.c
 * compile to DLL with MINGW installed in LILYDEV:
 *
 *    i686-w64-mingw32-gcc -shared -ox87mant53.dll x87mant53.c
 *
 */

void X87mantissa53(void)
{
  asm(
      "     push %ebp"
    "\n     mov  $0x027f, %eax"
    "\n     push %eax"
    "\n     mov  %esp, %ebp"
    "\n     fldcw (%ebp)"
    "\n     pop %eax"
    "\n     pop %ebp"
  );
}

In den LY-Dateien mit den mutmaßlichen Precission-Missmatch-Seiteneffekten fügte ich hinzu, umd die DLL vom lokalen Arbeitsverzeichnis zu laden und die Prozedur darin auszuführen:
%{
  For Windows usage only:

  Insert the following SCHEME lines near the beginning of your LY file,
  which is targeted to be compiled by LILYPOND 2.19.80 or newer - until
  the missing FPU_SETCW in MINGW is fixed.

  Or put it into 'init.ly' of your LILYPOND installation.

  BUT: check the path to this DLL!

%}

#(let ((dynlib (dynamic-link "./x87mant53.dll")))
  (ly:progress "\nGoing to set X87 mantissa length via DLL procedure ... ")
  (dynamic-call "X87mantissa53" dynlib)
  (ly:progress "done.\n"))


Damit wurde sowohl dieses Zeilenlängenproblem als auch die Seitenzahl-zu-groß-Assertion https://lilypondforum.de/index.php/topic,489.0.html (in je einem Beispiel getestet) behoben.

Folglich könnte man diesen Inline-Assembler-Code auch in main.cc in die Dummy-Version von configure_fpu() einfügen, eventuell in dieser Weise:
#include <fpu_control.h>
 static void
 configure_fpu ()
 {
   fpu_control_t fpu_control = 0x027f;
   _FPU_SETCW (fpu_control);
 }
 
 #else
 
 static void
 configure_fpu ()
 {
+#if ((defined (__x86__) || defined (__i386__)) \
+  && defined (__MINGW32__) && defined (__code_model_32__) && !defined(__SSE2_MATH__))
+  /* If this is a MINGW compilation (for Windows),
+   * but not using SSE2 arithmetic unit nor is a 64 bit compilation (which uses SSE2 by default)
+   * _FPU_SETCW() got lost in the MINGW libraries!
+   * Here is an inline assembler call to execute the same task for the X87 arithmetic unit.
+   *
+   * TODO: output a message what we're going to do here, _only_ if DEBUG level is selected,
+   *       but configure_fpu() is called before the commandline options get evaluated.
+   *       At the moment the info message will be blanked on the console, but if output is
+   *       directed into a file, most editors will show it.
+   */
+  fprintf(stderr, " X87 FPU setup via asm() ... ")
+  asm(
+      "     push %ebp"
+    "\n     mov  $0x027f, %eax"
+    "\n     push %eax"
+    "\n     mov  %esp, %ebp"
+    "\n     fldcw (%ebp)"
+    "\n     pop %eax"
+    "\n     pop %ebp"
+  );
+  fprintf(stderr, "done.\r                                 \r");
+#endif /* (defined(__x86__) || defined(__i386__)) && defined (__MINGW32__) && defined (__code_model_32__) && !defined(__SSE2_MATH__) */
 }

 #endif /* defined(__x86__) || defined(__i386__) */
(Änderung 2020-01-13: fprintf-Meldung optimiert)

Arnold

8
Fragen und Probleme aller Art / Antw:Durchstreichung im Markup
« Letzter Beitrag von Kuchenmampfer am Sonntag, 12. Januar 2020, 17:33 »
Vielen Dank Harm,

genau sowas suchte ich :D

Viele Grüße,
Kuchenmampfer
9
Fragen und Probleme aller Art / Antw:Durchstreichung im Markup
« Letzter Beitrag von harm6 am Sonntag, 12. Januar 2020, 12:29 »
Hallo,

willkommen im Forum

Ich habe dafür schon verschiedenes benutzt.

Manchmal reicht schon "D̸". Ein Schriftzeichen welches das "D" mit einem "backspaced slash" kombiniert. Bzw "S̸".

Oder
#(define-markup-command (diagonal-stroke layout props arg)
  (markup?)
  #:category font
  #:properties ((font-size 0) (thickness 1.5) (extension 0.07))
  (let*
   ((thick (* (magstep font-size)
      (ly:output-def-lookup layout 'line-thickness)))
    (underline-thick (* thickness thick))
    (markup (interpret-markup layout props arg))
    (x1 (car (ly:stencil-extent markup X)))
    (x2 (cdr (ly:stencil-extent markup X)))
    (y1 (car (ly:stencil-extent markup Y)))
    (y2 (cdr (ly:stencil-extent markup Y)))
    (dx (* extension (- x2 x1)))
    (dy (* extension (- y2 y1)))
    (line (make-line-stencil underline-thick
      (- x1 dx) (- y1 dy)
      (+ x2 dx) (+ y2 dy))))
   (ly:stencil-add markup line)))
Aus
http://lilypond.org/doc/v2.19/Documentation/music-glossary/functional-harmony
click auf das Bild.


Oder schreib ein eigenes Markup-command zur Kombination einer Linie und eines Buchstabens.
In der simpelsten Form ist seit neuestem folgendes möglich.

\version "2.19.83"

%% Definition
\markup diagonalStroke = \markup \combine \draw-line #'(1.6 . 1.6) \etc

%% Beispiel
\markup \diagonalStroke #"D"



HTH,
  Harm



10
Fragen und Probleme aller Art / Durchstreichung im Markup - gelöst
« Letzter Beitrag von Kuchenmampfer am Samstag, 11. Januar 2020, 22:57 »
Moin zusammen,

ich würde gerne unter einen Akkord in kurzer Schreibweise schreiben, dass es sich um einen verkürzten Dominantseptakkord handelt. Auf folgendes bin ich bisher gekommen:
\markup { D\super7 }
Jetzt muss das D noch durchgestrichen werden. Kann mir jemand weiterhelfen, wie das geht?

Vielen Dank und viele Grüße :)
Seiten: [1] 2 3 ... 10