Skip to content

Commit

Permalink
Release candidate for 0.7 (#300)
Browse files Browse the repository at this point in the history
* Do not save the value of a [var]. Closes #295

* Make sure mfpdsp lib for 32-bit build is in LDLP

* Add icon and .desktop file

* Fill in paths for desktop file at install time

* Add ANNOUNCE

* Move ready() to backend

* Move console/sidebar toggle handling to backend

* Refactor to support Store updates for basic attributes

* Async cleanups from testing

* Fix async bugs in patch loading and graph-on-parent

* More async and other cleanups

* Add rand_euclid to doc/ ; fix stepseq init

* Make sure parent UI obj is created before children

* Fix Programming Error #179 on re-create DSP object

* Update README and tutorial

* Fix bugs in buffer and scope behavior

* Async fix for OSC input handling

* Add some more serializable types

* Update known bugs for 0.7 release
  • Loading branch information
bgribble committed Feb 2, 2024
1 parent e839587 commit 58612f0
Show file tree
Hide file tree
Showing 74 changed files with 9,449 additions and 1,533 deletions.
110 changes: 71 additions & 39 deletions README.build
@@ -1,22 +1,23 @@
BUILDING AND INSTALLING MFP
BUILDING AND INSTALLING MFP
===================================

Post version 0.06, 2016-02-07
Post version 0.07, 2024-01-15

TL;DR
---------------------

$ ./waf configure --python=python3 --virtualenv --prefix ~/mfpvirt build install install_deps
[...]
$ . ~/mfpvirt/bin/activate
(mfpvirt)$ mfp -v
$ ./waf configure --python=python3 --virtualenv --prefix ~/mfpvirt build install install_deps
[...]
$ . ~/mfpvirt/bin/activate
(mfpvirt)$ mfp -v

THINGS TO KNOW
THINGS TO KNOW
---------------------

OS platform: I have only tested MFP on 64-bit Linux.
OS platform: I have only tested MFP on 32-bit (raspi) and 64-bit
Linux.

python: MFP requires Python 3.x at this time.
python: MFP requires Python 3.x at this time.

waf: MFP uses 'waf', which you can think of as a replacement for
autotools and make. You do not need to install waf; the correct
Expand All @@ -25,7 +26,7 @@ is designed to work; more information can be found at
https://code.google.com/p/waf/. MFP's "Makefile" or
"configure.in" equivalent is the file "wscript", which is a plain
Python file. The entry points used by waf are the functions
"configure" and "build", defined near the bottom of the file.
"configure" and "build", defined near the bottom of the file.

virtualenv: At this phase of MFP's development you should
probably build it in a "virtualenv" sandbox. The waf scripts
Expand All @@ -35,112 +36,143 @@ configure with --virtualenv as in the TL;DR above and the build
will go into the virtual environment. When you specify
--virtualenv, the install prefix (--prefix) is the path to the
virtual environment, so you shouldn't let this default to
/usr/local.
/usr/local.

setuptools: The build process depends on Python setuptools. If
you have virtualenv installed, you have setuptools already, but
if you aren't using virtualenv you may need to install setuptools
separately. It's packaged as "python-setuptools" on Debian and
Ubuntu.
Ubuntu.

pip: The modern replacement for "easy_install" to install Python
packages is called pip. If (1) you are using Debian or Ubuntu, (2)
you do not want to use a --virtualenv install, and (3) you want to use
the './waf install_deps' feature to install some Python dependencies,
you need the Debian package 'python-pip', or your distro's equivalent,
installed.
installed.

gcc: The C components of mfp (mfpdsp, pluginfo, and testext) are
straightforward C but include some c99-isms, mainly due to LV2. I
have been using versions from gcc-4.8.3 to 9.3.0 with no trouble.

CONFIGURING
CONFIGURING
-----------------------

The basic form:
The basic form:

$ ./waf configure [options]
$ ./waf configure [options]

A full list of options is shown by ./waf --help, under
"Configuration options". --virtualenv is the only "custom"
option.
option.


LIBRARIES
-----------------------

The "mfpdsp" C library/program needs a few C libraries with their
development headers and pkg-config files installed:
development headers and pkg-config files installed:

* ladspa.h (LADSPA plugins)
* glib-2.0 (GLib/GObject)
* glib-2.0 (GLib/GObject)
* json-glib-2.0 (JSON serializing/deserializing)
* serd-0 (LV2 TTL parsing)
* serd-0 (LV2 TTL parsing)
* jack (duh)
* liblo (OSC library, needed by pyliblo)
* lv2 headers (LV2 load/save)

You'll get errors in the "./waf configure" process if these aren't installed.
You'll get errors in the "./waf configure" process if these aren't installed.

Python runtime dependencies are checked for in "configure" and many of
them can be automagically installed by "./waf install_deps" if you
wish.
wish.

install_deps must be run after "./waf install". If you
are using a virtualenv, the installed Python libraries will also
be installed into the virtualenv.
be installed into the virtualenv.

Note that the Python language bindings for Gtk+/GLib and Clutter libraries
CANNOT be automatically installed by this build process. You need to
install your OS package manager's package for the "GIR" (GObject
Introspection Repository) data for Clutter, Glib, Gtk+, Gdk,
GtkClutter, and Pango, and the Python infrastructure to use that data.
In Debian, these are packaged as:
In Debian, these are packaged as:

gir1.2-clutter-1.0
gir1.2-gtkclutter-1.0
gir1.2-gtkclutter-1.0
gir1.2-pango-1.0
gir1.2-glib-2.0
gir1.2-gtk-3.0
python-gi
gir1.2-gtk-3.0
python-gi

BUILDING
BUILDING
-----------------------

$ ./waf build
$ ./waf build

This will build the project into ./wafbuild (or other directory as
specified to "configure"). There may be some temporary stuff placed
into ./build/ and ./dist/ by setuptools, so I wouldn't use those as
names for the waf build directory.
names for the waf build directory.

INSTALLING
--------------------------

$ ./waf install
$ ./waf install

The installation root defaults to /usr/local and can be modified
by passing in the --prefix argument to "./waf configure".

If you get errors on the install step to the effect of os.symlink
failing to make a link because the file already exists -- see GitHub
If you get errors on the install step to the effect of os.symlink
failing to make a link because the file already exists -- see GitHub
issue #220 and please add a comment indicating your Linux distribution
and that you are having this problem.
and that you are having this problem.

Note that the instances of #220 I have seen are failing at the
very tail end of the install process, and are trying to install
files that are already there... which means that you can probably
ignore this error. Try activating the virtualenv and running
mfp. If it launches, you are good to go.
mfp. If it launches, you are good to go.


DESKTOP FILE
--------------------------

The template desktop file `mfp.desktop` will be populated with
paths and installed to ${PREFIX}/share/mfp/mfp.desktop. You will
need to copy it to wherever such things go on your system.

The icon path is what I needed to get icons working on my Gnome
system. You may need to change it. If you need to do something
manual, the actual icon image is the one in mfp.svg. I can't
express how crabby I am about how messed up icons are on the
Linux desktop.

For what it's worth, on my system the desktop file should be
~/.local/share/applications/mfp.desktop


RUNNING TESTS
--------------------------

There are some tests, though not as many as I would like. What's
there basically comes in two flavors, all of which can be run
with various incantations of the `nosetests` test runner:
with various incantations of the `nosetests` test runner:

* Python test cases in mfp/test: run with plain `python /usr/bin/nosetests -v mfp/`
* Python test cases in mfp/test: run with plain `nosetests -v mfp/test/`

* C test cases in mfpdsp/test_*: run with the `testext` plugin
to nosetests, `python /usr/bin/nosetests -v --with-testext --exe wafbuild/libmfpdsp.so`
to nosetests, `nosetests -v --with-testext --exe wafbuild/libmfpdsp.so`

Note on nosetests: I started using it because, 12+ years ago, it
was the best test runner. Now other tools like pytest have won
more mindshare. I spent some effort on the plugins to run C tests
for mfpdsp so I am sticking with nosetests.

HOWEVER, the original nosetests is abandoned and doesn't work
with current Python versions, and the "new" version of nosetests
(nose2) changed the way plugins worked, and doesn't support the
--exe option needed to point nose to the libmfpdsp.so file. So I
switched over to "pynose", which is a fork of the original
nosetests, just updated to work with contemporary Python. It gets
installed by install_deps.
11 changes: 7 additions & 4 deletions README.md
Expand Up @@ -24,7 +24,7 @@ Up next:
* Refactor UI actions to support undo/redo
* Loading audio files into [buffer~]
* Named presets for patches
* Port to GTK4, making UI improvements along the way
* Port to Dear ImGUI, making UI improvements along the way
* Self-contained save format including sample and image files

### BUILDING
Expand Down Expand Up @@ -72,13 +72,16 @@ object, including assigned MIDI and OSC controllers.
## KNOWN BROKEN

There are a number of bugs that I hoped to get fixed by this
release (0.05) but have not. Here are some that I will just have
release (0.7) but have not. Here are some that I will just have
to ask for your patience with:

Ticket | Description
-------| --------------
#165 | Markup in comments does not render when patch is loaded. Workaround: Click in another window.
#217 | MFP must be stopped with `kill -9` in (hopefully rare) error conditions. Workaround: ^Z to stop the process from the shell, then `kill -9 %1`
#299 | If JACK isn't running and can't be started, launch fails ugly
#298 | Occasional retry loop on quit
#297 | Bad behavior on abort of file load
#292 | In larger patches, selection and interaction may get messed up
#291 | When editing a label, the cursor disappears
#204 | Logging is broken when loaded as LV2 plugin
#212 | Rendering of smooth curves on XY plot shows gaps
#220 | 'waf install' can give error messages. Workaround: See the bottom of README.build; possibly no action is required.
Expand Down
123 changes: 123 additions & 0 deletions doc/ANNOUNCE-0.07.txt
@@ -0,0 +1,123 @@
MFP -- Music For Programmers
Release 0.7

I'm pleased to announce a new version of MFP, mostly consisting
of internal refactoring and architecture changes. It's been
almost 7 years since the last release! This one may not have a lot
of user-facing changes, but MFP is much improved internally and this
release is the base for what I hope will be a lot of exciting future
work.

If you're wondering why it's been so long since the last release,
the TL;DR is J-O-B. Recently I have managed to find a time slot
to work on my personal projects more and I've been really
enjoying getting back into MFP development.

A summary of changes is below. Please see the GitHub issue tracker
for complete details:

http://github.com/bgribble/mfp

This version is still source-code-only, but the new build system
should make it a bit easier for those who would like to try it.

Significant changes since release v0.06
----------------------------------------

* Internal architecture converted to use Python asyncio rather than
threads.

* RPC between main process, DSP process, and UI process shifted
to a separately-released package called "carp" (will be installed
as part of build process)

* RPC serialization mostly uses protobuf for efficiency

* UI code refactored into toolkit-agnostic and toolkit-dependent
code, in anticipation of beginning a migration to Dear ImGUI

* Built UI state management out with a separately-released
package called "flopsy" (will be installed as part of build
process). This is building the foundation for robust undo/redo,
but still not there yet.

* Added a step debugger with breakpoints for debugging patches

* Lots of new builtins and bugfixes resulting from my attempts to
do the 2023 and 2024 Advent of Code in MFP patches.


About MFP
----------------------------------------

MFP is an environment for visually composing computer programs,
with an emphasis on music and real-time audio synthesis and
analysis. It's very much inspired by Miller Puckette's Pure Data
(pd) and Max/MSP, with a bit of LabView and TouchOSC for good
measure. It is targeted at musicians, recording engineers, and
software developers who like the "patching" dataflow metaphor for
coding up audio synthesis, processing, and analysis.

MFP is a completely new code base, written in Python and C, with
a Clutter UI. It has been under development by a solo developer
(me!), as a spare-time project for several years.

Compared to Pure Data, its nearest relative, MFP is superficially
pretty similar but differs in a few key ways:

* MFP uses Python data natively. Any literal data entered in the
UI is parsed by the Python evaluator, and any Python value is a
legitimate "message" on the dataflow network. This makes it much
easier to make patches that work like conventional "programs".

* MFP provides fairly raw access to Python constructs if desired.
For example, the built-in Python console allows live coding of
Python functions as patch elements at runtime.

* Name resolution and namespacing are addressed more robustly,
with explicit support for lexical scoping. This allows patches
to have a dynamic number of inputs and outputs, with hygienic
layer copying preserving the lexical structure of each "voice"

* The UI is largely keyboard-driven, with a modal input system
that feels a bit like vim. The graphical presentation is a
single-window style with layers rather than multiple windows.

* There is fairly deep integration of Open Sound Control (OSC), with
every patch element having an OSC address and the ability to learn
any other desired address. MIDI controller learning is also robustly
supported.

* MFP has just a fraction of the builtin and addon functionality
provided by PD. It's not up to being a replacement except in
very limited cases!

The code and issue tracker are hosted on GitHub:

https://github.com/bgribble/mfp

You can find the LAC-2013 paper and accompanying screenshots,
some sample patches, and a few other bits of documentation in the
doc directory of the GitHub repo. The README files at the top
level of the source tree contain dependency, build, and
getting-started information.

More sample patches are in my personal patch repo:

https://github.com/bgribble/mfp-patches


Where's it going?
----------------------------------------

I've been working on MFP as a spare time project for almost 14
years now. The likelihood that it will ever have more than a few
users is low. Luckily, that doesn't bother me much; MFP is a
tool I am building mainly for my own use and education.

That being said, if there's something about it that appeals to
you, I welcome your interest and participation.

Thanks,
Bill Gribble <grib@billgribble.com>

0 comments on commit 58612f0

Please sign in to comment.