Lilycollider or superfomus?

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)?

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.

1 Like

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! :slight_smile:

EDIT: Proof of life:

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

1 Like

glad to help! :)))))

Update: This package seems the one to use nowadays

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.

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/

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));

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.