Re: Frescobaldi ... panic alternatives?
> With not too much work, you could get emacs to do all of that I > think. Well, it would be great if someone could convert the LilyPond mode of Emacs so that it uses the new 'tree-sitter' interface: https://tree-sitter.github.io/tree-sitter/ (look at the 'Playground' link to get a feeling what this tool is good for). This would allow seamless support of both Scheme and LilyPond syntax simultaneously... While there already is tree-sitter syntax support for Scheme (https://github.com/6cdh/tree-sitter-scheme, including some Guile extensions), no such thing exists yet for LilyPond syntax, which makes the conversion a larger undertaking, unfortunately. Werner
Re: Fw: Frescobaldi ... panic alternatives?
With not too much work, you could get emacs to do all of that I think. But my guess is that there's no reason to panic yet. I don't see frescobaldi magically disappearing. On Mon, Apr 29, 2024, 10:45 PM Dirck Nagy wrote: > Hi all > > Reading that last thread about Frescobaldi and its possible disappearance > from Mac is causing me to panic. Jean, I did not realize that you were the > last person to seriously work on Frescobaldi / Mac. > > > I use Mac exclusively, and Frescobaldi / Lilypond is very important to me. > > > FYI, what I like the most about Frescobaldi are: > > > >- > >Templates and wizards >- > >Snippets >- > >Point and Click selection >- > >Syntax highlighting > > > If Frescobaldi for Mac does indeed vanish, what are my alternatives for a > Lilypond editor? > > > Also, how can I help? (I'm not a programmer at all...) > > > Peace! and thank you for all your work! > > > Dirck >
Fw: Frescobaldi ... panic alternatives?
Hi all Reading that last thread about Frescobaldi and its possible disappearance from Mac is causing me to panic. Jean, I did not realize that you were the last person to seriously work on Frescobaldi / Mac. I use Mac exclusively, and Frescobaldi / Lilypond is very important to me. FYI, what I like the most about Frescobaldi are: * Templates and wizards * Snippets * Point and Click selection * Syntax highlighting If Frescobaldi for Mac does indeed vanish, what are my alternatives for a Lilypond editor? Also, how can I help? (I'm not a programmer at all...) Peace! and thank you for all your work! Dirck
Re: Transparent box around notes
> [...] the snippet is _very_ useful, and certainly much easier to use > than the lsr snippet. Please submit the example as a new LSR snippet. Note that we already have a (slightly different) issue for that: https://gitlab.com/lilypond/lilypond/-/issues/833 It would certainly help if you could add more information to the issue, for example, where to find the latest working example. > I strongly encourage the community to add it to the repository, > because the trial and error method is inaccurate and time consuming. Are you willing to work on that? It would need extensive tests (for example, to add other grobs like trill spanners to the box), documentation, and one or more regression tests. Werner
Re: Transparent box around notes
Yeah, it works if I just replace add-grob-definition with:
#(define (add-grob-definition grob-name grob-entry)
(set! all-grob-descriptions
(cons ((@@ (lily) completize-grob-entry)
(cons grob-name grob-entry))
all-grob-descriptions)))
That said, the snippet is _very_ useful, and certainly much easier to use
than the lsr snippet. I strongly encourage the community to add it to the
repository, because the trial and error method is inaccurate and time
consuming.
That said, is there an easy way to adapt it so that it draws a colored box
(with transparency) instead of a rectangle with segments?
Thanks again,
P
(I attach here the updated version of the snippet)
On Sun, Apr 28, 2024 at 11:38 AM Robin Bannister wrote:
> Paolo Prete wrote:
> > Note that there's also this (no trial-and-error):
> >
> > https://lists.gnu.org/archive/html/lilypond-user/2015-01/msg00142.html
> >
> > But it doesn't compile with 2.24...
> >
>
> That's due to merge request !818 [1], applied between 2.23.3 and 2.23.4.
>
> Simon Albrecht ran into the same problem in another case, and Jean
> helped him out [2] by adapting just the add-grob-definition part.
>
> Doing the same to David N's add-grob-definition gets his code running
> again. Maybe that's all you need to do.
>
>
> [1] https://gitlab.com/lilypond/lilypond/-/merge_requests/818
> [2] https://lists.gnu.org/archive/html/lilypond-user/2021-12/msg00045.html
>
>
> Cheers,
> Robin
>
\version "2.19.15"
\header {
tagline = ##f
}
#(define-event-class 'music-boxer-event 'span-event)
#(define-event-class 'box-event 'music-event)
% #(define (add-grob-definition grob-name grob-entry)
%(let* ((meta-entry (assoc-get 'meta grob-entry))
% (class(assoc-get 'class meta-entry))
% (ifaces-entry (assoc-get 'interfaces meta-entry)))
% ;; change ly:grob-properties? to list? to work from 2.19.12 back to at least 2.18.2
% (set-object-property! grob-name 'translation-type? ly:grob-properties?)
% (set-object-property! grob-name 'is-grob? #t)
% (set! ifaces-entry (append (case class
% ((Item) '(item-interface))
% ((Spanner) '(spanner-interface))
% ((Paper_column) '((item-interface
% paper-column-interface)))
% ((System) '((system-interface
%spanner-interface)))
% (else '(unknown-interface)))
% ifaces-entry))
% (set! ifaces-entry (uniq-list (sort ifaces-entry symbol1
\musicBoxerStart d8-4 g,-0 d' g, d'-4 g,-0 d' \musicBoxerEnd g,
}
%2
\repeat volta 2 {
\box 1\f\fermata
\musicBoxerStart g8-3 d-0 g d g8-4 d-0 g \musicBoxerEnd d\accent
}
}
\score {
\new Staff \melody
}
\layout {
\context {
\Global
\grobdescriptions #all-grob-descriptions
}
\context {
\Score
\consists \musicBoxerEngraver % for spans
\consists \boxEngraver
}
}
Re: Conditional markup? UP|DOWN
On 2024-04-29 7:50 am, Pierre-Luc Gauthier wrote:
Can a markup command introspect its direction ?
Is it possible to set in a markup command some conditionals (not paper
related) ?
\version "2.25.15"
#(define-markup-command (conditionalMrkp layout props)
()
(interpret-markup layout props #{
\markup {
%\if #DOWN
"↑"
%\if #UP
"↓"
}#}))
{b'^\markup \conditionalMrkp b'_\markup \conditionalMrkp}
\version "2.24.3"
is-directional =
#(lambda (layout props)
(number? (chain-assoc-get 'direction props #f)))
is-upward =
#(lambda (layout props)
(eq? UP (chain-assoc-get 'direction props #f)))
is-downward =
#(lambda (layout props)
(eq? DOWN (chain-assoc-get 'direction props #f)))
asdf = \markup \circle \overlay {
\if \is-upward ↑ \if \is-downward ↓
\unless \is-directional \pad-around #0.25 *
}
\layout { indent = 0 }
\asdf
{ b'4-\asdf 4_\asdf 2^\asdf }
-- Aaron Hill
Re: Is there a more complete predefined-guitar-fretboards.ly?
On Mon, 29 Apr 2024, Kevin Cole wrote: > "predefined-guitar-ninth-fretboards.ly" get the job done. But on a few > occasions I've had to resort to studying some online tutorial and > constructing the diagrams from scratch. Not a complete solution, but my chord database at https://files.northcoastsynthesis.com/chords/C already exposes the Lilypond code for each fretboard diagram in an HTML comment. In Firefox, if you right-click and choose "inspect" on a diagram, then "Edit as HTML" on the enclosing "fretboard-item" div, you can find the \fret-diagram command and copy out the code for use in your own Lilypond document. Most other browsers should be able to do something similar. If this is a feature people want and will use, then I can try to add something to make the source code more visible, most likely a "lilypond" button to make it visible and copyable without using the browser's source-viewing tools. Automatically generating a file of preferred fretboard diagrams for many chords wouldn't be easy because I don't have a strong sense of which ones are easiest or preferable to play; I'm not really a guitarist myself. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before tribes. https://ansuz.sooke.bc.ca/
Is there a more complete predefined-guitar-fretboards.ly?
Hi. I'm currently using 2.24.2. I'm not a guitarist, and most of the people I play with are by their own admission rather amateur. For most tunes that I transcribe the built-in "predefined-guitar-fretboards.ly" and, on one occasion, "predefined-guitar-ninth-fretboards.ly" get the job done. But on a few occasions I've had to resort to studying some online tutorial and constructing the diagrams from scratch. Being lazy, I'm wondering if there is a particularly popular reinvention of this wheel that doesn't come with the stock packaging -- or a set of such files all bundled together. (Yes, I know: Lots of fingerings / voicings, but the fact that there's already a predefined-guitar-fretboards.ly" suggests that there are some common favorites, and as I mentioned most of my friends are "amateur" and generally inclined to use easier fingerings and rely on whatever the diagrams tell them.) Thanks!
Conditional markup? UP|DOWN
Can a markup command introspect its direction ?
Is it possible to set in a markup command some conditionals (not paper
related) ?
\version "2.25.15"
#(define-markup-command (conditionalMrkp layout props)
()
(interpret-markup layout props #{
\markup {
%\if #DOWN
"↑"
%\if #UP
"↓"
}#}))
{b'^\markup \conditionalMrkp b'_\markup \conditionalMrkp}
--
*Pierre-Luc Gauthier*
Re: How to manually set MIDI channel # for a staff?
Jean Abou Samra writes:
> Le lundi 29 avril 2024 à 06:31 -0500, Jason Yip a écrit :
>> Hi,
>>
>> Does anyone know how to manually set the midi channel # for a staff to
>> something other than the default of channel 0/1? Without having to
>> create dummy staffs with just `s256` as the voice content preceding the
>> desired staff? The staff in question usually only has one voice, so I
>> modified the midi context as shown below simply made a bunch of dummy
>> voices with only `s256` as the content so that they don't at least
>> affect the graphical output:
>>
>> ```
>> \midi {
>> \context {
>> \Staff
>> \remove "Staff_performer"
>> }
>> \context {
>> \Voice
>> \consists "Staff_performer"
>> }
>> }
>> ```
>
>
> You can do \set Score.midiChannelMapping = #'voice as an alternative to that.
We really need a plain simple way to set a fixed channel. There is
enough hardware around using dedicated channels.
--
David Kastrup
Re: Frescobaldi?
Hi Kieren, On Mon, Apr 29, 2024 at 3:12 PM Kieren MacMillan < kie...@kierenmacmillan.info> wrote: > > 1. Any thoughts about what the optimal package is? > I use TexStudio for all my TeX work, and it's excellent. Here: https://texstudio.sourceforge.net (shoutout to extremely old-skool sourceforge hosting) > > 2. Is there any benefit/interest in trying to duplicate the most > important/useful functionality of Frescobaldi (e.g. two-way point-and-click > navigation) into a LaTeX-based IDE? > TexStudio let's you right-click the pdf output and select "go to source", so presumably the functionality is there. The only issue is that the lilypond code isn't interpreted by LaTeX directly, but called through lyluatex. I worked with Urs a few years back to produce an architecture for editing multi-volume Lily file trees, with excellent output, all called through LaTeX. I'm not sure if the project is still hosted anywhere (it was residing on Urs' private github/gitlab server), but it worked well. I don't use any tools in frescobaldi besides the point-and-click functionality that wouldn't already be available in any modern TeX IDE. But it seems my issues with frescobaldi are due to some problems with my qtwebengine installation, so I might be able to get them resolved relatively easily. Updating it to use PyQt6 would be an important long-term sustainability goal, but at least it's not a complete blocker for me (for now). Cheers, A
Re: Frescobaldi?
Hi all, > Fortunately for me, I'm using lualatex already, so that worked. I do indeed > lose point-and-click, but it's good to know that if frescobaldi stops working > I at least have a backup. I’ve been considering moving fully to *lula*tex ever since Urs demonstrated his lyluatexmp (https://github.com/uliska/lyluatexmp) at the Salzburg conference. 1. Any thoughts about what the optimal package is? 2. Is there any benefit/interest in trying to duplicate the most important/useful functionality of Frescobaldi (e.g. two-way point-and-click navigation) into a LaTeX-based IDE? Cheers, Kieren. __ My work day may look different than your work day. Please do not feel obligated to read or respond to this email outside of your normal working hours.
Re: How to manually set MIDI channel # for a staff?
On 2024-04-29 06:48, Jean Abou Samra - jean(a)abou-samra.fr wrote:
You can do \set Score.midiChannelMapping = #'voice as an alternative to that.
Also \new Voice { } should work (untested) instead of \new Voice { s256 }.
I don't think there's a better way.
Setting midiChannelMapping property didn't deliver my desired results.
My way worked apparently.
Removing the s256 doesn't also deliver my desired results.
Re: How to manually set MIDI channel # for a staff?
Le lundi 29 avril 2024 à 06:31 -0500, Jason Yip a écrit :
> Hi,
>
> Does anyone know how to manually set the midi channel # for a staff to
> something other than the default of channel 0/1? Without having to
> create dummy staffs with just `s256` as the voice content preceding the
> desired staff? The staff in question usually only has one voice, so I
> modified the midi context as shown below simply made a bunch of dummy
> voices with only `s256` as the content so that they don't at least
> affect the graphical output:
>
> ```
> \midi {
> \context {
> \Staff
> \remove "Staff_performer"
> }
> \context {
> \Voice
> \consists "Staff_performer"
> }
> }
> ```
You can do \set Score.midiChannelMapping = #'voice as an alternative to that.
Also \new Voice { } should work (untested) instead of \new Voice { s256 }.
I don't think there's a better way.
signature.asc
Description: This is a digitally signed message part
How to manually set MIDI channel # for a staff?
Hi,
Does anyone know how to manually set the midi channel # for a staff to
something other than the default of channel 0/1? Without having to
create dummy staffs with just `s256` as the voice content preceding the
desired staff? The staff in question usually only has one voice, so I
modified the midi context as shown below simply made a bunch of dummy
voices with only `s256` as the content so that they don't at least
affect the graphical output:
```
\midi {
\context {
\Staff
\remove "Staff_performer"
}
\context {
\Voice
\consists "Staff_performer"
}
}
```
It's definitely a hacky solution, especially given that my program that
automatically generates lilypond code has to output `\new Voice { s256
}\n` n - 1 times before the actual content then wrap the voices with <<
>>. If this is the only way to do it, is there some sort of way to
substitute `s256` with something else that doesn't occupy length but at
least lets the performer still assign a channel to the dummy staff/voices?
Thanks!
Re: Frescobaldi?
Hi Jean,
On Mon, Apr 29, 2024 at 1:17 PM Jean Abou Samra wrote:
>
> lilypond-book isn't called by LaTeX, it's a preprocessor that you first
> have
> to run on a .lytex file to get a .tex file, then you compile that .tex file
> with TeX.
>
> Consider lyLuaTeX, which is an alternative that runs inside the TeX process
> directly, but requires LuaTeX. You can specify the path to the LilyPond
> executable with \usepackage[program=/path/to/bin/lilypond]{lyluatex}.
> See https://ctan.org/pkg/lyluatex
>
>
> Fortunately for me, I'm using lualatex already, so that worked. I do
indeed lose point-and-click, but it's good to know that if frescobaldi
stops working I at least have a backup. Thanks for the help!
N. Andrew Walsh
er/ihn/ihm/sein | he/him/his
Berlin
Re: Frescobaldi?
> yeah, I just had the package-manager in gentoo downgrade to the previous
> version of snappy, and then filed a bug with gentoo. It's a workaround for
> now.
>
> As another workaround, I'm trying to get my latex editor to use lilypond-book,
> but since it's on a nonstandard path, I don't seem able to use it. How do you
> integrate lilypond-book into a LaTeX toolchain?
lilypond-book isn't called by LaTeX, it's a preprocessor that you first have
to run on a .lytex file to get a .tex file, then you compile that .tex file
with TeX.
Consider lyLuaTeX, which is an alternative that runs inside the TeX process
directly, but requires LuaTeX. You can specify the path to the LilyPond
executable with \usepackage[program=/path/to/bin/lilypond]{lyluatex}.
See https://ctan.org/pkg/lyluatex
With both methods, you will lose point-and-click, though.
signature.asc
Description: This is a digitally signed message part
Re: Frescobaldi?
Hi Jean, yeah, I just had the package-manager in gentoo downgrade to the previous version of snappy, and then filed a bug with gentoo. It's a workaround for now. As another workaround, I'm trying to get my latex editor to use lilypond-book, but since it's on a nonstandard path, I don't seem able to use it. How do you integrate lilypond-book into a LaTeX toolchain? Cheers, N. Andrew Walsh er/ihn/ihm/sein | he/him/his Berlin On Mon, Apr 29, 2024 at 12:35 PM Jean Abou Samra wrote: > > > It gets a bit more complicated now. See this bug: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278633 > > > > That bug is for freeBSD, but I expect it applies to other > > distros as well (it certainly applies to gentoo, as I'm > > getting the exact same error). In short, snappy (an archiver) > > was updated to version 1.2.0 a few days ago, and it contains > > symbols that aren't defined in earlier versions. > > > Well, new symbols shouldn't be a problem (removed symbols would be, > if other packages expect them). Based on > https://github.com/conda-forge/snappy-feedstock/issues/35 > what apparently happened is that the snappy developers released > 1.2.0 but forgot to update the library soname even though they > changed function signatures. The lookup of that symbol > > _ZN6snappy11RawCompressEPKcmPcPm > > which is the mangled version of > > snappy::RawCompress(char const*, unsigned long, char*, unsigned long*) > > fails because the new version only has a (mangled) symbol for > > snappy::RawCompress(char const*, unsigned long, char*, unsigned long*, > snappy::CompressionOptions) > > That's a bug in snappy, and it will affect things other than qtwebengine > too… > You should probably ask the Gentoo developers to revert to the previous > version > or patch it. There's probably a way to ask the Gentoo package manager > to downgrade the package, too. > >
Re: Frescobaldi?
> It gets a bit more complicated now. See this bug: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278633 > > That bug is for freeBSD, but I expect it applies to other > distros as well (it certainly applies to gentoo, as I'm > getting the exact same error). In short, snappy (an archiver) > was updated to version 1.2.0 a few days ago, and it contains > symbols that aren't defined in earlier versions. Well, new symbols shouldn't be a problem (removed symbols would be, if other packages expect them). Based on https://github.com/conda-forge/snappy-feedstock/issues/35 what apparently happened is that the snappy developers released 1.2.0 but forgot to update the library soname even though they changed function signatures. The lookup of that symbol _ZN6snappy11RawCompressEPKcmPcPm which is the mangled version of snappy::RawCompress(char const*, unsigned long, char*, unsigned long*) fails because the new version only has a (mangled) symbol for snappy::RawCompress(char const*, unsigned long, char*, unsigned long*, snappy::CompressionOptions) That's a bug in snappy, and it will affect things other than qtwebengine too… You should probably ask the Gentoo developers to revert to the previous version or patch it. There's probably a way to ask the Gentoo package manager to downgrade the package, too. signature.asc Description: This is a digitally signed message part
Re: Frescobaldi?
OK, so maybe I should just move lilypond work into my LaTeX IDE for the time being. Since my lilypond installation isn't on the system PATH, how do I include it as part of a .tex document to get access to the lilypond-book commands? Cheers, N. Andrew Walsh er/ihn/ihm/sein | he/him/his Berlin On Mon, Apr 29, 2024 at 12:16 PM Mats-Olof Liljegren wrote: > I use it on Sonoma without issues. > > Med vänlig hälsning / Kind regards > *Mats-Olof Liljegren* > > *e-pro* > Oskarsvägen 11B > 702 14 Örebro > Tel 070 360 19 19 > e-post m...@e-pro.se > web: http://e-pro.se > > 29 apr. 2024 kl. 11:40 skrev Robert Garrigos : > > I cannot use Frescobaldi on Mac Sonoma (not working), so I went for Visual > Studio Code, with some lilypond plugins, and I have to say that it offers > everything I need > > Robert > > El 28 abr. 2024, a les 13:57, Jean Abou Samra va > escriure: > > Is Frescobaldi the most common tool on Linux, or what do the majority of > Lilypond users use? > > > Frescobaldi is the most common LilyPond editor, on all OSes. > > > > >
Re: Frescobaldi?
> Would it maybe make things a bit easier to leave the whole MacOS > business aside and take care of the Linux-specific stuff first? Linux is not really causing us any specific problems. Packaging is a lot easier, thanks to Linux distributions and Flatpak. The only wrinkle is the oddities on Wayland that are related to Qt 5. > And what actually about Windows - out of curiosity. Windows is… a can of worms of its own. The Windows installers for the past few releases were built by a user (@19joho66 on GitHub) who apparently manages to them work by moving shared libraries around manually :-( > I myself am a Linux user (Mint), and so far Frescobaldi is still running > flawlessly. > And - another question out of curiosity: Could it be a workaround (if > Qt5 would be officially retired and no longer be available in the repos > of the "big" distros like Mint, Ubuntu and the like) if one used a > distro for older computers which might stick to Qt5 much longer? I may be wrong, but I don't really foresee distros retiring Qt 5 soon since Frescobaldi should not be the only piece of software still requiring it (as Qt is so widely used). In any case, the Flatpak package can still ship it. What's more likely to happen is that changes in the desktop environments (like Xorg → Wayland) make Qt 5 work less and less well. signature.asc Description: This is a digitally signed message part
Re: Frescobaldi?
I use it on Sonoma without issues. Med vänlig hälsning / Kind regards Mats-Olof Liljegren e-pro Oskarsvägen 11B 702 14 Örebro Tel 070 360 19 19 e-post m...@e-pro.se web: http://e-pro.se > 29 apr. 2024 kl. 11:40 skrev Robert Garrigos : > > I cannot use Frescobaldi on Mac Sonoma (not working), so I went for Visual > Studio Code, with some lilypond plugins, and I have to say that it offers > everything I need > > Robert > >> El 28 abr. 2024, a les 13:57, Jean Abou Samra va >> escriure: >> >>> Is Frescobaldi the most common tool on Linux, or what do the majority of >>> Lilypond users use? >> >> Frescobaldi is the most common LilyPond editor, on all OSes. >> >> >
Re: Frescobaldi?
I cannot use Frescobaldi on Mac Sonoma (not working), so I went for Visual Studio Code, with some lilypond plugins, and I have to say that it offers everything I need Robert > El 28 abr. 2024, a les 13:57, Jean Abou Samra va > escriure: > >> Is Frescobaldi the most common tool on Linux, or what do the majority of >> Lilypond users use? > > Frescobaldi is the most common LilyPond editor, on all OSes. > >
Re: Frescobaldi?
It gets a bit more complicated now. See this bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278633 That bug is for freeBSD, but I expect it applies to other distros as well (it certainly applies to gentoo, as I'm getting the exact same error). In short, snappy (an archiver) was updated to version 1.2.0 a few days ago, and it contains symbols that aren't defined in earlier versions. So qtwebengine-5* will fail on systems with older versions of qtwebengine but newer versions of snappy. My error message is this: -- $ frescobaldi Traceback (most recent call last): File "/usr/lib/python-exec/python3.11/frescobaldi", line 42, in import main File "/usr/lib/python3.11/site-packages/frescobaldi_app/main.py", line 34, in import app # Instantiate global signals etc ^^ File "/usr/lib/python3.11/site-packages/frescobaldi_app/app.py", line 38, in import PyQt5.QtWebEngineWidgets ImportError: /usr/lib64/libQt5WebEngineCore.so.5: undefined symbol: _ZN6snappy11RawCompressEPKcmPcPm So now frescobaldi won't run on my system at all. I sure hope we can fix this soon. I've talked to a colleague of mine who does python and UI development, and they're going to have a look at the code and see what needs updating to work with Qt6. Cheers, N. Andrew Walsh er/ihn/ihm/sein | he/him/his Berlin On Mon, Apr 29, 2024 at 10:49 AM Hajo Baess wrote: > Would it maybe make things a bit easier to leave the whole MacOS > business aside and take care of the Linux-specific stuff first? And > what actually about Windows - out of curiosity. I myself am a Linux > user (Mint), and so far Frescobaldi is still running flawlessly. > > And - another question out of curiosity: Could it be a workaround (if > Qt5 would be officially retired and no longer be available in the repos > of the "big" distros like Mint, Ubuntu and the like) if one used a > distro for older computers which might stick to Qt5 much longer? > > At any rate the present state of affairs is really sad, since > Frescobaldi just is a masterpiece of software for its purpose. I have > looked at a couple of alternatives, but I was less convinced of them. > > Maybe in case Frescobaldi one day will not run any more, I need to > return to a combination of a good text editor and a PDF viewer like I > had many years ago when I was still a Mac user. I had TeXShop and Skim, > and that worked well enough. And then I also sometimes used > LilyPondTool which in the meantime is defunct as well, but was a > similar approach to editing LilyPond files as Frescobaldi. > > This is the moment when I wish I'd be a programmer, but I am afraid the > learning curve for helping out with Frescobaldi would be way to steep > for me... > > Am Sonntag, dem 28.04.2024 um 22:14 +0200 schrieb Jean Abou Samra: > > > […] > > > Well, the explanation wasn't that brief. Sorry that I didn't have > > > time to write a shorter one, as they say. > > > > > > PS: Maybe I should mention that at the time I went down the rabbit > > hole of Python packaging in general because of Frescobaldi, I wrote > > two articles on the LinuxFR site, which may be of interest here if > > one reads French: > > > > > https://linuxfr.org/news/l-installation-et-la-distribution-de-paquets-python-1-4 > > > https://linuxfr.org/news/l-installation-et-la-distribution-de-paquets-python-2-4 > > > > (Yes, these are ~8 and ~14 pages long. Yes, they're only the two > > first articles in a series of four. I haven't given up on publishing > > the two others, but it's not my priority at the moment.) > > > >
Re: Frescobaldi?
Would it maybe make things a bit easier to leave the whole MacOS business aside and take care of the Linux-specific stuff first? And what actually about Windows - out of curiosity. I myself am a Linux user (Mint), and so far Frescobaldi is still running flawlessly. And - another question out of curiosity: Could it be a workaround (if Qt5 would be officially retired and no longer be available in the repos of the "big" distros like Mint, Ubuntu and the like) if one used a distro for older computers which might stick to Qt5 much longer? At any rate the present state of affairs is really sad, since Frescobaldi just is a masterpiece of software for its purpose. I have looked at a couple of alternatives, but I was less convinced of them. Maybe in case Frescobaldi one day will not run any more, I need to return to a combination of a good text editor and a PDF viewer like I had many years ago when I was still a Mac user. I had TeXShop and Skim, and that worked well enough. And then I also sometimes used LilyPondTool which in the meantime is defunct as well, but was a similar approach to editing LilyPond files as Frescobaldi. This is the moment when I wish I'd be a programmer, but I am afraid the learning curve for helping out with Frescobaldi would be way to steep for me... Am Sonntag, dem 28.04.2024 um 22:14 +0200 schrieb Jean Abou Samra: > > […] > > Well, the explanation wasn't that brief. Sorry that I didn't have > > time to write a shorter one, as they say. > > > PS: Maybe I should mention that at the time I went down the rabbit > hole of Python packaging in general because of Frescobaldi, I wrote > two articles on the LinuxFR site, which may be of interest here if > one reads French: > > https://linuxfr.org/news/l-installation-et-la-distribution-de-paquets-python-1-4 > https://linuxfr.org/news/l-installation-et-la-distribution-de-paquets-python-2-4 > > (Yes, these are ~8 and ~14 pages long. Yes, they're only the two > first articles in a series of four. I haven't given up on publishing > the two others, but it's not my priority at the moment.) >
