I like to announce the first release of GxPlugins.lv2
GxPlugins.lv2 is a set of mostly analogue guitar pedal simulations as
LV2 plugins, simulated with the guitarix ampsim toolkit.
They contain the following plugs:
GxBottleRocket.lv2 - -> tube based preamp pedal
GxHotBox.lv2 - -> tube based preamp pedal
GxVBassPreAmp.lv2 - -> transistor based Bass preamp
GxSuppaToneBender.lv2 - -> transistor based preamp
GxHyperion.lv2 - -> transistor based Fuzz pedal
GxVoodoFuzz.lv2 - -> transistor based Fuzz pedal
GxSaturator.lv2 - -> saturation plugin
GxVintageFuzzMaster.lv2 - -> transistor based Fuzz pedal
GxSuperFuzz.lv2 - -> transistor based Fuzz pedal
GxVmk2.lv2 - -> transistor based solid stage preamp
GxUVox720k.lv2 - -> transistor based solid stage preamp
GxSlowGear.lv2 - -> volume swell plugin
GxGuvnor.lv2 - -> transistor based overdrive pedal
GxToneMachine.lv2 - -> transistor based Fuzz pedal
I hope they may be useful for the one or the other.
Build instruction and screenshots may be found here:
the release zip file is located here:
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 <grib(a)billgribble.com>
On 11/01/17 12:52, Ralf Mattes wrote:
> Am Mittwoch, 11. Januar 2017 13:21 CET, Felipe Ferreri Tonello <eu(a)felipetonello.com> schrieb:
>> Hi Ralf,
>> On 03/01/17 21:37, Ralf Mattes wrote:
>>> Am Dienstag, 03. Januar 2017 19:31 CET, Felipe Ferreri Tonello <eu(a)felipetonello.com> schrieb:
>>>> If sched_setscheduler() returns -1, check if errno is set to EPERM. In
>>>> this case the user trying to perform this operation does not have
>>>> CAP_SYS_NICE capability, which is *required*.
>>>>  http://man7.org/linux/man-pages/man7/capabilities.7.html
>>>> If you want this type of feature, set CAP_SYS_NICE to the group audio
>>>> that you are referring.
>>> ??? How can I grant capabilities to a group? I thought capabilites where either given to
>>> a user (via /etc/security/capability.conf) or to a binary (by means of setcap).
>> AFAIK, pam_cap support users and groups.
> Not according to my local manpages (pam_cap(8) 09/23/2011 and CAPABILITY.CONF(5) -- 09/23/2011).
> Do you have any y reference for your information?
I never tested, but try out based on this reference paragraph 2.2.
Apparently there are two implementations for pam_cap. One supports the
Am Mittwoch, 11. Januar 2017 13:21 CET, Felipe Ferreri Tonello <eu(a)felipetonello.com> schrieb:
> Hi Ralf,
> On 03/01/17 21:37, Ralf Mattes wrote:
> > Am Dienstag, 03. Januar 2017 19:31 CET, Felipe Ferreri Tonello <eu(a)felipetonello.com> schrieb:
> >> If sched_setscheduler() returns -1, check if errno is set to EPERM. In
> >> this case the user trying to perform this operation does not have> >> CAP_SYS_NICE capability, which is *required*.
> >>  http://man7.org/linux/man-pages/man7/capabilities.7.html
> >> If you want this type of feature, set CAP_SYS_NICE to the group audio
> >> that you are referring.
> > ??? How can I grant capabilities to a group? I thought capabilites where either given to
> > a user (via /etc/security/capability.conf) or to a binary (by means of setcap).
> AFAIK, pam_cap support users and groups.
Not according to my local manpages (pam_cap(8) 09/23/2011 and CAPABILITY.CONF(5) -- 09/23/2011).
Do you have any y reference for your information?
TIA Ralf Mattes
Hi list. Hope Rui gets this...
I have a puzzling technical question, involving QTractor.
I have been looking very closely at how Qt's class QThread works.
Actually, it doesn't. On Linux. As a normal user.
A long investigation into its source code and ultimately some test programs,
shows that on Linux it ignores what priority you attempt to start it with,
if running with normal user privileges.
In Qt's qtbase/src/corelib/thread/qthread_unix.cpp:
void QThread::start(Priority priority)
This code in Qt shows it initializes with default attributes which have
scheduling 'other' and thus the range of priority levels is ZERO and thus
QThread is lying about being at QThread::TimeCriticalPriority for example -
it is NOT, it stored your requested level but did not actually set it.
I just finished examining the following programs using 'htop' plus a
custom program to ask what each's scheduling policy is,
(With Jack running realtime etc. etc...)
a) MusE : Two threads running FIFO policy (policy = '1'). Good, expected.
MusE directly uses pthreads, and set policies and levels.
I assume since I'm in the audio group with good rt limits,
some help is going on, 'cause I ain't runnin' as root.
b) QTractor : NO threads running FIFO (all policies = '0'). Bad? Unexpected?
QTractor uses a few different QThreads with various priority settings
including one requesting TimeCriticalPriority. Seem's it's not happening?
c) Qt5Creator test program using QThread set to TimeCriticalPriority: Bad -
thread has policy = '0'.
The Mixxx project found the exact same thing:
"RJ discovered that Mixxx's requests for real-time priority on this thread are
having no effect. Running as a regular user on Linux shows that the priority
range is from 0 to 0, and as root from 1 to 99, but it is set to 1 (the
lowest) by default. However, calling
setPriority(QThread::TimeCriticalPriority) (while running as root)
does result in priority escalation. "
A further look at the ticket shows they had to go with pthreads directly.
What are your thoughts on this? Am I doing something wrong?
Is QTractor really running realtime or not?
After seeing the source and fooling with this, I'm disliking QThread.
Before creating a QThread, I tried to elevate using seteuid, setegid
and so on, and tried elevating to group 'audio'.
Permissions denied, of course.
The MusE project.