MFP -- Music For Programmers
I'm pleased to announce a new version of MFP, mostly consisting
of bug fixes and improvements. It's been about 2 years since the
0.05 release, but lately I have been pretty energized!
A summary of changes is below. Please see GitHub for complete
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.05
* Build issues reported for the 0.05 release have been
fixed or mitigated
* Clarification of semantics around names and namespaces
* A change to send/receive semantics may break patches saved with
earlier versions of mfp, if they make use of vias and scopes
* New demo patches and fixes to old ones
* Improvements to performance, stability and error handling
* Left-side tabs and bottom-edge console/log can be toggled
with ` and ~ respectively
* Better default color selections, and the ability to set
per-object style (colors, fonts) in your patches
* Many other bugfixes and improvements. The complete list of
tickets closed since the 0.05 release is in the 0.06
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 dynamic or parameterized content, with hygienic
layer copying preserving lexical structure without name
* 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
* 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:
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
More sample patches are in my personal patch repo:
Where's it going?
I've been working on MFP as a spare time project for almost 7
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.
Bill Gribble <[hidden email]>
Linux-audio-dev mailing list
|Free forum by Nabble||Edit this page|