Phasex

PHASEX-0.14.97:

[P]hase [H]armonic [A]dvanced [S]ynthesis [EX]periment

Welcome to the latest and greatest of PHASEX!

PHASEX is an experimental MIDI softsynth for Linux/ALSA/JACK with a synth engine built around flexible phase modulation and flexible oscillator/LFO sources. Modulations include AM, FM, offset PM, and wave select. PHASEX comes equipped with multiple filter types and modes, a stereo crossover delay and chorus with phaser, ADSR envelopes for both amplifier and filter, realtime audio input processing capabilities, and more. Inspirations come from a variety of analog and early digital MIDI synthesizers from the '80s and '90s.

GOALS:

• C Hacker Friendly. PHASEX is written entirely in C. No C++. No assembly. From the very beginning, the program framework (now a much larger application framework) has existed to support a synth engine written in good ol' C. Now the application framework is well on its way to serving as a basic platform for developing new instruments written in... you guessed it... C.

• Reliability. Whether playing music on stage, working in the studio, or writing music on a laptop in a coffee shop, the instruments and tools need to function properly and consistently in order to achieve good results. Musicians need to be able to focus on the music, not shortcomings of the toolset.

• Compatibility, starting with full JACK and ALSA API support (and eventually support for additional audio / MIDI libraries), allowing PHASEX to be used in any pro audio workflow on a modern Linux distribution. The standalone application design was partially chosen for this reason -- not all sequencers and DAWs support all instrument plugin formats. For this reason, PHASEX will most likely see support for features such as ALSA channel mapping, JACK Freewheel, and even Non Session Manager (NSM) before seeing support for DSSI or LV2? Why? PHASEX already runs side by side with Ardour, MusE, Rosegarden, Qtractor, Seq24, or any other sequencer supporting JACK MIDI or the ALSA sequencer interface, no matter what plugin APIs these sequencers do or do not happen to support. In the future, adding support for plugin formats may be deemed necessary for making PHASEX more useful in certain situations. For now, the development effort will focus on fine-tuning and extending the usage of the APIs already supported.

• Stage friendly. Low MIDI latency and low timing jitter. Run with or without the GUI. Ability to specify alternate config files (just be sure you have a backup of your ~/.phasex/on-stage.cfg...). With decent hardware running PHASEX and a recent -rt kernel with proper permissions, priority tuning, hardware tuning (BIOS settings, PCI latencies, etc.), and audio buffer tuning, MIDI-audio latencies of under 10ms should be well within reach for audio hardware capable of running with 128 sample buffer periods or better.

• Studio friendly. Focus on workflow. The recent development work has been aimed at making PHASEX easier to use and efficient to manage (quick configuration, built in session management, MIDI connections in the menus, etc.). Again, the focus should be on the music, not on remembering how to make the instrument jump through a bunch of hoops just to do it's job. PHASEX development will continue in this direction with new session management features based on community feedback.

• Great sound. This one is of course, quite subjective, but it still comes down to the same juggling act on the programming end: Choosing the "right" algorithms, making resource usage vs. sound quality decisions, calculation speed vs. accuracy decisions, and of course, decisions about how much programming time is spent on what features (hmmm... is it worth the time to do the math and write and debug the code for nifty-feature-x, or is time better spent fixing broken-feature-y?). At this point, a lot of these decisions have been made and the synth engine as a whole is very stable, but these things are not necessarily set in stone. There is always room for improvement by researching new ways of doing the math and learning new DSP tricks for solving some of the flaws inherent in the current methods. So, how does it sound? Decide for yourself.

FEATURES:

• GTK Interface:

  PHASEX has a GUI with switchable color themes, knobs and buttons for all 150+ patch parameters, preferences dialog for easy configuration, patch bank and session bank, MIDI connections from the main menu, and more. True fullscreen mode, notebook, one-page, and widescreen layouts, and select-able fonts and knob sizes allow PHASEX to fit into any amount of screen real-estate (now able to squeeze into sizes smaller than 800x600, or more comfortably sit in a 1920x1080 desktop).

• Polyphonic:

  PHASEX is polyphonic. In poly mode, voices are allocated dynamically up to the runtime configurable voice limit.
  Oscillators and filters function independently per-voice. LFOs, however, function on a per-part basis. In addition to Poly mode, the three legacy Mono modes are still supported: Mono Smooth mode puts new notes back into sustain if playing legato. Mono Multikey mode maps the keys played, in order, round-robin style to all oscillators based on MIDI note frequencies in use. In Mono Retrigger mode, envelopes and oscillator init phases are retriggered every time a note is played.

• Multitimbral:

  Many parts of PHASEX were re-architected during the v0.14.x development phase. This release is now fully multitimbral, with each part running in its own thread. The number of parts (and thus engine threads) is determined at compile time, and has been tested rigorously with 8 voices on a quad-core q6600. Part switching in the GUI is clean and efficient. Session handling support takes the fuss out of keeping track of session patches.

• ALSA Audio:

  PHASEX supports native ALSA for flawless xrun free audio playback. Sample rate and buffer size are easily configurable to achieve the lowest possible latencies for your system.

• JACK Audio:

  PHASEX has supported JACK audio from the beginning of the public MIDI enabled releases. Any sample rate or buffer size used by jackd can be utilized. Both single- and multi- stereo-pair routings are supported. Basic Transport is supported, but as of this time, the tempo and LFO sync are largely untested and may still need some fine-tuning.

• ALSA MIDI:

  The ALSA sequencer interface has been with PHASEX since its first public release. As of v0.14.x, the ALSA raw MIDI interface is also supported, offering lower timing jitter when controlling PHASEX via hardware MIDI.

• JACK MIDI:

  JACK MIDI provides 100% sample-accurate timing by design. PHASEX has embraced this design, and the new underlying MIDI system is the result.

• Generic MIDI:

  Generic MIDI (/dev/midi) support is provided for communicating with MIDI devices or drivers that use a standard POSIX interface supporting open/close/poll/read/fcntl on a named pipe, socket, or device file. The generic MIDI support has only been tested with ALSA's /dev/midi* and /dev/snd/midiC?D? device files (which are accessed through the POSIX interface, not the alsa-lib API), but should perform the same with any MIDI device interface as long as additional system and library calls are not needed. Currently, compatibility with serial to MIDI converters is unknown, so please send feedback (positive or negative) if you attempt to use a serial to MIDI converter.

• MIDI Control:

  All parameters are quickly mappable and ready for full realtime control. Parameter names are right clickable for quick and easy MIDI controller assignments. Each MIDI controller can be mapped to up to 15 parameters. Velocity sensitivity and key aftertouch can modulate the amp and the filter, or used as raw oscillators of LFOs. MIDI maps may be saved and later restored to facilitate switching between different working environments.

• Realtime MIDI Clock:

  Addresses the issue of how to accurately synchronize MIDI events with individual frame positions within a buffer period instead of quantizing the timing to whatever the audio buffer period happens to be. Typical audio hardware supports stable realtime operation at anywhere from 2-20 milliseconds latency. With no additional synchronization, this audio latency becomes a self-imposed quantization factor on event timing, adding MIDI timing jitter roughly equal to the duration of one audio buffer processing period, hence the need for a MIDI clock:

  A timerless, tickless audio / MIDI timing synchronization system. The clock latches onto the audio buffer processing periods and generates a high-precision MIDI clock reference, with much less jitter than timing based on when the audio processing cycle actually wakes up (which can really be anywhere within the period). This clock is agnostic to the specific audio and MIDI drivers being used and requires no timer interrupts. In essence, the timing accuracy achieved is only dependent on the MIDI hardware/software and realtime scheduling latencies of the system. With decent professional MIDI and audio hardware, sub-millisecond timing accuracy is available with total MIDI event latency unde