Fedora Special Interest Groups (SIGs) Audio Creation / Music

Hoping to revive the Fedora Audio Creation SIG. (or at least to update/delete a few Wiki pages)

The prominent figure in "Fedora Audio" is Brendan Jones

There is the outdated "Fedora Jam":  https://fedoraproject.org/wiki/Fedora_jam
Mostly active in 2012~2014, but there are update in 2017 too!

Fedora Special Interest Groups (SIGs) Audio Creation https://fedoraproject.org/wiki/Audio_Creation . Many (all?) Wiki pages are obsolete (relates to Fedora 14) and contains dead links.


MuseScore really shows that Fedora could do better, there many broken links and for example:  Distribution maintainers Fedora's link is broken and the 2 persons listed show no activities for the last 6 years.
Looks like the current packager is Orcan Ogetbil, according to the changelog. I hope to progress on this topic.


DrumGizmo RPM

Install packages
sudo dnf install fedora-packager

and add yourself to group mock, logout, login.  (See references at the end.)

rpmdev-setuptree will create the ~/rpmbuild structure (from any location, it is a super old shell script!)

Either specify an URL in the source or specify just a file.
IF you just specify a file:
- Download the sources   spectool -R -g ../SPECS/drumgizmo.spec   will download in  SOURCES/ ...

Before DrumGizmo, we have to build LibSmf-Devel because this dependency is not in standard repos.
Note: Using  make --disable-cli ... in DrumGizmo spec file allow to bypass libsmf issue ...   But the Drumgizmo command line tool can be useful.

 is  a serious problem. Should really be included in Fedora!

LibSmf is really a simple library with very few dependencies and the spec file is already OK. We can create the RPM and then Mock allows to  Build packages that depend on packages not in a repository.

1/ Build All LibSmf:  rpmbuild -ba SPECS/libsmf.spec

2/ Prepare your DrumGizmo source RPM: rpmbuild -bs SPECS/drumgizmo.spec

3/ Install the RPMs in mock and build (note: libsmf-devel requires libsmf):
mock --init
mock --install RPMS/x86_64/libsmf{-devel,}-1.3.692e728-3.fc28.x86_64.rpm
mock --no-clean --rebuild SRPMS/drumgizmo-0.9.15-1.fc28.src.rpm 

You get the idea, by default mock would clean the environment. So here we init, install out RPM and build the new one while keeping our installed RPM. 
The idea is to:

  1. modify the drumgizmo  spec
  2. rebuild the source RPM
  3. test with mock if the rpm build

You can rebuild multiple times with --no-clean, but in the end, be sure to test from init.

Once everything build OK.  Try on your own PC...
  sudo dnf install ./RPMS/x86_64/libsmf-1.3...rpm  and libsmf-devel
  rpmbuild -ba SPECS/drumgizmo.spec

I had a QA "minor issue" with hard coded rpath '/usr/lib64'. I did not find other solution than to ignore it:
  QA_RPATHS=0x0001 rpmbuild -ba SPECS/drumgizmo.spec

sudo dnf install ./RPMS/x86_64/drumgizmo...rpm


Note: the plugin is installed for everyone, in /usr/lib64/lv2.  If you follow the Drumgizmo guide, it will be installed only in your own ~/.lv2/ directory.

Beware that maybe the DrumGizmo plugin and its host (Ardour typically) require the same lib versions. At least, I read that it could be an issue sometimes.



Online Scientific Notebooks, Course, Visualization show and tell comics

Course, Visualization, Notebooks

We could add Mathematica, WolframAlpha, but they are not so free.

Also Geogebra (https://www.geogebra.org/) is almost there, if only its interface was not so complicated. It is a shame that this tool has not more success!


In 2018, there will be innovations, but no jobs

There will be innovations, but no jobs:

The current response is "losers go to hell":
It might not be sustainable, since losers can still vote ...

Will 2018 bring an answer? (other than Trump/Poutine duo)

That is my happy prediction :-)

Music in 2017

Not a lot, I guess I did not take note of all I liked this year, but anyway here it is:

I think I will spend less time listening to educational music video and more time practicing with Android Apps like "ear trainer".


Encoding/Decoding in Java 9 using javax.xml.bind or not

DatatypeConverter and Java 9

If you used to do conversions, like

import javax.xml.bind.DatatypeConverter;

byte[] bin = DatatypeConverter.parseHexBinary("0769cc");

With Java 9 you will get errors, since javax.xml.bind is no longer in the module path, it is considered part of Java Enterprise. With Java 10 it may even be removed from the JRE.

It is a known problem:

There are many solutions: Rewriting the function or Using command line option to load the library at runtime ...  But the most robust and long term one seems to be adding the dependency to your project.

Here I will focus on adding the dependency:

Java Enterprise library 

As a Maven dependency:

Directly in IntelliJ (Community edition):


Guava also provides conversion methods, but you will have to adapt your code:

Apache Common

Same for Apache Commons. It is a matter of taste.


Fedora Special Interest Groups (SIGs) Audio Creation / Music

Hoping to revive the Fedora Audio Creation SIG. (or at least to update/delete a few Wiki pages) The prominent figure in "Fedora Audi...