Updates available now at
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads>
zita-alsa-pcmi-0.2.0
* Now includes some dirty hacks (implemented via the debug
options parameter so they don't clutter the API) to support
the -L option of
zita-ajbridge-0.2.2
* Fixed the bug that made it fail with Jack period sizes
>= 1024 (filter coefficients going out of range).
* Added some hacks, activiated by the -L option, to make
it work with ALSA's loop devices.
The latter requires some clarification.
The two apps provided by zita-ajbridge were never intented to be
used with the ALSA loop devices. They were developed to provide
additional and full quality capture or playback channels to Jack,
using a real soundcard.
Yet most people trying the first release used them with the
loop devices, to provide a Jack interface to some misbehaving
apps such as flash player or skype. Using the loop device is
required since those apps refuse to work with ALSA's Jack
plugin. It's a dirty hack using an unwanted resampling step,
but it seems there is no working alternative.
The ALSA loop devices presents themselves as hw: devices, but
they don't behave like a real one:
* Timing of period wakeups is quantised to a much too high
value, and produces lots of jitter, worse than even the
most crappy USB interface. It also makes using the device
with small period sizes impossible, as wakeups occur when
it's almost too late. The next cycle will xrun in that case.
* The loop devices have 32 channels. They allow to be opened
with a different channel count at both ends, but then make
a mess of it. For example mplayer's two channels will be
spread out over the available 32, making it run at 16 times
normal speed.
To run zita-a2j or zita-j2a with the ALSA loop device:
* Use the -L option. This forces two things: the sample format
will be 16-bit, and the device is opened in 2-channel mode.
This makes it usable to apps at the other end which can't deal
with floats or more than 2 channels.
Note that just using -c 2 (which is also the default) still
opens the ALSA device with all its channels, as must be done
on a real hw: device, so that won't work.
* Use at least -p 256 -n 3, or -p 512 or higher (on the ALSA
device - Jack's parameters don't matter).
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
I'm very happy with the 3 hours I've spent with Seq24. It's much closer
to my way of composing than other timeline based editors :)
I have some questions:
* I'm using version 0.9.2 that supports Jack session, according to
https://launchpad.net/seq24/+milestone/0.9.2 However, when I save a
session in QJackCtrl, a folder for seq24 is not created. Any config
option that I'm missing, maybe???
* Is there a way to set the playhead possition while on song mode?
* When looping netween L and R markers in song mode, transport slaves
don't loop, they just keep going, is this a bug?
* Which app do you guys recommend for use along with Seq24 for playing
wave loops? I'm thinking something that allows me to open a wave file,
set the number of bars and then trigger it with seq24. Ideally it would
stretch the wave according to tempo and bar length.
Thanks!
Hello,
Does anyone have any pointers towards resources for streaming audio and
video (it is intended for a conference type event, probably both for
lectures and performances). I had some luck with ffmpeg/ffserver and I
guess I could pursue this route but I wanted to see if there is anything
else. I had a quick look at ices2 but did not see any obvious way to stream
video with audio.
I don't mind getting my hands dirty, worst case scenario I will write some
scripts to allow those who will be in charge of streaming but I would
rather find a good solution, alternative to ustream and other such services.
Thank you in advance for any pointers.
./MiS
Greetings,
I'm pleased to announce the release of Non-DAW and Non-Mixer version
1.1.0. It's been a while since the last release. But, I assure you,
the project is still alive and well.
This release includes a number of fixes and some minor improvements to
the build system. The big changes are:
* Enhancements to the spatialization controls (which are automatically
provided for Ambisonics plugins).
* Support for the Non Session Manager.
* Enhancements to Control Sequences, OSC control signals can be sent
from Non-DAW to Non-Mixer. These connections will be preserved in
the session.
* Non-Mixer accepts input for all Module/Plugin controls via OSC.
* Non-Mixer can now import and export individual strips (including the
chain of modules and all their parameters!) This allows a workflow
on a higher level than presets.
* Updated visual styles for both Non-Mixer and Non-DAW. The 'Flat'
style has been greatly improved.
* New knob styles for Non-Mixer and knob style is a configuration
option rather than requiring editing the source.
* New icons in an assortment of sizes.
Additionally, Non now supports a robust new session management
protocol called NSM. A session management daemon is provided along
with a graphical interface called Non-Session-Manager. NSM represents
a significant leap forward for session management in Linux audio.
:: History of NSM
Way back in 2008, I became frustrated with the state of the art of
session management on Linux (a situation which has improved only
incrementally since that time). I ditched support for LASH, wrote a
lengthy post about Non-DAW's session management requirements to the
LAD mailing list, and started managing my sessions with shell scripts
and jack_snapshot. This eventually evolved into a session manager
written in Unix shell and using Unix FIFOs and regular files for
client control/communication. This system of session management was
tentatively called NASH (Non Audio Session Handler) and was never
released. In 2010, shortly after the release of Non-Mixer, I devised a
prototype version of the NSM OSC API and have been using it, still
unreleased and in prototype form, since then. The 2010 implementation
did not have a user interface and was controlled via shell scripts
using the `send_osc` command included in the distribution. Then, in
2012 (4 years later!), I was contacted by an enthusiastic power-user
regarding implementing OSC support in Non-Mixer. Since NSM uses OSC
for server<->client communication, I already had much of the OSC work
done and figured I might as well release it--and, while I was at it,
NSM. I then endeavored to simplify and document the NSM API,
discussing it at length with, and taking many suggestions from, Nedko
Arnaudov, the LADISH author. After implementing the
Non-Session-Manager FLTK GUI to control the session management daemon,
a new release became inevitable.
:: Bullet Points for NSM:
* Extremely fast and responsive control mechanism and user interface.
* The only dependency for clients and server is an OSC library (I use
liblo).
* Smart clients are able to switch projects without restarting.
* Clients can provide real-time status feedback to the server, and
therefor the user.
* The server stores all session data in per-session directories under
a configurable session root.
* Clients are forbidden to save or open files outside of the
per-session directory.
* The server provides simple template support in the form of
whole-session duplication.
* The Session management daemon is fully controllable via OSC.
* Strict user interface guidelines for a uniform and predictable
experience.
* The abstract session management API has no architectural requirement
for JACK, Xorg or any other subsystem (other than UDP
networking). This means that both headless daemons and programs
which are not JACK clients can be managed together in the same
session.
* A single session can be distributed across multiple machines on a
network.
* Multiple, independent, sessions can be opened on one machine at the
same time.
:: More About the NSM API
The latest NSM API documentation can be found at:
http://non.tuxfamily.org/nsm/API.html
NSM is included in the Non-DAW/Non-Mixer repository.
:: Ongoing and Future Development
Features that are in development for future releases include an
auto-learning and graphically re-mappable JACK MIDI<->OSC gateway
program tentatively named Non-OSC-MIDI-Mapper, which will simplify the
connection of bidirectional control surfaces such as the BCF2000 to
Non-Mixer. This program relies on Non's generic Control Signal layer
on top of OSC. So it's not necessarily generally useful (although, in
the future, it may be possible to use the `libmapper` library to
provide the same functionality in a somewhat standard way).
LV2 support is a frequently asked question. For various reasons, I
currently have no plans to host LV2 plugins in Non-Mixer. But if
anyone can come up with a compelling argument for LV2, or name one
existing (libre) LV2-only plugin which couldn't be ported to LADSPA in
a few hours that I couldn't live without having in Non-Mixer--I'd love
to hear about it.
I plan to re-factor Non-Sequencer to use the `nonlib` library common
to Non-DAW and Non-Mixer. This will eliminate some duplicated code and
allow for some of the user interface improvements seen in Non-DAW to
be implemented for Non-Sequencer. It will also enable various forms of
MIDI support in Non-DAW/Non-Mixer (it's not clear yet what forms this
support might take.)
Similarly, by using nonlib, OSC will be available in Non-Sequencer,
probably taking the form of OSC control for pattern triggers and
possibly pattern input. Also, with NSM's 'broadcast' capability, the
holy grail of a shared tempomap is closer than ever.
Another long-term goal for Non-Sequencer is to make the interface more
compatible with touchscreen use, which I am better equipped to tackle
now that I have a tablet like computer to play with.
A near term goal for Non-Mixer is to add an option to that causes all
mixer strips to run in a single JACK client. Conceptually, this is a
horrible idea, but due to some practical performance limitations of
JACK which affect users with hundreds of mixer strips, it may be a
necessary evil. Leave it to JACK to design and advertise a feature
(multiple clients per process) and then turn around and antagonize the
people who actually use it.
:: Project Notes
Please keep in mind that the Non project is a one man show. I designed
and implemented all of this stuff by my self, and at a considerable
cost in time, sleep and energy. I make it available to you so that you
can be free of the enormous burden of having to solve these complex
problems yourself. I see chatter on various forums about forking the
project, the project being dead, etc. Unlike some of the more
heavyweight projects out there, Non has no corporate sponsor, and I
have a complicated and turbulent existence which does not always allow
me to devote my attention to purely intellectual pursuits. I welcome
any and all contributions, whether they be in the form of code,
documentation, testing, package maintenance, chocolate, roses,
precious metals, priceless relics--whatever. If those who bring up the
issue of forking really had the skill and energy required to do
something better with Non-*, you'd think they'd at least try
submitting a few patches to me first...
I run Debian GNU/Linux and Non-* use a made-from-scratch custom build
system which relies on accurate information from pkg-config. I cannot
test on, or anticipate the quirks of, the hundreds of other Linux
distributions out there. I have a policy of never committing code to
the Non git repositories which does not build. Thus, if you are having
a problem building Non on your system, chances are it's just because
of some silly/simple quirk of the distribution you're using that could
easily be fixed. However, I'm not going to scour the web looking for
these reports. Unless you send a report to the appropriate Non-*
mailing list, expect that your issue will never be resolved. As
always, the best and fastest way to get anything fixed is to just fix
it yourself and sent me the patch--preferably with a thorough
explanation in the commit message of why it is needed and how it
works, as the less time I have to spend reviewing a patch, the quicker
it will be applied.
And finally, a note to packagers: If you feel that there's something
about Non's build system that you don't understand or feel like you
have to hack around, please consider discussing it with me. I'm more
than willing to make changes to the build system which make life
easier for packagers and improve the quality of packages. Having flaky
builds of Non-* in a distribution's packages isn't good for
anybody. I've seen comments in distributions' packaging bugtrackers
saying that Non is a dead project, that the "developers" (plural) are
unresponsive etc. But I've never heard from these people. If they
actually took the time to email me, they might have different
opinions.
:: Errata
I do not recommend linking Non-DAW against FLTK 1.3.0. FLTK 1.3.0
introduced a number of bugs, one of which seriously impairs Non-DAW's
graphics performance. Non-Sequencer and Non-Mixer do not use the
features of FLTK that have become buggy, so if you only plan to use
them 1.3.0 should be fine. 1.1.10, 1.1.9, and 1.1.7 work fine,
however.
In the future, I'll be maintaining a known-working version of FLTK
along with the Non repository so that Non-* can be statically linked
to the custom FLTK and avoid problems like this--and also allow many
workarounds used by the Non-* programs to be removed in preference to
fixing them at their source.
If you decide to build FLTK yourself, don't forget to use the
following configure options:
--enable-threads --enable-shared --enable-xft --enable-xdbe
-----
Non-DAW and Non-Mixer (and Non-Sequencer) can be acquired via git from
the URLs listed on the Non website:
http://non.tuxfamily.org
-----
The shortlog from v1.0.0 to v1.1.0 follows:
Jonathan Moore Liles (114):
Mixer: Don't use Fl_Group::clip_children(), which was only made
public in FLTK 1.1.10.
Fix a 64-bit bug in LADSPAInfo.
Fix another 64-bit bug in Module insertion.
Fix a mismerge that caused meter indicators not to be updated.
FL: Clip drawing of value of FL_Sometimes_Input when in non-input mode.
Mixer: Set minimum size for main window.
Mixer: Fix automatic row layout logic.
Mixer: Don't die if user picks a submenu node in module context menu.
Mixer: Destroy a module's parameter editor window when the
module itself is destroyed.
FL: Get rid of unnecessary call to clip_children().
Move non-daw scripts into timeline/ tree.
Mixer: Save/load the control mode status of the gain controller
as part of the mixer strip's state.
Mixer: Improve spatializer appearance.
Mixer: Report azimuth and elevation of panner points.
Mixer/Module_Parameter_Editor: Automatically show panner control
for module parameter pairs named Azimuth and Elevation.
Mixer/Panner: Vary width of latitude lines.
Module Parameter Editor: Don't use local allocation to store label.
Mixer: Further improve the appearance of the Panner widget.
Mixer: Fix azimuth/elevation reporting. Load current values in
Module_Parameter_Editor.
FL/Fl_Scalepack: Give scalepack the ability contain a resizable() child.
Mixer/Mixer: Cleanup.
Mixer: Auto-connect spatializer controls to spatialization plugins.
Mixer: Cleanup.
Mixer/Panner: Fix azimuth assignment.
Make spatialization mode of controller_module more robust.
Mixer/Module_Parameter_Editor: Don't point widow label at stack
allocation.
Mixer/Module_Parameter_Edtior: Silence compiler warnings.
Mixer: Raise (arbitrary) maximum number of channels of JACK
module from 6 to 16.
Mixer: Fix callback delivery by Controller Module.
Timeline: Fix 64-bit bug in interactive region trimming.
Fix 64-bit bug in peakfile handling.
Mixer: Explicitly link to libdl.
Fix build being broken by some include defining a preprocessor
macro for 'None'
Mixer: Don't segfault when removing a module.
Mixer: Don't segfault during teardown upon WM initiated exit.
Mixer: Handle WM main window close event just like Quit menu
comment (confirm save).
Some distributions put --as-needed in pkg-config and fltk-config
results. *See you in /dev/null*
Some distributions put --as-needed in pkg-config and fltk-config
results. *See you in /dev/null*
Really. I do.
Don't rely on 'Fl' symlink which only exists on Debian.
Mixer: Add basic OSC support.
Mixer: Add basic OSC control to Controller_Module.
Mixer: Add commandline option for specifying the OSC port to use.
Mixer: Allow clients to query for available OSC paths.
Mixer: Ensure that JACK_Module passes chain_name_changed event
to its Controllers.
Mixer: OSC enhancements. Responsd to both exact (range limited)
and Control Voltage (0.0-1.0 on */cv) input.
Mixer: Make OSC ports a property of Module::Port, not
Controller_Module. Therefore, all plugin parameters will be accessible
via OSC.
Mixer: Create unique OSC paths even when multiple instances of a
module/plugin with the same name exist in a chain.
OSC: Don't swallow up all parameterless messages.
Mixer: Feedback control values to OSC senders.
Mixer: Default OSC paths are CV. Use /unscaled for exact input.
Mixer: Don't create/destroy OSC ports more often than necessary.
Mixer: Update OSC paths upon chain/strip name change.
Mixer: Add OSC section to documentation.
Mixer: Display realtime parameter changes (initiated via
automation or GUI) in Module_Parameter_Editor
Mixer: Cleanup OSC value scaling/clamping behavior.
Mixer: Fix behavior issues of Toggle controls.
Mixer: Don't allow ',' in OSC paths.
Mixer: Fix mirroring and OSC automation of Spatialization controls.
Implement the Non-Session-Manager (NSM)
Mixer: Fix GUI update on Controller_Modules being controlled via JACK CV.
Mixer: Destroy instances of Controller_Module when the connected
modules are removed.
NSM: Process more than one message per wait cycle!
NSM: Detect death of clients whose processes are not children of NSMD.
NSM: Update documentation.
NSM: Fix logic when waiting for clients to load.
NSM: Support sessions spread across multiple servers.
OSC: Process all available events in one wait cycle.
Give Non-DAW the ability to detect Non-Mixer OSC servers via NSM
broadcast handshake.
OSC: Implement generic signal model with path auto discovery through NSM.
NSM: Mutli-server fixes.
Timeline: Don't die when not running under NSM.
Mixer: Don't die when not running under NSM.
FL: Fix an uninitialized value.
Mixer: Fix an invalid read on strip destruction due to a missing lock.
Don't poll NSM as frequently.
NSM: Clients must use the same protocol (UDP,TCP) as NSM server.
Timeline/Track: Avoid unnecessary drawing of occluded track box.
Timeline: Add interpolation mode choice of Linear and None to
Control Sequences.
OSC: Save and restore OSC signal connections outgoing from Non-DAW.
Timeline: Run OSC output in a dedicated thread.
Timeline: Clock cleanup.
OSC: Signal cleanups.
OSC: Improvements to signal routing.
Add libsigc++ as a dependency.
Big OSC signal cleanups
NSM: Add --detach option to nsmd.
NSM: Add session locking to nsmd.
NSM: Minor GUI enhancements.
NSM: Don't forget to inform GUI of the removal of stopped
clients when closing a session.
OSC: Fix signal creation notification.
Cleanup compiler warnings.
NSM: Time client responses.
Update documentation.
Mixer: Document spatialization control for Ambisonics plugins.
Mixer: Update documentation.
scripts: Allow suggested packages.
Everybody gets new icons! Also, .desktop files.
Use getopt_long for processing command line arguments to Non-DAW
and Non-Mixer.
NSM: For lack of a better place to put it, add 'jackpatch'
program to the repository.
NSM: Minor cleanup.
NSM: Update documentation.
Add notes to packagers.
Add 'gleam' inspired boxtypes to replace the ones in the gtk+
theme. Also, tweak crystal boxtypes.
Mixer: Add new 'plastic' knob type. Make knob type to display
configurable.
GUI tweaks.
Mixer: Try harder to avoid drawing meters more than necessary.
Timeline: Work around bug in FLTK 1.3 when drawing a string
containing only symbols.
Mixer: Make slider types optional too.
Timeline: Warn about buggy FLTK version.
Mixer: Try to fix some weirdness with Controller Module knob display.
Mixer: Implement mixer Strip import/export
Update Non-DAW screenshot in documentation.
Bump versions.
Hi
I'm interested in buying this midi cotroller / sound interface:
http://www.auzentech.com/site/products/jam_primus.php
Has anybody used it with linux (keyboard and / or sound card). How did it
worked? What about latency?
thanks
fran
---------- Forwarded message ----------
From: SuperCollider Symposium London <info(a)sc2012.org.uk>
Hi all,
April sees the SuperCollider Symposium 2012, an international
collision of programming and audio. We can now announce the Wednesday
club finale will be an audiovisual extravaganza headlined by
BOXCUTTER.
Boxcutter’s continuously shape-shifting sound has long flowed beyond
the bounds of what we call dubstep. His lead-heavy missives share the
cross-over appeal of Burial or Vex’d, whilst keeping a foot firmly in
the more electronically-founded margins of the genre. Boxcutter will
headline the SuperCollider Club night at Corsica Studios, evolving his
live bass and electronics set on their famously gorgeous sound system.
Also providing live beats is NY/Berlin legend Timeblind, as well as
Mexican party duo Mico Rex, and Louis Mac premiering his PortaDJ
machine. But it’s not all about beats: this midweek extravaganza also
features mind-altering audiovisual performances from Japan’s
Craftwife, Berlin’s Fredrik Olofsson and Brighton’s Chris Kiefer.
It all takes place Wed 18th April, 8pm–1:30am, at Corsica Studios
(Elephant & Castle tube). Tickets are £5 advance, more on the door.
(Or included in the full-week symposium ticket.) Spread the word.
website: http://www.sc2012.org.uk/
facebook: http://www.facebook.com/events/325748604145008/
sc2012
> others looking for an inexpensive (under US $40)
> but decent way to digitize existing analog recordings
When I had not much money Daniel James posted a link to an elCheapo PCI
Envy24 card at Ebay. Costs were around 30€. I already owned one of those
cards and got this card from Ebay too, TerraTec EWX 24/96. It can't
compare with my RME card, but it's ok for some usage and even today I'm
using both TerraTec cards for MIDI.
Useful audio cards must not be expensive. A replacement for onboard crap
does cost less than 50€/$ and it's able to replace some stereo.
For producing music IMO it's better to spend some more money, if
possible.
- Ralf
Hello everyone! I just joined this list and already I feel I'm in
way over my head. :-) I have one simple question, but it definitely
involves using Linux for audio. In fact, it's such a simple and
common question that I'm almost embarrassed to ask the experts here
about it.
I've finally got my collection of analog sound recordings (LPs and
audiocassettes) down to the relatively few that aren't available in
any digital format but are worth preserving. That means I'll have
to digitize those myself. So --
Can anyone recommend (or disparage) any particular hardware and
software for digitizing sound recordings?
Here are some specifics about my equipment and my expectations:
Something close to CD quality or 320 kbps MP3s will be "good enough"
here. I'll be dealing only with existing stereo recordings. I
already have a turntable, receiver (including phono preamp), and
cassette deck, all working, that are IMO good enough. I also have
the 25' of audio cables (RCA plugs) necessary to connect my "stereo
system" to my computer, unless rearranging my entire room to bring
them closer together would make a significant difference.
At the computer end, I have an low-end Compaq desktop with
integrated audio (inadequate quality for input here) running
Mandriva 2010.0, an available PCIe-x16 slot and some USB 2.0 ports
(no Firewire), plus lots (hundreds of GBs) of free HD space. For
the new audio hardware, I'd prefer something that not only fits this
machine and runs well under Linux, but will also be usable in future
desktop Linux systems (e.g. not a plain PCI card if possible).
Anything that would fit into that PCIe x16 slot (I understand a PCIe
x1 card will work in a PCIe x16 slot) or a USB port -- I just need
something that will accept line-level stereo inputs. I'm hoping to
find something decent in the US $40-80 range, new or used.
For software, I thought I could use 'rec' to put the digitized audio
into some standard file format (and automatically split it into
tracks if desired), and 'audacity' for the digital signal processing
(noise reduction, declicking, etc.). Or are there other programs
that would be better for me, either in audio quality or ease of use?
Any recommendations for hardware or software, especially hardware,
would be very much appreciated! Suggestions on where else to look
for advice would be welcomed too. Thanks!
Adam
Hello all,
A bugfix update of zita-ajbridge is now available at the
usual place.
Thanks to Robin Gareus who discovered the bug: the typical
last-minute-after-testing-added-line-typo. In this case
it meant that both apps would use the lowest resampling
quality in all cases...
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Hello all,
The first official release of zita-ajbridge is now available at
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads>.
Quoting the README:
This package provides two applications, zita-a2j and zita-j2a.
They allow to use an ALSA device as a Jack client, to provide
additional capture (a2j) or playback (j2a) channels.
Functionally these are equivalent to the alsa_in and alsa_out
clients that come with Jack, but they provide much better audio
quality. The resampling ratio will typically be stable within
1 PPM and change only very smoothly. Delay will be stable as
well even under worse case conditions, e.g. the Jack client
running near the end of the cycle.
You will also need the latest zita-resampler and zita-alsa-pcmi
libraries.
All feedback welcome.
Ciao,
--
FA
Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
