The pre-release is here. It's stable. It builds cleanly. No build
errors or warnings. No runtime errors or crashes. No glitches.
If no bugs are found in the next week, then this code (with the
addition of some brand-new patches) will become the stable release.
Changes since phasex-0.12.0-beta4:
- Build system overhaul. GCC version detection for better arch-
specific optimization (compiles clean with gcc-3.4.x or higher).
Atom builds fall back to next-best optimizations for GCC < 4.5.x.
New --enable-32bit and --cpu-power-level= flags and better user
variable handling for ./configure. Missing -lpthread in link phase
- Velocity control for the amplifier. Better aftertouch handling.
- Scheduling policy defaults to SCHED_RR, and can be changed in the
settings at runtime.
- Broken ringbuffer code has been fixed. No more glitches (unless you
have actually run out of CPU).
- Theme loading has been fixed. Now properly detects if the nodoka
theme engine is installed, and quietly falls back to an engineless
- Fullscreen and Maximize interaction have been fixed.
- New command line options: -m (--midi-channel=), -f (--fullscreen),
and -M (--maximize). Loading a patch by name or by program number
on the command line now finds the appropriate patch in the patchbank.
- The lurking patch name corruption bug has been fixed!
- And more. See the ChangeLog for details...
Download phasex and hear for yourself...
Alternatively, you can utilize the git repositoty:
git clone http://sysex.net/git/phasex.git
I wrote a scripting engine for a pro audio plugin by embedding a
CPython interpreter. Since audio sequencing hosts use separate threads
for each audio track, loading more than one instance of my plugin
while running scripting code causes contention on Python's GIl and
results in CPU spikes at low latencies.
While CPython is more than capable of running fast enough in the audio
thread for control-rate (MIDI) work, the GIL is killing us. Using
process migration to move calls to CPython to daemon processes would
take less code than forking python itself, but the scripting engine
includes a python extension module that exposes pointers to the C++
classes in the audio engine. This complicates things quite a bit. The
calls look like this:
size = engine.getAudioBufferSize()
...where 'engine' and 'instrument' are C++ classes in the audio engine
that I wrapped in a python extension.
I think that the biggest problem for me is tackling the complexity of
managing new real time daemon processes for each audio track, finding
an IPC method, and also implementing a middle-ware layer that would
allow those synchronous calls to the engine be made back to the host.
This is the sort of overhead that one can expect when trying to use
process migration to work around the GIL. I consider myself an
experienced coder, but just thinking about finding a clean, rock-solid
daemon management and IPC mechanism that works on Mac and Windows
freaks me out.
Does anyone have any comments on this topic?
I'm impressed by my recent discovery: non-daw and especially non-sequencer:
I love the design of the sequencer, it's very intuitive, userfriendly
and fast! Respect for that!
But I couldn't contact the author. So I was wondering, maybe he is on
this (lad) list?
I really like to know what his plans are with the apps and if he needs
support in some kind of way. Does he continue to work on it? (If not
that would be a real pity, cause this is not just another sequencer...
And then we might need some talented devs to fork it...)
Ok, I hope I will get some sign of life from the author soon...
-----BEGIN PGP SIGNED MESSAGE-----
I'm just curious what your long-time experiences with these
Considering to use one of these two but can't really decide.
But I do not want to switch in a year or two...
Thanks for your advices!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
A number of system here, including the ones at the Casa
del Suono are to be upgraded in the coming weeks.
At the moment they all run Fedora 8, so the first choice
would be to go for Fedora 11. But:
* None of them will run Gnome or KDE.
* Most will be headless anyaway.
* I want access/privilege control to be based on
user and group ID and nothing else. Privileges
will never depend on the user having a local
login or desktop session.
* I'm prepared to have to spend some time configuring
udev, pam, /etc/fstab etc. etc. etc.
* What I certainly *do not want* is some parallel
access control system that would interfere with
the above, or that could modify/bypass/enhance
in any way what has been configured there.
* I'm *not* really prepared to have to waste any time
reconfiguring the Kit family. Consequently I don't
want to see any of them.
So what distro should I go for ? Having to spend weeks
compiling everything from source is not an option.
Anyone able to point in the right direction will receive
my eternal gratitude which could be expressed in quantities
of fine Italian food and drinks if the occasion arises.
Io lo dico sempre: l'Italia è troppo stretta e lunga.
i would like to know if somebody has already thought about a (unified)
way to save or export the settings of ladspa plugins (or vst,lv2..)
I'm familiar with the idea of LASH, but i want to share plugin settings
between different sessions. A typical use case:
After recording songs with my drumset, the gate-plugin applied to
basedrum and snare has most times (nearly) the same setting.
At the moment this is a quite painful task: Ardour is able to save the
settings, but you can't export these or exchange them between other
In addition, ardour's ladspa plugin dialog can just save the settings,
changing an already saved settings is not possible. This results in a
heap of saved settings and old revisions..
It would be great to export these settings, it could be implemented as a
feature in applications like ardour2 ,jackrack or hydrogen.
After exporting the setting to a plain text file (or xml), sharing the
file with other people or between your computer would be no problem.
What are your thoughts on this? What are the disadvantages?
I have tried the contact form on the FFADO website and through the email
address provided in the contact pages at the SourceForge.net project page to
no avail. I'm not sure where else to ask except here. Are any of the FFADO
developers on this email group that can provide a contact email that will
garner a response?
When you gotta have it, you gotta have it. Lesson learned from days of
I'm new to the list so I hope this is not the wrong forum!
I've been working on a midi keyboard ("physical" hardware 88-keys
"professional" = no toy) for a while for which I plan to release the
schematics and source as open source.
It's based around a Fatar keybed (they make Studiologic) and an Atmel
AVR mcu. The code is all in C and is very portable.
Current features are:
- Velocity sensitivity.
- Pedal support.
- Custom velocity curves.
- Only normal MIDI serial "current" link. No USB, yet...
My questions are, Is there an interest in this sort of thing..? What
features would you like to see, what are you missing from