notice that it has an inline definition in one header and a non inline declaration in another header. this potentially presents a problem because inline functions should be declared inline everywhere (https://en.cppreference.com/w/cpp/language/inline)..)
try moving the definitions around, which led to the realization that there are some gnarly header dependencies
choose the most expedient option (based on my knowledge) to de-inline these functions and place their definitions in a single translation unit with external linkage.
looking at this again now it might have worked to simply add inline to the non-inline declarations, i guess iâve never seen a function just declared inline without a definition. in any case i knew this would work from past experience and i think this library has bigger issues than the performance hit from that.
good for you to put it in github, although reformatting it seems like an unnecessary step unless you are planning to hard fork it and maintain it going forward. i donât know much about fomus, is it still under active development at all (it doesnât seem like it from this experience)?
Thanks! That makes sense - didnât know that information about inline vs. non-inline functions, and it looks like that did the trick.
The reformatting is just for me, as thatâs the formatting I use when hacking on my personal stuff. Afaik, this isnât under any development and hasnât been touched for years. I donât expect that anyone is going to be touching it or looking for me to maintain this, but I do expect it will become a hard fork that I will be working on in my own time.
EDIT: youâre absolutely right about this library being a mess, but itâs definitely got its uses. Being able to see a pattern in actual notation is a godsend and is going to help my composition immensely.
got it, i didnât realize itâs been abandoned for that long!
the libraryâs not a mess, i didnât mean to imply that. itâs just clearly got a lot of technical debt, and that makes the point of inlining or not inlining a few functions relatively unimportant.
Sorry I misread you - I donât want to put words in your mouth and feel bad about doing so. And yes, itâs been a minute since anyoneâs worked on it!
What bugs? I didnât know fomus syntax had changed at all.
I wrote SuperFomus as a quick solution for some specific cases. It works well with Events, for instance. Iâve never seen it as a universal solution, far from it.
Yes, fosc tries to port python abjad to sc. That would be a more general-purpose solution. I need to find out how much is ported and how much used another approach, I donâ t know.
Some people using abjad create the complete music score as a software package. Thatâs one way to do it. If that fits your approach, thatâs the tool. Of course, python also offers all the libraries, numpy, music21, etc. Also, works inside jupyter notebooks. But limited to lilypond, no musicxml, guido, etc.
I believe itâs related to finding the proper Lilypond executable in my Fosc.lilypondPath directory. For what itâs worth, I havenât done the graphical install of fosc. Not sure if thatâs required as well.
I did a deep dive a while back and I think itâs unfortunately related to the .systemcmd and .unixcmd invocations and how they function on windows. Couldnât find any documentation on the matter. After some edits of the source, I was able to get lilypond generation and PDF output, albeit with many console errors in SC IDE.
What I can share is that Fosc runs quite well on a Linux virtual machine so that approach may be worth investigating if youâre still interested.