Taktzahlen für alle Instrumente

Begonnen von unique75m, Mittwoch, 18. April 2018, 18:38

« vorheriges - nächstes »

harm6

Hallo zusammen,

ein paar Bemerkungen zu einigem aus den letzten beiden posts hier. Ich gehe nur auf ausgewählte Punkte ein, was nicht heißen soll, daß andere nicht kommentierungs- oder diskussionswürdig seien.

Zitat von: rgreeTatsächlich gibt Lilypond viele Kröten zu schlucken, die ja auch teilweise genannt wurden.
Ich würde noch ergänzen,
- dass ich es erstaunlich finde, dass ausgerechnet eine solch skurrile Programmiersprache wie das Lisp-Derivat "Scheme" (ich kenne ungefähr 10 Programmiersprachen ganz gut)
  als Interface-Spache gewählt wurde; sie ist - nach meiner Beobachtung und was hier so im Forum ausgebreitet wird -
  für das Gros der Lilypond-Anwender (insbes. ohne IT-Hintergrund) extrem gegen-intuitiv; was übrigens nach meinem Geschmack auch für viele Scheme-Funktionen gilt;

Interface-Sprache ist ja nicht ganz korrekt. Es ist nicht nur die LilyPond-Erweiterungssprache, sondern die offizielle GNU-Erweiterungssparche.
https://www.gnu.org/software/guile/

Ansonsten bin ich der Ansicht, daß sich Computer-Nutzer eines erweiterbaren Programs ohne jegliche Programmiererfahrung mit jeder Erweiterungs-Sprache schwertun werden. Das ist natürlich nur meine persönliche Ansicht. Aber es ist nicht schwer vorzustellen, daß das Erlernen einer Sprache, welcher auch immer, Zeit und Arbeit erfordert.
Jedoch habe ich die Erfahrung gemacht, daß sich gerade Personen mit Programmiervorkenntnissen, bis hin zu IT-Spezialisten, mit Scheme, genauer Guile, schwer tun. Ich wage die Vermutung, daß die Vorkenntnisse eher im Wege stehen als hilfreich sind.

Ich selbst habe übrigens keinerlei IT-Ausbildung, sondern guile im Selbststudium erlernt, um LilyPond für meine Zwecke zu erweitern.

Zitat von: rgree- dass eigentlich eine vernünftige Preprozessor-Sprache fehlt,
Zitat von: unique75mModularität, wiederverwendbarer Code und hierarchische Dateitemplates werden meiner Meinung nach sehr mangelhaft von Lillypond unterstützt.
Zitat von: unique75mMir fehlt hier eindeutig ein Präprozessor oder zumindest eine Lilypond-Funktion für einen if-Befehl, damit man bedingte Kompilierung machen kann.

LilyPond ist ein open-source Programm. Die meisten features sind implementiert worden, weil jemand sie haben wollte und sich die Mühe gemacht hat entsprechende patches zu erstellen und sich dem review-Prozedere zu stellen (Das gilt auch für viele meiner eigenen patches)

Mit anderen Worten: patches are welcome.

Zitat von: unique75mWas nützt mir die schönste Ausgabe, wenn ich selbst bei trivialen Dingen massive Probleme habe, stundenlang Doku wälzen muss, um dann doch mal irgendein mystisches Codeschnipsel zu finden. Am Ende der Pipeline soll ein Ferrari rauskommen, aber während der Produktion habe ich nur den Faustkeil benutzt.

Solange Du die "trivialen" Dinge nicht benennst, kann niemand etwas dazu sagen ;)
Aber LilyPond ist sehr umfangreich in ihren Möglichkeiten. Zugegebenermaßen dauert es seine Zeit bis man gut damit zurecht kommt.
Es wäre schön gewesen Du hättest den letzten Satz anders fomuliert. Mir persönlich kommt er unangemessen agressiv vor.
Nicht das ich ihm inhaltlich zustimmen würde ...

Zitat von: unique75m
Ansonsten darf mir irgendwer mal gern erklären, wie ich ein Buch mit 4 Scores zu je 12 Staffs + PianoStaff mit bis zu 3 Voices pro Staff anlege. Ich möchte dieses Buch als Gesamtkunstwerk drucken, dann aber auch gezielt von allen Scores nur die Violinstimme mit anderem Papierformat. Ich werde hier den Teufel tun und auf keinen Fall hier alles in eine Gesamt-Struktur-Datei kippen, um dann die dynamischen Teile von außen per Variablen zu kontrollieren. Das ist reinster Spaghetti-Code, den man nach 2 Tagen nicht mehr versteht. Ich teile meine Dateien hierarchisch auf. Eine book.ly inkludiert die einzelnen scoreXX.ly, diese includieren wiederum die vielen staffXX.ly und diese wiederum die voiceXX.ly.

Nun habe ich noch nicht verstanden was Du mit "Gesamt-Struktur-Datei" meinst und deshalb natürlich auch nicht was Dir daran nicht zusagt...

Aber es scheint, daß Dein Wollen und LilyPonds Möglichkeiten nicht zusammenfinden.
Da sehe ich nur ein paar Möglichkeiten:
Ändere Deine Vorstellung wie Du Deinen Plan ausführen willst.
Oder ändere LilyPond (s.o. patches are ...)
Vielleichtgibt es ja auch bereits etwas, an das niemand hier bislang dachte.
Oder jemand entwickelt etwas (s.o. patches ...)
Was mich selbst angeht, so habe ich momentan gleich mehrere Projekte rumzuliegen, deshalb bin ich Deiner Fragestellung bislang nur sehr zeit-limitiert nachgegangen.

Zitat von: unique75mMir scheint es auch so zu sein, dass man außerhalb von book oder score nicht jedwede Variablendefinition machen kann.

Eigentlich wird anders herum ein Schuh draus.
In einem book/score kann man keine Variable definieren.

Gruß,
  Harm



Manuela

Ich möchte mich Harms Post anschließen.  :)

Lilypond ist ein geniales Programm, das allerdings einige Einarbeitungszeit benötigt, ich habe mir manch blutige Nase geholt beim Versuch, irgendwas umzusetzen was aus jetziger Sicht völliger Unsinn war. Niemand muss es verwenden, jeder kann und darf, wenn er will  ;)

Aus eigener Erfahrung kann ich sagen, dass Programmierkenntnisse tatsächlich dem Verständnis von Scheme/Guile im Weg stehen.
Danke für eure Hilfe
viele Grüße
-- Manuela

unique75m

Lieber Harm,

ich denke meine trivialen Dinge habe ich genannt :-)

Ich benötige einen if-Befehl, der überall funktioniert und nicht nur innerhalb von Kontexten, wo musikalische Definitionen erlaubt sind.

Des Weiteren konnte mir auch bisher niemand erklären, wie man vernünftig ein Buch mit 4 Scores zu je 12 Staffs zu je 3 Voices erstellt , sodaß auch Teilauszüge einzelner Stimmen druckbar sind. Die bisherigen Antworten in den anderen Threads waren nur, bau die gesamte Struktur in eine Datei und eine andere Datei, wo die ganzen Notendefinitionen stehen. Es dürfte klar sein, dass beide Dateien riesengroß und unleserlich werden. Zudem fange ich dann wohl auch an die Strukturdatei jedesmal zu kopieren, um die ungewünschten Scores/Staffs/Voices zu entfernen. Wenn man diesen Strukturcode ebenfalls rauszieht in Variablen, was nach meiner Erfahrung bisher, auch nicht immer funktioniert, dann gewinnt man auch keinen Blumentopf, weil man dann alles inhaltlich zerreißt. So verwaltet man nunmal keine großen Projekte.

Die einzigste Lösung, die ich momentan sehe ist, dass ich mich von dem Gedanken verabschiede ein Buch mit 4 Scores zu machen. Dann baue ich eben jeden Score separat und benutze meine if-equal-Funktion zum bedingten Kompilieren nur innerhalb des score. Nur frage ich mich eben, wo dann der Anspruch von Lilypond bleibt, dass man damit große Partituren machen kann und Einzelauszüge aus den gleichen Quellen, wenn man doch immer ständig nur um die Probleme herum schifft bzw. diese sich zurechtbiegt, bis es irgendwie passt.

Ich sehe mich auch nicht in der Situation, dass ich mich in ein OpenSource-Projekt derart tief einarbeite, damit ich dort irgendwelche Patches am Quellcode vornehmen kann. Dazu fehlt mir schlicht und einfach die Zeit und vor allem die Lust. Dann kann ich mir auch gleich einen eigenen Engraver in meiner Lieblingssprache bauen.

Mag sein das Manuela Recht hat und nach gewisser Einarbeitungszeit die große Erleuchtung kommt. Immerhin habe ich ja schon ein bisschen dazu gelernt. Mein Ziel ist aber eben, dass ich am Ende eine Art Template habe, was leicht lesbar und erweiterbar ist, sodaß man sowas evt. auch einem Geigenlehrer älteren Jahrgangs in die Hand drücken kann.

Vielen Dank für Eure Hilfe soweit :-)


harm6

Hallo unique,

Zitatich denke meine trivialen Dinge habe ich genannt :-)
Eigentlich nicht.
Ich hab nochmal alle Deine Beiträge gelesen und drei Themen gefunden.
Taktzahlen und tags waren zwei davon. Beide beantwortet und gelöst, imho.

Das dritte ist Dein "if",
Dazu:
ZitatDes Weiteren konnte mir auch bisher niemand erklären, wie man vernünftig ein Buch mit 4 Scores zu je 12 Staffs zu je 3 Voices erstellt , sodaß auch Teilauszüge einzelner Stimmen druckbar sind.
Doch, aber
Zitat
Die bisherigen Antworten in den anderen Threads waren nur, bau die gesamte Struktur in eine Datei und eine andere Datei, wo die ganzen Notendefinitionen stehen.
die Antwort hat Dir nicht gefallen ;)

Es sollte alledings machbar sein eine Funktion zu schreiben die als Eingabe eine Liste von Voices erhält und ein book ausgibt.
Falls ich Zeit finde denk ich mal drüber nach wie das gehen kann und was diese Funktion vielleicht sonst noch braucht. Kann aber ne' Woche dauern...

ZitatIch sehe mich auch nicht in der Situation, dass ich mich in ein OpenSource-Projekt derart tief einarbeite, damit ich dort irgendwelche Patches am Quellcode vornehmen kann. Dazu fehlt mir schlicht und einfach die Zeit und vor allem die Lust. Dann kann ich mir auch gleich einen eigenen Engraver in meiner Lieblingssprache bauen.
Zeitprobleme versteh ich sehr gut.
Das mit der Lust ist natürlich so n' Sache.
Ich hab' auch nicht immer Lust Fragen zu beantworten, kostet ja auch Zeit ;)

Gruß,
  Harm




unique75m

Hallo lieber Harm,

eigentlich sind es nur 2 Beiträge. Einmal ging es um die Taktzahlen, die sind ja nun gelöst. Das zweite ist das Thema, wie man aus einem Quellcode verschiedene Editionen baut. Dort werden auch die Tags erwähnt und auch ein if-Befehl. Das sind nur mögliche Lösungsansätze, um bedingte Kompilierung hinzukriegen. Ob ich die verschiedenen Editionen nun mit Tags, einem if-Befehl oder sonstigem hinkriege, ist mir eigentlich egal, nur es sollte eine generell funktionierende Lösung sein, die auch außerhalb von Score und Book funktioniert. Daran scheitern momentan alle genannten Lösungen.

Ein Vorschlag, der darauf hinausläuft, dass mein Projekt unleserlich und unwartbar wird, ist für mich keine zufriedenstellende Lösung. Wenn man die gesamte Struktur eines Buches mit 4 Scores, 12 Staffs und 3 Voices in einer einzigen Datei ablegt und dann alles mögliche mit Variablen dynamisiert, dann blicke ich da jedenfalls nicht mehr durch und mein Geigenlehrer erst recht nicht. Baue ich ein Projekt modularisiert auf, dann steht in den Dateien nur das notwendige, was da hingehört. Score-Eigenschaften sind in score.ly, Voice-Eigenschaften sind in voice.ly usw.. Die Dinge sind überschaubar kurz und das Zusammengehörige ist auch zusammen und nicht quer verstreut über 100 Variablen.

Bitte spare dir deine kostbare Zeit, eine Funktion zu schreiben, die ein Buch ausgibt. Ich denke das würde nicht meinen Anforderungen entsprechen. Da wüsste ich schon mal garnicht, wie ich mir eine solche Funktion vorstellen soll, wenn man die ganzen \header Variablen einstellen will, einen eigenen \paper-Block usw.. Das artet doch dann in einer Funktion mit 100 Parametern aus  :)

Trotzdem vielen Dank, dass du deine wertvolle Zeit opferst, meine Problemchen anzuschauen  :)
Früher wo ich jung und dynamisch war, hab ich oft einfach drauf los programmiert und nicht über die Zeit nachgedacht. Da hat man dann auch mal Jahre damit verbracht in Assembler hardwarenahe Spiele zu schreiben. Heute bewerte ich eigentlich eher eine Software danach, wieviel Nerven und Lebenszeit mich das kostet :)
Ich glaube das ist wie bei den Autos, manche basteln eben liebend gerne an jeder Schraube herum, machen den Ölwechsel selbst und andere wollen das Ding nur fahren. Ich gehöre mittlerweile zu der zweiten Gattung und möchte ohne viel Widerstand mein Ziel erreichen :-)

harm6

Hallo unique,

ZitatBitte spare dir deine kostbare Zeit, eine Funktion zu schreiben, die ein Buch ausgibt. Ich denke das würde nicht meinen Anforderungen entsprechen. Da wüsste ich schon mal garnicht, wie ich mir eine solche Funktion vorstellen soll, wenn man die ganzen \header Variablen einstellen will, einen eigenen \paper-Block usw.. Das artet doch dann in einer Funktion mit 100 Parametern aus

Einerseits bezweifel ich, daß eine solche Funktion wirklich so chaotisch werden würde, andrerseits kann man das nicht wirklich wissen bevor man nicht ein paar Schritte in diese Richtung gegangen ist.

Ich setz mich wahrscheinlich mal dran, aber vor Ablauf dieser Woche wird es nichts und danach auch nur mit nicht höchster Priorität. ;)
(Im Moment beschäftige ich mich hauptsächlich damit ein neues grob zu erschaffen, welches nicht so will wie ich möchte, grrrrrr...)

Aber der Problemkreis taucht immer mal wieder auf. Ich hatte ja auch schon auf Jan-Peters Herangehensweise verwiesen. das Thema weiter auszuloten kann eigentlich nicht sinnlos sein ...


Gruß,
  Harm


Hilflos-im-Code

Zitat von: harm6 am Montag, 14. Mai 2018, 23:13

Jedoch habe ich die Erfahrung gemacht, daß sich gerade Personen mit Programmiervorkenntnissen, bis hin zu IT-Spezialisten, mit Scheme, genauer Guile, schwer tun. Ich wage die Vermutung, daß die Vorkenntnisse eher im Wege stehen als hilfreich sind.

Weil es bestimmte Konzepte und Wege gibt, wie so etwas aufgebaut ist. Wenn  diesen Konzepten nicht ensprochen wird, macht man es den Leuten schwerer.

Zitat von: harm6 am Montag, 14. Mai 2018, 23:13

Solange Du die "trivialen" Dinge nicht benennst, kann niemand etwas dazu sagen
Damit kann ich dienen. Bisher habe ich es in jeder Computersprache selbstständig geschafft, herauszufinden wie man Strings "addiert", sodass kein Leerzeichen zwischen den Strings ist.

Der Grund ist einfach, weil so etwas bei den mir genutzten Sprachen zu den Grundübungen bei den entsprechenden Einführungen gehört. Bei Lilypond musste ich dann hier fragen.

Einerseits weil ich nichts gefunden habe. Andererseits weil z.B. nicht klar ist, wenn ich mir eine Funktion schreibe, wessen Baustelle ist das denn nun. Lilypondsyntax oder Schemesyntax. Bei Scheme habe ich nichts gefunden. Die Antwort hier hat mich auf Lilypondsyntax verwiesen.

Und so etwas ist einfach unpraktisch.

Seit einer Woche schreibe ich das PHP meiner Wordpressinstallation wegen DSGVO um. Ich habe noch keine einzige Forenanfrage gestellt. Bitte zähle mal die Anfragen die ich in dieser Zeit hier gestellt habe.

harm6

Zitat von: Hilflos-im-CodeWeil es bestimmte Konzepte und Wege gibt, wie so etwas aufgebaut ist. Wenn  diesen Konzepten nicht ensprochen wird, macht man es den Leuten schwerer.
Das kann ich nicht wirklich beurteilen, meine Kenntnisse anderer Sprachen als guile sind zu rudimentär.

ZitatDamit kann ich dienen. Bisher habe ich es in jeder Computersprache selbstständig geschafft, herauszufinden wie man Strings "addiert", sodass kein Leerzeichen zwischen den Strings ist.

Der Grund ist einfach, weil so etwas bei den mir genutzten Sprachen zu den Grundübungen bei den entsprechenden Einführungen gehört. Bei Lilypond musste ich dann hier fragen.

Einerseits weil ich nichts gefunden habe. Andererseits weil z.B. nicht klar ist, wenn ich mir eine Funktion schreibe, wessen Baustelle ist das denn nun. Lilypondsyntax oder Schemesyntax. Bei Scheme habe ich nichts gefunden. Die Antwort hier hat mich auf Lilypondsyntax verwiesen.

LilyPondsyntax und Schemesyntax sind sehr eng verflochten.
In den entwsprechenden C++-files sind auch diverse Prozeduren definiert, die wir in scheme-Syntax innerhalb Lilypond anwenden können. Hinzu kommen natürlich die ganzen in nativem scheme definierten Sachen in all den ~.scm-files.

Bei Deinem Beispiel mit den strings ist mir die Problematik nicht klar geworden.
strings zusammenzufügen ist keine LilyPond-Syntax sondern natives guile. Das guile-manual offeriert verschiedene Möglichkeiten, je nachdem wie man die zusammenzufügenden strings "anliefert" bzw was man sonst vielleicht noch machen will, z.B.:
(string-append "a" "b" "c")
(string-concatenate '("a" "b" "c"))
(format #f "~a~a~a" "a" "b" "c")

Beim schreiben von Definitionen, Prozeduren, Funktionen im eigenen ~.ly-file kann man scheme-syntax in LilyPond einbetten. Alles was mit einem #-Zeichen in LilyPond beginnt wird an den scheme-interpreter weitergereicht, der auch Zugriff auf die in ~.cc und ~.scm-files definierten Dinge hat, und dort bearbeitet.
Man kann darüberhinaus auch wieder LilyPond-syntax in scheme einbetten. Alles was zwischen #{  #} steht, ist LilyPond.

Zitat von: Hilflos-im-CodeUnd so etwas ist einfach unpraktisch.
Da bin ich konträrer Meinung.
Ich will gerne zugestehen, daß diese Gemengelage Einarbeitungszeit erfordert. Jedoch ist die LilyPond-Syntax keine Programmiersprache, es ist eine Eingabesyntax. Will man diese erweitern, so muß man in die Sprache die für Erweiterungen vorgesehen ist wechseln können und zurück. Das kann man mittlerweile annähernd reibungslos.

Wie sonst?


Gruß,
  Harm

harm6

Noch eine Bemerkung zu:

Zitat von: rgree am Montag, 14. Mai 2018, 12:58
  Beispiel \partial
    dass z.B. \partial 4. dasselbe ist wie \partial 8*3,
    aber das so etwas wie \partial 3/8 (für mich das Intuitivste)
    nicht unterstützt wird, obwohl der \time-Befehl ja diese Art Parameter akzeptiert;
    dass dann in diesem Zusammenhang die Regel gilt, das \partial innerhalb eines Musikstücks nicht nochmal kommen darf,
    obwohl es klaglos (unter Absonderung eines Warning) funktioniert, und man stattdessen so etwas schreiben muss wie
    \set Timing.measurePosition = #(ly:make-moment -1/8) % = \partial 4. : schon wieder eine andere Art zu parametrieren;
    mir ist als IT-ler natürlich klar, dass das alles wohldefinierte Funktionen sind, aber wer kann sie ohne Doku-Studium bewältigen,
    wo doch so einfach und klar ist was man will   

\partial verlangt eine duration als Eingabe.
4. ist genauso lang wie 8*3. Möglich wäre aber auch 1*3/8 :)
Das \partial innerhalb eines bereits begonnenen Stückes nicht mehr klaglos funktioniert hat sich im Laufe der Versionen auch schon mal geändert.
In 2.19.81 funktioniert folgender Code ohne Warnung:
{
  \partial 1*3/8
  c'4.
  R1
  c'1
  \partial 8
  c'8
  R1
}


Das die Eingabe für \time anders ist, sollte aber nicht überraschen. Wie wir alle wissen ist ein 2/2 etwas anderes als ein 4/4-Takt bei gleicher Dauer. In neueren Versionen akzeptiert \time auch ein optionales Argument.
\partial und \time setzen halt völlig unterschiedliche Dinge. Die Dauer für partial ist wirklich eine Dauer, z.B. für eine 8-tel (ly:make-duration 3).
Bei \time kommt es aber darauf an was im Nenner un was im Zähler des Bruches steht.
Z.B für die automatische Bebalkung



Gruß,
  Harm

Hilflos-im-Code

Zitat von: harm6 am Mittwoch, 16. Mai 2018, 12:24

Zitat von: Hilflos-im-CodeUnd so etwas ist einfach unpraktisch.
Da bin ich konträrer Meinung.
Ich will gerne zugestehen, daß diese Gemengelage Einarbeitungszeit erfordert. Jedoch ist die LilyPond-Syntax keine Programmiersprache, es ist eine Eingabesyntax. Will man diese erweitern, so muß man in die Sprache die für Erweiterungen vorgesehen ist wechseln können und zurück. Das kann man mittlerweile annähernd reibungslos.

Harm, es gibt ein kleines Problem bei deiner Äußerung, einerseits weißt Du nicht, wie es bei anderen Computersprachen aussieht, aber urteilst doch darüber, was praktisch ist, obwohl dir der Vergleich fehlt. Wenn andere Sachen praktischer werden, dann sind praktische Sachen irgendwann unpraktisch. Die Bewertung praktisch ist auch eine vergleichende Bewertung.

harm6

Hallo Hilflos-im-Code,

im Bewußtsein meiner geringen Kenntnisse in Bezug auf andere erweitere Programme (und deren Erweiterungssprachen) hatte ich jedoch mit

Zitat von: HarmWie sonst?

geschlossen.

Das ist bislang unbeantwortet.


Gruß,
  Harm

Hilflos-im-Code

GEM =
#(define-scheme-function
  (parser location mrkp tr-val )
  (markup? pair?)
  #{
    -\tweak extra-offset #tr-val
    -\markup {

      \magnify #1
      \bold
      \with-color #darkmagenta
      %  \center-align

      %% other syntax-possibility:
      %\override #'(font-name . ,font-name-string)

      \concat \fontsize #-3 { $mrkp  g }



    }
  #})


Es geht um das \contact, deine anderen Sachen habe ich gesucht, auch gefunden, bin aber nicht weitergekommen.

harm6

Zitat von: Hilflos-im-Code
<code-skipped>
Es geht um das \contact, deine anderen Sachen habe ich gesucht, auch gefunden, bin aber nicht weitergekommen.

Bitte erwähne, zitiere oder verlinke worauf Du Dich beziehst.

Ich vermute es geht ums Thema "strings addieren".

Falls das richtig ist, so kommt es in der GEM-definition nicht vor.
In der Zeile
\concat \fontsize #-3 { $mrkp  g }
wird aus `$mrkp' (welches ein beliebiges markup ist und daher auch ein \draw-line ... sein könnte) und `g' welches zumindest intern als string gewertet wird ein Ausdruck erstellt.
Falls `$mrkp' wirklich ein beliebges markuo ist so ist /concat das einzige Mittel.
Solltest Du Dich auf Text für `$mrkp' beschränken wollen so ändere das Funktionsprädikat von markup? auf string? dann würden auch die nativen guile proceduren greifen können. Führt dann zu:


GEM =
#(define-scheme-function
  (parser location strg tr-val )
  (string? pair?)
  #{
    -\tweak extra-offset #tr-val
    -\markup {

      \magnify #1
      \bold
      \with-color #darkmagenta
      %  \center-align

      %% other syntax-possibility:
      %\override #'(font-name . ,font-name-string)
      #(string-append strg  "g")
    }
  #})
 
{
  c'1-\GEM "xy" #'(0 . 0)
}


Gruß,
  Harm