It's job hunting time, and while I am skeptical that there are very many
paying jobs for Linux audio developers out there, I thought I'd at least
ask on this list. What companies are doing work in the Linux audio
Or, on the other side, anybody know of interesting
music-instrument/audio companies located in or around NYC (where I live)
who might need Linux folks for their web presence or other online stuff?
Any tips appreciated!
Hi Linux Audio Developers,
TL;DR; Discussing experience driven design for linux audio.
I'd like to discuss the "age of experiences". Allow me 10 minutes of
your time, to watch a video by Aral Balkan talk about development of
technology, FLOSS, design, and the future.
To start, please watch the following clip: I've skipped into the video
to get the section I think is most interesting to discuss on this
To bring this discussion to a productive start, I'd like to concider
the tools we have available as the linux-audio community: they
certainly have features, and empower the user to own thier tools, and
the data used with those tools.
Should we improve experience for users?
Should we design "experience driven open" software?
Should we forward the UX of Linux Audio to the "age of experiences"?
What do users know, that developers might not?
What is it that needs to change? Are there even issues here?
If so, how do we (the community as a whole) try to solve this?
I hope this is a productive and inclusive discussion, and politely
request remaining on topic ;)
To a fruitful discussion, -Harry
tonight is the next edition of the Creative Music Coding lab:
We welcome again all creative music coders at STEIM for an evening of
exchanging current work, problems and solutions - and music together.
Entrance is free.
And let us know if you plan to join (just to get an idea of how many
seats, and how much coffee and tea we should prepare)!
Focusrite's RedNet series of interfaces uses Dante as the transport
protocol. Going to the Dante home page I find that an audio driver
(mac/win) is available for $30 or so (there is apparently a linux version
available from another party). Yet Focusrite sells a RedNet PCIe
card for around $800... one hopes it has more on it than an ethernet port
:) That looks like a sound card to the computer. This card does not look
like it has a special plug on it (like the locking ones some of the
snake/mixing boxes have). I am wondering what other processing might be
happening on this card to make it worth Focusrite's effort to produce.
Routing to be sure, but the Interface boxes all have that anyway. DSP?
Effects? maybe, but not useful on a Linux box I am sure.
I realize a big part of the cost is scale (lack of scale in this case),
but can't help but think that the money would be better spent on a better
mother board. For example moving from an i5/7 to a Xeon based board.
Reading more about the RedNet PCIe card. It is 4 lane, but the recomend
installing in an 8 lane slot. They also recomend using a GB switch to
which both the PCIe audio card as well as the MB native Ethernet port is
connected. They are suggesting that all the audio will go through PCIe AI
card and that control will go through the native enet port. This all may
be to do with 128 channels at 192khz at 3ms. The native enet port has the
dante driver on it too.
I am not suggesting that the Linux world embrace Dante as a protocol so
much as learning from its implementation. I am not sure that building for
192k is the way to go though.
Some numbers... if they are talking 192k with a 32sample buffer (like jack
with 16/2?) it would seem there is a lot of extra latency built in as at
48k and 16/2 the raw latency from card to jack is only .6ms and at 192k it
would be less than .2ms... .3ish for return trip. So the network and ADC
together take a lot longer. Considering my USB IF at 48k has an ADC time
of ~.5ms, most of that is network.
I am looking forward to testing Fons' n2jbridge jack backend. I will not
be using 192k however. I generally use 48k, but may try 96k to test
differences in latency. My own low level protocol is way down the road, if
it ever happens.
I've got this audio app I'm writing which uses message passing to
communicate between threads (similar to the actor model). A message
channel consists of a ring-buffer for the actual message storage, and
then an eventfd so that a thread can block on its channel (or,
At the moment, when the audio thread (the JACK callback) needs to send a
message over a channel to another thread, it follows the common codepath
of appending the message to the channel's ring-buffer and then
write()ing to the eventfd. I suspect this is not real-time safe, but is
it something I should lose sleep over?
QMidiArp 0.5.2 has just seen the light of the day. It brings mainly
two improvements. One is a comeback, that of tempo changes on the fly,
and that now includes also tempo changes of a potential Jack Transport
master. Also the Jack Transport starting position is finally taken into
account, so that QMidiArp should be in sync also when starting the
transport master not at zero.
The second one is Non Session Manager support, mainly thanks to the work done by Roy Vegard Ovesen!
Note that for compiling in NSM support you will now need liblo as dependency.
Enjoy, and enjoy LAC in Graz this year
QMidiArp is an advanced MIDI arpeggiator, programmable step sequencer and LFO.
Everything is on
o Tempo changes are again possible while running, both manually or by
a Jack Transport Master
o Jack Transport position is now taken into account when starting,
QMidiArp used to start always at zero
o Muting and sequencer parameter changes can be deferred to pattern
end using a new toolbutton
o Modules in the Global Storage window have mute/defer buttons
o Global Storage location switches can be set to affect only the pattern
o Non Session Manager support with "switch" capability (thanks to
Roy Vegard Ovesen)
o NSM support requires liblo development headers (liblo-dev package)
Hello Linux Audio Users and Developers
In less than an our the MOD Duo Kickstarter campaign will go live and so it is with great pleasure that the MOD Team makes the announcement of the desktop versions for our entire software suite.
Some of this software has already been announced in the past but, as part of our Kickstarter campaign, we put the necessary effort to have them running in a regular Linux environment and not just inside the MOD. All instructions in Github were also updated in order to yield working elements when followed.
Most of this software has been under development for almost two years and their history is related to the development of the MOD itself. Being so, they carry some differences in workflow when compared to other LV2 programs and our current effort is being put on correcting those differences.
The softwares are:
MOD Client - run your LV2 plugins using the MOD interface.
MOD SDK - plugin interface creator
Use this program to create the HTML interface required by the MOD Client. If you don’t create an interface the plugins still work, but their icons will be a tuna fish can with just the ON/OFF button. When you click on the gear symbol on the upper right side of the icon you have access to the Plugin Settings Screen in which all parameters are visible.
The MOD SDK is Python based and can be installed by typing “pip install modsdk”
As the MOD Client, it runs on your browser and requires a mod-workspace folder (or link) in which you place your LV2 bundles.
Just run “modsdk" in your terminal and point your browser to localhost:9000
There is also post on our blog about the SDK: http://portalmod.com/blog/2014/09/the-mod-sdk
LV2BM - tool for analyzing and benchmarking LV2 plugins
Allows to select which URIs to test
Uses minimum, maximum and default control values to run the plugins
Uses several controls combinations in the full test mode
The output shows the JACK load percent
LV2 port of the CAPS suite of LADSPA plugins.
- TAP-LV2 -
LV2 port of the TAP suite of LADSPA plugins.
- Pitch shifters - http://github.com/portalmod/mod-pitchshifter
Capo - up to 7 semitones up pitch shifting
SuperCapo - up to 24 semitones up pitch shifting
Drop - up to 12 semitones down pitch shifting
SuperWhammy - continuous pitch shifting from -12 to 24 semitones
Harmonizer - scale interval generator
- Utilities - https://github.com/portalmod/mod-utilities
Switchbox - A/B box for audio signal routing
SwitchTrigger - 4 excluding channel selector
ToggleSwitch - 4 non-excluding channel selector
Gain (mono and stereo)
Filters (LP, HP and BP) - 1st, 2nd and 3rd order
Two way mono crossover - 1st, 2nd and 3rd order
Three way mono crossover - 1st, 2nd and 3rd order
- Distortions - mathematical simulations of classic distortion circuits
LV2 simplified port of the SooperLooper.
All plugins from our repository have the HTML MOD GUI included.
In our Github repository - www.github.com/portalmod - we also have plugins that were forked from the original repositories.
One of our aims is to trigger a dialogue with the developers, deprecate our forks and add the MOD interface to the original plugins but that depends on the developers and creators and shall be discussed in a one-to-one basis.
Wish you all the best
The MOD Team
Ah, the equinox...
Twice a year a cherished planetary alignment checks in on schedule,
The little rock gets another round from its warmy solar furnax, from
which were forged. The pale blue dot gets yet another round and to no
surprise, another tinier dot gets here around:
Qtractor 0.6.3 (armed hadron beta) is now released!
* Revamped mixer (un)dockable panels (NEW)
* Plugin preset selection sub-menu (NEW)
* LV2 Time position/transport event support (NEW)
* Constrained plugin multi-instantiation (FIX)
* Automation curve node resolution (FIX)
Qtractor is an audio/MIDI multi-track sequencer application written
in C++ with the Qt4 framework. Target platform is Linux, where the Jack
Audio Connection Kit (JACK) for audio and the Advanced Linux Sound
Architecture (ALSA) for MIDI are the main infrastructures to evolve as a
fairly-featured Linux desktop audio workstation GUI, specially dedicated
to the personal home-studio.
nb. Despite the old Qt4 stance, but still recommended, Qtractor does
build, runs and does it all on Qt5 for quite some time now. However, the
former recommendation prevails as the despicable LV2 plugin GUI
X11/embedding support through libSUIL just does NOT work on modern Qt5.
- source tarball:
- source package (openSUSE 13.1):
- binary packages (openSUSE 13.1):
- quick start guide & user manual (still outdated, see wiki):
- wiki (help wanted!):
Weblog (upstream support):
Qtractor is free, open-source software, distributed under the terms
of the GNU General Public License (GPL) version 2 or later.
- Make the mouse-wheel to scroll the plugin list views, when not
hovering a direct-access parameter slider.
- Mixer widget gets (un)dockable Inputs and Outputs panels, also with
their respective title captions.
- Plugin instantiation is now constrained as much to prevent any audio
channel output overriding.
- Existing plugin presets may now be selected right(-click) from plugin
list context-menu (ticket by Harry van Haaren, thanks).
- So-called "painting" over multiple selected event values, while on the
MIDI clip editor view pane below the main piano-roll (eg. note
velocities, controller values, etc.) is now split into two similar
painting modes, whether the sub-menu Edit/Select Mode/Edit Draw is set
on (free-hand) or off (linear).
- Drag-and-copy of plug-in instances across tracks or buses (ie.
cloning) now also copies the direct access parameter setting (ticket by
Holger Marzen, thanks).
- File/Save As... now prompts and suggests an incremental backup name
for existing sessions files.
- Zooming in/out increment is now augmented by whether shift /ctrl
keyboard modifiers are set (on a ticket request by Holger Marzen, thanks).
- LV2 Time position event messages for plugin atom ports that support it
is now being implemented.
- Attempt to break extremely long audio file peak generation on session
close or program exit (as reported by EternalX, thanks again).
- MIDI Controllers Hook and Invert properties are now properly saved for
tracks (after bug report by Nicola Pandini, thanks).
- A segmentation fault when closing with VST plugins open has been
hopefully fixed (after a patch by EternalX, thanks).
- Messages standard output capture has been slightly improved as for
non-blocking i/o, whenever available.
- Automation curve node editing has been slightly improved in regard to
time positioning and resolution.
Enjoy && have fun.
rncbc aka. Rui Nuno Capela
Just trying to get a clearer understand so hope these aren't too noob-ish.
If you have several processes wanting to send audio, does the callback go to all
of them at (essentially) the same time, or does Jack poll them?
If the former, is it the quickest to complete that gets processed first?
If the latter, does Jack maintain the same order (assuming none stop) or might
it change between buffers?
I've a few more questions but they depend on whether either of these
scenarios is correct!
Will J Godfrey
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.