Nothing much to say...
but anything goes, as long it goes before the proverbial midsummer
meltdown...
whatever:)
Qtractor 0.5.10 (kilo papa) is out!
Release highlights:
* Edit/Insert, Remove range options (NEW)
* LV2 Dyn-manifest support (NEW)
* Time, frames, BBT display option in-place menu (NEW)
* Audio export track automation (FIX)
* Clip/event selection clear/reset (FIX)
Website:
http://qtractor.sourceforge.net
Project page:
http://sourceforge.net/projects/qtractor
Downloads:
http://sourceforge.net/projects/qtractor/files
- source tarball:
http://downloads.sourceforge.net/qtractor/qtractor-0.5.10.tar.gz
- source package (openSUSE 12.3):
http://downloads.sourceforge.net/qtractor/qtractor-0.5.10-7.rncbc.suse123.s…
- binary packages (openSUSE 12.3):
http://downloads.sourceforge.net/qtractor/qtractor-0.5.10-7.rncbc.suse123.i…http://downloads.sourceforge.net/qtractor/qtractor-0.5.10-7.rncbc.suse123.x…
- quick start guide & user manual:
http://downloads.sourceforge.net/qtractor/qtractor-0.5.x-user-manual.pdf
Weblog (upstream support):
http://www.rncbc.org
License:
Qtractor is free, open-source software, distributed under the terms
of the GNU General Public License (GPL) version 2 or later.
Change-log:
- Default drum-key note names are now properly showing on MIDI tracks
that are assigned to known drum/percussive instrument patches (eg.
SoundFont 2 (.sf2) bank 128).
- Time display format (frames, clock-time or BBT) may now be changed
from the context-menu on any time entry spin-box.
- LV2 plugin support is now tightly tied to liblilv; the same tie
applies to LV2 plugin UI support and libsuil and vice-versa.
- Mixer buses racks (ie. left/input and right/output panes) are now both
kept fixed-width when whole mixer window is resized.
- Unconditional LV2 Dyn(amic)-manifest support has been added.
- Main track-view Edit/Insert,Remove/Range dialog is now being
introduced with optional applicability to Clips, Loop, Punch in/out,
Automation, Tempo-map and/or Markers.
- New range removal editing tool, split/moving clips backward at the
specified edit-head/tail interval (Edit/Remove/Range, Track Range)--by
Tuomas Airaksinen, thanks.
- Andy Fitzsimon's original icon from opencliparts.org makes it through
as the default standard scalable format (SVG).
- Automation's back in effect on Track/Export Tracks.../Audio.
- Reversed shift/ctrl keyboard modifier roles on middle-button clicking
over the main track and MIDI clip editor views (aka. piano-roll) in
regression to original old semantics.
- Color selection actions now have a brand new palette icon.
- Make sure main track-view and MIDI clip editor selection is only
cleared on specific discrete commands.
- Try keeping the original session file in most recent files menu list,
despite current version auto-incremental backup mode is in effect.
- Fixed non-zero clip offsets upon tempo/time-scale changes.
- Some sympathy to extreme dark color (read black) schemes is now
indulged on empty backgrounds.
See also:
http://www.rncbc.org/drupal/node/680
Enjoy && have (lots of) fun.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
Hi All,
I finally got around to giving Praxis LIVE its own home on the web
this week. There's a lot more to come in the near future in terms of
help and resources, but this should hopefully give a better overview
of what the project's all about.
www.praxislive.org
Praxis LIVE is an open-source, graphical environment for rapid
development of intermedia performance tools, projections and
interactive spaces.
This replaces and enhances the somewhat outdated information on the
Google Code site. Downloads and code are still hosted there, though
I'll be looking to host downloads elsewhere in the near future now
Google has deprecated this.
Thoughts and / or contributions to the further development of the
project and its online resources very much appreciated.
Thanks to whoever mentioned Praxis LIVE on the open-source musician
podcast last month - your slight confusion over what it was for was
one of a number of factors that prompted the development of this
website! :-)
Best wishes,
Neil
--
Neil C Smith
Artist : Technologist : Adviser
http://neilcsmith.net
Praxis LIVE - open-source intermedia development - www.praxislive.org
Digital Prisoners - interactive spaces and projections -
www.digitalprisoners.co.uk
OpenEye - the web, managed - www.openeye.info
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi all,
(apologies if this is the wrong mailing list, but i'm currently only
subscribed to LAD and not LAU. anyhow:)
i'm having serious troubles using zita-ajbridge with alsa loopback
devices.
my basic requirement is, to allow *any* ALSA-only application to be
"jackified".
i'm on debian, and my current tests are done on i386 resp. x86_64, but
my target platform is armel (wandboard solo, powered by a single-core
ARM cortex-A9)
the basic problem i'm facing is, that i don't get much output.
occasionally i do get output (e.g. with mplayer)
so here's what i did:
# modprobe snd-aloop (with all the default parameters)
which gives me:
$ cat /proc/asound/cards
0 [Generic ]: HDA-Intel - HD-Audio Generic
HD-Audio Generic at 0xf0244000 irq 43
1 [SB ]: HDA-Intel - HDA ATI SB
HDA ATI SB at 0xf0240000 irq 16
2 [Loopback ]: Loopback - Loopback
Loopback 1
$ zita-a2j -v -d hw:Loopback,0 -L
playback : not enabled
capture :
nchan : 2
fsamp : 48000
fsize : 256
nfrag : 2
format : S16_LE
Starting synchronisation.
0.460 0.999864
[...]
on another terminal i do:
$ mplayer -ao alsa:device=hw=Loopback.1 STE48.wav
and after connecting zita-a2j to my system's output, i can hear sound.
cool!
ok, so i stop mplayer, and start some other application e.g. Pd (what
else). hooking it up to the loopback device, i start my testpatch:
silence :-(
ok, so mabye Pd is broken, i try some zita app, e.g. zita_delay (from
libzita-alsa-pcmi)
$ alsa_delay hw:Loopback,0 hw:Loopback,0 48000 1024 2
playback :
nchan : 32
fsamp : 48000
fsize : 1024
nfrag : 2
format : FLOAT_LE
capture :
nchan : 32
fsamp : 48000
fsize : 1024
nfrag : 2
format : FLOAT_LE
synced
Signal below threshold...
Signal below threshold...
[...]
not very surprisingly, it doesn't detect any input signal (zita-j2a is
not running), but i also don't hear any output signal.
hmm.
stopping jack (which quits zita-a2j), i try a alsa_delay on my soundcard:
$ alsa_delay hw:SB,0 hw:SB,0 48000 1024 2
playback :
nchan : 2
fsamp : 48000
fsize : 1024
nfrag : 2
format : S32_LE
capture :
nchan : 2
fsamp : 48000
fsize : 1024
nfrag : 2
format : S32_LE
synced
2176.341 frames 45.340 ms ??
2176.405 frames 45.342 ms ??
and i hear nice sine-tones.
checking the output of alsa_delay vs that of zita-a2j, i notice that
one uses latter S32_LE whereas the former uses FLOAT_LE.
since i cannot change the format of alsa_delay without recompilation,
i try to match the two formats with zita-a2j, by running:
$ zita-a2j -v -d hw:Loopback,0 -p 1024
$ zita-a2j -v -d hw:Loopback,0 -p 1024
playback : not enabled
capture :
nchan : 32
fsamp : 48000
fsize : 1024
nfrag : 2
format : FLOAT_LE
Starting synchronisation.
3.716 0.999042
2.713 0.998499
[...]
which gives me pretty much the same config as is used with alsa_delay.
re-starting `alsa_delay`: still no sound.
just in case: starting zita-j2a as well:
$ zita-j2a -v -d hw:Loopback,0 -p 1024
playback :
nchan : 32
fsamp : 48000
fsize : 1024
nfrag : 2
format : FLOAT_LE
capture : not enabled
Starting synchronisation.
-2.919 1.000933
-1.457 1.001286
[...]
and making sure that zita-*2* are jack-connected to system, but still
no luck.
hmm, what is going on here?
currently the *only* application that i can convince to use
zita-ajbridge seems to be mplayer, and only in S16_LE mode.
what are the requirements for an application to use zita-ajbridge?
shouldn't other zita applications (like alsa_delay) automagically
fullfill these requirements through libzita-alsa-pcmi?
do my application either have to support FLOAT_LE or be stuck with
S16_LE/2channels forever?
is there a tutorial out there on how to use zita-ajbridge with snd-aloop?
masdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iEYEARECAAYFAlHeuicACgkQkX2Xpv6ydvRT+ACcC0ZW07gHvW6ub3HXhWG8sXR8
TYcAn1SALKnlTeFYJmtPz8gkvpX+aLNB
=BuNd
-----END PGP SIGNATURE-----
Hello everyone!
I was wondering, is there a direct way to do a transport locate in sync with
klick? Or can one at least tell klick to relocate to 0, so that the metronome
is back in line with everything else. I've tried this:
tty1> klick -i -t # interactive and JACK transport aware
tty2> ecasound -i null -o jack_alsa -G:jack,eca,sendrecv # Transport master
Klick reacts to start and stop. But it doesn't react at all to a setpos 0
(relocate to 0) in Ecasound.
Warm regards
Julien
----------------------------------------
http://juliencoder.de/nama/music.html
Hello all,
I'm trying to add Alsa support to an application with mixed results.
When using the default audio output it sounds fine (my dac display 48KHz
as sampling rate, which doesn't equal the source signal of 44.1) but
when using hw:0 it is heavily distorted and with plughw:0 the sound
stutters at a steady interval of about 2Hz (in these last two cases my
dac display 44.1kHz as the sampling rate). When using libao plughw:0
sound fine (and my dac always display 44.1kHz).
Can anyone give me a direction (or answer) where I might go wrong here.
Unfortunately I'm a bit out of my league here and I do not yet
understand the data that fills buf[]. However, I do know that the data
it supplies works fine with libao, so I do suspect it is something with
the code below.
Thanks in advance, Maarten
ps. it is supposed to add Alsa to the following:
https://github.com/abrasive/shairport/tree/1.0-dev
static void start(int sample_rate) {
if (sample_rate != 44100)
die("Unexpected sample rate!");
int ret, dir = 0;
snd_pcm_uframes_t frames = 32;
ret = snd_pcm_open(&alsa_handle, alsa_out_dev,
SND_PCM_STREAM_PLAYBACK, 0);
if (ret < 0)
die("Alsa initialization failed: unable to open pcm device:
%s\n", snd_strerror(ret));
snd_pcm_hw_params_alloca(&alsa_params);
snd_pcm_hw_params_any(alsa_handle, alsa_params);
snd_pcm_hw_params_set_access(alsa_handle, alsa_params,
SND_PCM_ACCESS_RW_INTERLEAVED);
snd_pcm_hw_params_set_format(alsa_handle, alsa_params,
SND_PCM_FORMAT_S16);
snd_pcm_hw_params_set_channels(alsa_handle, alsa_params, 2);
snd_pcm_hw_params_set_rate_near(alsa_handle, alsa_params, (unsigned
int *)&sample_rate, &dir);
snd_pcm_hw_params_set_period_size_near(alsa_handle, alsa_params,
&frames, &dir);
ret = snd_pcm_hw_params(alsa_handle, alsa_params);
if (ret < 0)
die("unable to set hw parameters: %s\n", snd_strerror(ret));
}
static void play(short buf[], int samples) {
int err = snd_pcm_writei(alsa_handle, (char*)buf, samples);
if (err < 0)
err = snd_pcm_recover(alsa_handle, err, 0);
if (err < 0)
die("Failed to write to PCM device: %s\n", snd_strerror(err));
}
Hi all,
I'm working on a wavetable oscillator class, and I'm wondering about how to
best go about bandlimiting. I see two ways to achieve bandlimiting, i'll
detail as A and B.
A) Create different wavetables for each octave. Base octave includes all
harmonics. Octave 1 has the top half of the harmonics removed by FFT. Oct 2
has the harmonic content halved again.
B) Oversample the single waveform x8. Play the oversampled audio back, and
lowpass with a steep rolloff just below the nyquist of the output
samplerate. Removal of the otherwise aliasing harmonics is done at the
higher samplerate, so its not aliased yet at that stage.
I'm asking in terms of quality and CPU usage: this is for a synth which has
3 oscillators per voice, and 16 / 32 voices..
Cheers, -Harry
Hey everybody,
Its my pleasure to announce that the next OpenAV Productions LV2 plugin is
finished!
Its called Fabla, and its a performance sampler.
Page: http://openavproductions.com/fabla
Demo reel: https://vimeo.com/70122957
One year from today Fabla will be released, and each donation motivates the
release to be one month earlier. -Harry
PS: The release system is the same as the previous OpenAV release for
Sorcer, details available here: http://openavproductions.com/support
Hello all,
Some maintenance updates are available on
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads>
* libclxclient 3.9.0: bugfixes
* aeolus, aliki, jaaa, japa: all now use zita-alsa-pcmi instead
of clalsadrv.
* The aliki package now includes the manual.
That means that clalsadrv is now deprecated. It will remain available
for a few months and then disappear forever.
Note to AMS devs: zita-alsa-pcmi is a near drop-in replacement
for clalsadrv-2.0.0:
* Change the library name in the build files
* s/#include<clalsadrv>/#include<zita-alsa-pcmi>/
* s/Alsa_driver/Alsa_pcmi/
* s/->stat()/->state()/
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 incredible happens.
The electronics of the 'Lampadario' at the Casa del Suono in
Parma consists of a rack with an RME ADI468 converting MADI
to 8 ADAT outputs, 8 Behringer ADA8000 converters, and 8 QSC
amplifiers of 8 channels each. The rack was wired (very neatly)
by a firm specialising in this sort of work.
When I installed the software four years ago, I found out
that 25 of the 64 channels had their phase inverted. For one
of those it was an error in the speaker wiring, which was easy
to correct. The other 24 corresponded exactly to 3 groups of 8,
and the speaker wiring was OK. I assumed that the cables between
the ADA8000 and the amps were to blame - this is a non-standard
cable which had to be hand-made by the whoever did the wiring.
If two technicians had worked on that, they could have had
different ideas of what were the correct connections.
Since I didn't want to take the rack apart, resolder 24 wires
and put it all back, and since there was only one SW app driving
the installation at that time, those 24 inversions were corrected
for by that software. So far so good.
Recently I re-measured the IRs of the whole thing. There
were again 24 channels out of phase. But not the same ones.
One of the groups of 8 had turned in-phase, and another
one was now inverted.
The only thing that has happened to the installation over
the last years is that some of the Behringers failed (power
supply blown up, one per year on average) and were replaced.
So I checked those separately. And yes, some of them had their
output phase inverted w.r.t. the others. Apparently the thing
exists in two versions, but apart from measuring there's no
way to tell which is which. So I'll have to recheck things
each time any of them are replaced again. Thank $GOD we didn't
use those for the WFS system.
The incredible happens.
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)
