stump / libsmf Goto Github PK

These were removed with the glib removal. They should be restored.

(Some discussion of this point took place in #1.)

ABI-bump-related, so this goes on branch libsmf1.

We use libsmf in Ardour. Recently got a bug report about a file from EZ Drummer that would not load correctly. After a lot of investigation and comparison of parsing routines in midicomp, I realized that the issue was EZ Drummer's use of running status, and the presence of Meta events. The meta event would reset track->last_status to 0xff, leading to much craziness as the next event (a 2 byte note off, using running status) was parsed.

This is the commit from the ardour codebase. Sorry that we don't upstream more of our patches to libsmf, but this one seemed important enough to do so;

`commit 1f86876a0d91c28e00486332ea2480d100a0b4ca (HEAD -> new-ripple-arch)
Author: Paul Davis [email protected]
Date: Tue Jun 22 14:08:58 2021 -0600

SMF meta-events do not set running status while parsing the file

diff --git a/libs/evoral/libsmf/smf_load.c b/libs/evoral/libsmf/smf_load.c
index 2528c328fa..6a6223de0c 100644
--- a/libs/evoral/libsmf/smf_load.c
+++ b/libs/evoral/libsmf/smf_load.c
@@ -625,7 +625,9 @@ parse_next_event(smf_track_t *track)

c += len;
buffer_length -= len;

• track->last_status = event->midi_buffer[0];

• if (!smf_event_is_metadata (event)) {

•   track->last_status = event->midi_buffer[0];
  

• }
  track->next_event_offset += c - start;

  smf_track_add_event_delta_pulses(track, event, etime);
  `

This way they can be freely changed to accommodate new features, without breaking ABI again.

ABI-bump-related, so this goes on branch libsmf1.

https://sourceforge.net/projects/libsmf/ says that development has moved to https://github.com/nilsgey/libsmf but that doesn't exist.

If this is now the new home of libsmf development, the SourceForge project should be updated to help people find it.

A LICENSE file is welcomed for packaging (RPM, DEB, ...)
it eases the acceptance in Official Repos.
If I am not mistaken, Github allows you to add this file just by choosing in a dropdown list :-)
Thanks

The current release, 1.3.0, embeds copies of config.guess and config.sub that are too old to identify Apple Silicon machines. Making a new release with current autotools, and whatever accumulated fixes you've already made over the years since 1.3.0, would be a good idea.

I am interested in using this library, and I first tried to import the smf.h to my program, but then it complains about functions such as smf_load() not existing:

smftest.c:(.text+0x15): undefined reference to smf_load'
`

I'm compiling with:

gcc smftest.c $(pkg-config --cflags --libs glib-2.0)

Then I read that the home page suggests to do a make install. Is this the only way to use the library? What about doing the build to some other location than:

usr/bin/mkdir: cannot create directory ‘/usr/local/lib64’: Permission denied

When I tried to run the first line in the readme instructions, I got the following error:

$ ./autogen.sh
autoreconf-2.71: export WARNINGS=
autoreconf-2.71: Entering directory '.'
autoreconf-2.71: configure.ac: not using Gettext
autoreconf-2.71: running: aclocal --force
Can't exec "aclocal": No such file or directory at /usr/share/autoconf-2.71/Autom4te/FileUtils.pm line 274.
autoreconf-2.71: error: aclocal failed with exit status: 1

I'm not very familiar with 'autogen' and 'configure', so maybe I'm doing something wrong.

BTW, I downloaded the 'libsmf1' branch, since I don't know what to use for 'glib' (or even what it is). Is this branch up-to-date?

Thanks.

Is this viable? My files are, for some reason, in FPS format, not PPQN, and I do not know how to convert them.

Since we have the opportunity to change argument and return types due to the ABI bump, look carefully through all of them and ensure they make sense for what they are.

ABI-bump-related, so this goes on branch libsmf1.

libsmf as it exists now uses glib. Some people consider this OK; some people consider this undesirable.

I'm currently in the OK camp. I am thinking of using it to simplify error handling, remove utility code, preserve the ability to redirect log output to an arbitrary function, and deal with potential libc mismatches (a mostly Windows-specific problem, but an insidious one) for the functions that currently return malloc()'d memory and expect the caller to free() it when finished with it. Though we could do that last part by just adding a function that wraps free().

Arguments against continuing to use glib are that we currently use fairly little of it, it wouldn't be too hard to reimplement the parts we use (though the log message handling would of course become incompatible with the glib logging system without extra hacks), and it's a somewhat heavy dependency to be dragging around in certain contexts.

I like glib and want to keep it and take further advantage of it in libsmf , but I could be convinced not to do this.