Lilycollider or superfomus?

[john-d-murphy]

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/libfomus.so: 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.

[VIRTUALDOG]

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

[john-d-murphy]

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!

[john-d-murphy]

If you have time, can you do a quick obj dump on the libfomus.so 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/libfomus.so | grep fom_get_sval_up
0000000000000000      D  *UND*  0000000000000000              _ZN5fomus15fom_get_sval_upB5cxx11Ei

[VIRTUALDOG]

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?

[john-d-murphy]

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

Compiler:

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
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

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.

[VIRTUALDOG]

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

[VIRTUALDOG]

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

diff --git a/src/lib/api.cc b/src/lib/api.ccindex 62ec8d2..1a0edb8 100644---...

[john-d-murphy]

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

[john-d-murphy]

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: https://github.com/john-d-murphy/fomus

thank you very much for your help!

[VIRTUALDOG]

no problem, i enjoy debugging builds.

how did i track down this particular issue:

1. grepped for the missing symbol in the codebase
2. 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)..)
3. try moving the definitions around, which led to the realization that there are some gnarly header dependencies
4. 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)?

[john-d-murphy]

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.

[VIRTUALDOG]

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.

[john-d-murphy]

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!

EDIT: Proof of life:

Thank you again @VIRTUALDOG - you’ve helped me considerably.

[VIRTUALDOG]

glad to help! :)))))

[madskjeldgaard]

Update: This package seems the one to use nowadays

GitHub - n-armstrong/fosc: A SuperCollider API for generating musical...

[smoge]

@scztt

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.

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.

Anyway, maybe those bugs can be fixed.

[smoge]

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.

https://abjad.github.io/

[smoge]

A while ago, after a boost update, I used this patch to fix it. It worked.

On MacOS, you can just open the App package, copy the files to your local folders (local bin and lib), and chmod +x them. Dirty but works just fine.

diff fomus-0.1.18-alpha/src/lib/mods.h fomus-0.1.18-alpha.patched/src/lib/mods.h
--- fomus-0.1.18-alpha/src/lib/mods.h	
+++ fomus-0.1.18-alpha.patched/src/lib/mods.h	
@@ -214,7 +214,7 @@
   class dlmodt2:public dlmodt1<T> {
   public:
     dlmodt2(const T& st):dlmodt1<T>(st) {}
-    void* getdata(FOMUS f) const {return initerrwrap(T::newdata(f));}
+    void* getdata(FOMUS f) const {return this->initerrwrap(T::newdata(f));}
     void freedata(void* data) const {T::freedata(data); T::initerrcheck();}	 
   };
   typedef dlmodt1<dlmodstuffinit> dlmodinit; // auxiliary modules
diff -aur fomus-0.1.18-alpha/src/lib/vars.cc fomus-0.1.18-alpha.patched/src/lib/vars.cc
--- fomus-0.1.18-alpha/src/lib/vars.cc	
+++ fomus-0.1.18-alpha.patched/src/lib/vars.cc	
@@ -450,11 +450,11 @@
     const boostspirit::symbols<numb>& ip(fd ? fd->getmicpa() : mic_parse);
     const boostspirit::symbols<numb>& op(fd ? fd->getoctpa() : oct_parse);
     if (lst.type != module_list) return false;
-    for (const module_value* i = lst.val.l.vals, *ie = lst.val.l.vals + lst.val.l.n; i < ie; ++i) {
-      if (i->type != module_string) return false;
+    for (const module_value* j = lst.val.l.vals, *ie = lst.val.l.vals + lst.val.l.n; j < ie; ++j) {
+      if (j->type != module_string) return false;
       numb nov(module_none), acv(module_none), miv(module_none), ocv(module_none);
       parserule rl(notematchhasoct(mp, ap, ip, op, nov, acv, miv, ocv));
-      parse_it p(i->val.s, endof(i->val.s));
+      parse_it p(j->val.s, endof(j->val.s));
       parse(p, parse_it(), rl);
       rat m(nov.isnull() ? std::numeric_limits<fint>::min() + 1 : numtorat(nov));
       rat a(acv.isnull() ? std::numeric_limits<fint>::min() + 1 : numtorat(acv));

[lannes]

Hi all,

Has anyone attempted to get fosc running on Windows? Currently I’m getting the following error when trying to show a note (as found in the readme on fosc’s github page): ERROR: Message 'at' not understood.RECEIVER: nilARGS: Integer 0PAT - Pastebin.com

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.