SCAMP 0.8.8 released!

Hi all! I’ve been hard at work at a few new features, bug fixes, etc., and just released SCAMP 0.8.8 on PyPI (source code on source hut). Here’s what’s new:

  • Added dynamics notation support, finally! It’s a simple as: inst.play_note(pitch, volume, length, "dynamic: f") or even just inst.play_note(pitch, volume, length, "f"). (Note: this doesn’t affect playback, since that would require having some sort of global dynamic level for the part, and SCAMP treats volume on a note-by-note basis. I may implement part-level dynamic curves at some point in the future, but it’d be a major project.)
  • Made it possible to record the output of the default soundfont playback to a WAV file! (@musescore1983 and @punksterbass, I think you both have asked about this?) It’s as simple as adding this line right after the initial import of scamp: playback_settings.recording_file_path = "output.wav". The truth is, it’s a bit of a hack behind-the-scenes (it runs a second, parallel, copy of fluidsynth), but it works really well as far as I can tell, and it also should be sample accurate, since it’s using the precise time-stamps from the clocks.
  • Updated the fluidsynth .dylibs that come bundled with SCAMP on Mac, so that they are the latest version. @aestephe, I’m super curious whether these work on your M1 machine using rosetta.
  • Made it possible to use .sf3 soundfont files as well as .sf2. (These are just ogg-vorbis compressed .sf2 files.) This would be great, except that they take so long to load (I guess since they’re decompressing all the samples?), that it’s pretty much unusable, at least on my machine. Might be good for final rendering, now that you can record the output.
  • Moved SCAMP settings outside of the SCAMP package and into the OS application data directory ("~/Library/Application Support/SCAMP" on mac, “~/.local/share/SCAMP” on Linux, and “C:\Users<username>\AppData\Local\SCAMP” on Windows). This has the advantage that avoids certain permissions problems that @shiihs was pointing out, and also lets the settings persist between upgrades.
  • Added playback_settings.open_json_file(), engraving_settings.open_json_file(), and quantization_settings.open_json_file(), which just opens up the settings file in a text editor, so that you don’t have to root around for it. You can specify the command-line program to use as an argument (e.g. engraving_settings.open_json_file("atom"))
  • Added engraving_settings.export_note_velocities_to_xml, an option to have SCAMP put the note velocities into exported MusicXML files. Unfortunately, this doesn’t necessarily translate the way you want it to when you open it up in another program. For instance, in MuseScore it works for piano, but not for sustained instruments like violin (for good reasons not worth going into). Because of this inconsistency, the setting is False by default.
  • Made string representations of Session, ScampInstrument, and Ensemble less horrendous and unhelpful
  • Fixed bug discovered by @mahatGma with 15/16 time signatures (Subdivision length does not neatly subdivide beat). It should work now!
  • A bunch of other behind-the-scenes refactoring and clean-up. Good stuff, but not noticeable to the end user (hopefully!).

One other thing worth mentioning: I notice abjad came out with yet another new version (3.4), and I think there may be some tweaks I need to do to make SCAMP compatible with it. For now, version 3.3 is the version you want to install for compatibility with SCAMP.

Whew! Anyway, let me know if you have any issues with the new version. I suppose I should also plug my Liberapay, in case you want to support my ongoing efforts. :slight_smile:

2 Likes

Thank you so much for everything you are doing, Marc! This sounds like such a great update. Yes, I’ll definitely give it a whirl on my M1 machine soon. (I’m just a tad nervous about all of the Abjad changes recently… I’m currently on 3.2 and have a couple of Abjad-only programs which I think will probably break on 3.3 without some rewriting, but I guess I need to bite the bullet sometime :wink: Or I could put the new versions of Abjad and SCAMP in a different virtual environment, I suppose… anyway, I’ll keep you posted!)

I guess maybe you could put those abjad programs in a virtual
environment instead? To be honest, I know I should work more with
virtual environments, but never quite got into the habit. :slight_smile:

Yeah, good point, that is what I did! And, OK, it looks like SCAMP’s local version of fluidsynth does now work on M1/Big Sur with Rosetta—with the caveat that there seems to be some continuing weirdness with fluidsynth not being able to access Core Audio, so it’s having to fall back on another audio driver, I think. The first time running import scamp gave me this:

Testing for working audio driver…

fluidsynth: error: Couldn’t find the requested audio driver ‘alsa’.

fluidsynth: Valid drivers are: coreaudio, file, portaudio

fluidsynth: error: Error setting the audio callback. Status=-66748

fluidsynth: error: Couldn’t find the requested audio driver ‘dsound’.

fluidsynth: Valid drivers are: coreaudio, file, portaudio

fluidsynth: error: Couldn’t find the requested audio driver ‘Direct Sound’.

fluidsynth: Valid drivers are: coreaudio, file, portaudio

fluidsynth: error: Couldn’t find the requested audio driver ‘oss’.

fluidsynth: Valid drivers are: coreaudio, file, portaudio

fluidsynth: error: Couldn’t find the requested audio driver ‘pulseaudio’.

fluidsynth: Valid drivers are: coreaudio, file, portaudio

fluidsynth: error: Couldn’t find the requested audio driver ‘jack’.

fluidsynth: Valid drivers are: coreaudio, file, portaudio

Found audio driver ‘portaudio’. This has been made the default, but it can be altered via the playback settings.

I think the fourth line (in bold) is where fluidsynth found Core Audio but failed to load it.

Just to make sure that this was coming from SCAMP’s local copy, I also ran…

scamp.playback_settings.try_system_fluidsynth_first = False

scamp.playback_settings.make_persistent()

…then started python afresh, ran import scamp again (no warnings/comments this time), and was able to code and get sound just fine. So I think it’s all good, yeah? Let me know if there is anything else I should test!

Interesting… When you got it work earlier by installing fluidsynth using homebrew, did it work with coreaudio, or did you have to use portaudio?

I had to use portaudio.

So, currently after updating the PIP, I have the JSON in ~/.local/lib/python3.8/site-packages/scamp/settings/. (Actually, it’s a bit deeper than that because I use pipenv, but you get the idea.)

Should I manually:

mv ~/.local/lib/python3.8/site-packages/scamp/settings ~/.local/share/SCAMP

or just rely on changing a setting from within Python to take care of all the magic?

Strange… you’re sure this is SCAMP 0.8.8? Can you run:


import scamp
print(scamp.__version__)

Also, you might check the contents of
~/.local/lib/python3.8/site-packages/scamp/_package_info to see what
version that says. It’s possible you have multiple copies of scamp in
different virtual environments or something…?

I hadn’t tried importing scamp after the upgrade. It looks like it set up the new directory and files upon first run… but did not get rid of the old. So, I’ll manually get rid of the older JSON files.

(It no longer needs the .../lib/python3.8/site-packages/scamp/settings directory or contents, right?)

Yeah, should be able to delete the old settings! SCAMP just recreates a default settings file when it doesn’t find one.

Thanks Marc!