Lilycollider or superfomus?

anyone still using these?

advice on getting one or both to work with 3.10?

thanks in advance

I have just started using superfomus recently (with 3.10/3.11).

I’m on macOS and the issues I encountered were mostly with handling of paths (and installing fomus itself). Here’s some notes:

  • you need to install fomus - the installer fails but I was able to install by hand, I believe

  • you need to make sure that fomus executable is in the PATH

"which fomus".unixCmd if this returns non-0, that means that SC can’t find fomus. Add its path (where you installed it) to the PATH env variable, in my case: "PATH".setenv("PATH".getenv ++ ":/usr/local/bin") and re-run "which fomus".unixCmd, which should now return a path to the fomus executable

  • I believe that the files you are working on can’t have spaces in the whole path, so no spaces in folder names either (I worked around that by adding quotes in the class file, but I haven’t made a pull request to the quark repo yet)
  • finally, superfomus still doesn’t seem to handle some events well and if it fails it’s not clear what’s wrong

I hope this helps!

I recently went through a research spike on SuperCollider + FOMUS/Lily for a project. Let me see what I can remember…

  • I ended up settling on this Lilypond quark: for score generation. I was using this because there were a few notational things that SuperFOMUS wasn’t doing very well, and this one seemed more powerful. I don’t know notation really at all, so take that with a grain of salt :slight_smile:
  • I ran into pretty serious bugs between SuperFomus and the FOMUS implenentations I was using - scores with certain kinds of elements in them caused FOMUS to crash. This also pushed me in the direction of the above quark.
  • IIRC Fomus isn’t very stable with respect to it’s syntax, and I recall finding some things where SuperFOMUS output syntax that my build of FOMUS didn’t understand.
  • I don’t remember significant problems with running them in current version of SC. I have a few local changes to the lilypond library, but these were bug fixes / score generation issues - I’m happy to share them if you run into trouble.
  • I produced some example scores via:
    [a] an ingested MIDI score,
    [b] modified by some Pattern stuff,
    [c] output using either SuperFOMUS or the LIlypond quark.
    These were a little dumbed down, e.g. no tempo changes, everything rounded to a 1/4 note, etc. I showed them to a person that was working with us on the scoring part of this project (see above, I don’t know music theory / notation well at all…), and he said they were barely comprehensible and definitely wouldn’t work for the production setup (really professional ensemble, only 1-2 rehearsals kinda thing) :). So, I guess be aware that if you’re working with complex material, you might end up doing a LOT of hand tweaking of the output.

I have to agree that FOMUS breaks easily and I haven’t investigated further number of issues I have encountered (handling rests etc).
Fomus was my choice since I needed musicXML output and AFAIK LilyPond does not provide that…

And yes, absolutely, any score generation still needs manual cleanup, I don’t think there’s really a way around it (especially for semi-complex and certainly for all complex notation tasks).


Thank You both. Will write with any problems. Doing something quite simple actually.

Apologies for bumping - has anyone had any luck building fomus recently ? I actually found a bug in boost while attempting to build it this weekend, and the way my system is set up, building older versions of boost that are ostensibly compatible with fomus is a non-starter.

Hoping against hope, but it’d be really nice, as superfomus fits much more nicely into my workflow than n-armstrong’s library.

i just tried building it locally with Boost 1.72 on Arch Linux, with lilypond and puredata extensions enabled. some nasty errors but this is the patch i ended up with:

Amazing work - I got part of the way there (replacing some of the headers that you did). But figured I was sunk when I found a bug in boost.rational (bad enough that the #boost irc channel told me to submit an issue tracker!). I’ll apply this patch and come back to this thread if I have any issues.

was the boost.rational bug the way it somehow causes iomanip operators to instantiate a bad form of numeric_limits? i didn’t look into that too much but it seemed really bizarre. i fixed that by simply calling the equivalent function on the iostream rather than using << std::fixed, for example. also, this was with gcc 10 where i believe the default setting is std=c++14.

@VIRTUALDOG - yes I believe that’s where it was getting hung up - there were some easier issues to sort out (i.e. the changing of the location of library), but that one got me. I still haven’t had a chance to apply your patch as I had a major release at work this week, but I’ll give it a crack today.

Thanks for taking a look at it.

Looks like this gets me basically all the way there, with two issues - one with an issue with ncurses/curses not being found (def an issue with my system and the paths in the makefile) and another one that seems more serious:

/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: ../../src/lib/.libs/ undefined reference to `fomus::fom_get_sval_up[abi:cxx11](int)'

This is defined in schedr.h / instrs.h so there’s something wonky going on with the includes.

Did you run into this at all in your travels ? If not, no worries, I likely can figure it out, just don’t want to duplicate work in case you already wrestled with this.

hey! sorry, i didn’t ever see that issue while i was compiling. did you figure it out yet?

Still working through it. It looks like it an issue with linkage, rather than an issue with the code. I’ve got some learning about C++ to do, apparently! :slight_smile:

If you have time, can you do a quick obj dump on the file ? The main problem I see is that the method is undefined, so something is getting wonky with the linking and I don’t know if it’s the ./configure configuration or what - knowing if you have the same representation of the object as me would be super useful.

$ objdump -T ./src/lib/.libs/ | grep fom_get_sval_up
0000000000000000      D  *UND*  0000000000000000              _ZN5fomus15fom_get_sval_upB5cxx11Ei

i would try building again from a clean start; i just took a look and i don’t see any reason for this, so it is probably because you’ve been trying to build multiple times while changing the source tree. have you made any modifications besides the patch i posted?

what’s your compiler?

This is the sequence of events:

  1. tar xzvf fomus-0.1.18-alpha.tar.gz
  2. patch -p1 < Fomus\ 0.1.18-alpha+Boost\ 1.72\ build\ patches.txt
  3. ./configure --prefix=/home/murphy --with-ncurses
  4. make -j20


murphy@emergentprocess ~/Downloads/fomus-0.1.18-alpha
$ g++ --version
g++ (Gentoo 10.2.0 p1) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO

I’ve also noticed that I’ve needed to make a change to the makefile in the ‘exe’ directory to link to “-ltinfo” since that doesn’t seem to be in any of the linked libraries.

perhaps I’m apply the patch wrong or should be using a different set of libraries or a different configure incantation ?

EDIT: fwiw, this project uses a lot of magic behind the scenes to generate the makefiles and that may be causing some of the issues. I’m going to look to see if there’s a gentoo overlay from a while back that built this, bc there’s likely something that needs to change.

EDIT2: I’ll try to build this on an Arch Box and see if I have better luck.

ah i get this error now. i was compiling in debug prior. let me see if i can find the issue.

ok, it wasn’t so bad, just the same function declared inline in one spot and non-inline in another :sweat_smile: . i have it compiling now in release mode with this patch:

Ah! you are much better at C++ than I am. :slight_smile: l was coming to post that I tried compiling this on my netbook and had the same issue.

Bingo - this works - offtopic, how were you able to track this down ? I should’ve been able to do this as I develop software in C++ for a living, but apparently there’s a bit of a gap with applying the tooling/knowledge I have to unfamiliar codebases.

Additionally, I’ve put the source into github after running a clang format on it and pasted it here:

thank you very much for your help!