Dear all,
the deadline for submission of papers for the Linux Audio Conference 2010(*)
is coming closer (February 14th, 2010), and (like last year) the amount of
submissions so far is..quite small. However, without papers and presentations
this kind of conference cannot exist.
I believe that most of the prospective paper submitters out there will probably
wait until the very last minute (I recall in one case there was even a bit of
a debate about "what exact time, and what time zone please?" :-), but it would
be helpful to get an idea of the upcoming submissions.
For this reason I am asking that if you plan to submit a paper, to give us/me
a short notice (title, topic) of your planned paper (direct reply, no need to
send that information to any of the addressed lists). This would help us in
planning the next necessary steps.
By the way, we are not considering to extend the paper deadline this year.
Please feel free to forward this mail to whatever people/mailing lists are
suitable.
Regards,
Frank Neumann, on behalf of the LAC2010 organization team
(*) See http://lac.linuxaudio.org/2010
In considering a rand() -> random() -> random_r() transition, is the random_r()
family considered "cool for school"? Or are they simply not worth the bother
given the srandom_r() segfault (easily resolved) and a "non-standard glibc
extensions" tag.
cheers, Cal
Hello all,
Jretune is a Jack client inspired by the 'autotalent'
plugin (re)discovered and discussed some time ago on
the LA lists.
It uses the same algorithm (autocorrelation) for pitch
detection, but there the similarity ends. All the code
is entirely new.
Its purpose is to process solo voice recordings
to ensure they have correct pitch. It can't do
miracles but it helps in some cases. Don't expect
it to work on a mix.
Main differences are:
- Jretune is a Jack client and not a plugin.
- A *much* cleaner output due to a better resampling
and cycle jumping algorithm.
- A very simple GUI, just 12 switches that allow to
disable notes, and a 'nostalgic' analog tuning meter.
The latter means you could probably use it as a guitar
tuner as well, but don't expect miracles.
Later versions will include a 'tuning' control to
define the set of expected pitches, and maybe some
other controls.
This version is very much a beta one, released only
to invite feedback from users. Once it has stabilised
a bit it should be easy to tranform it into e.g. an
LV2 plugin for those that want this, as the complete
DSP code is contained in a single C++ class.
Please don't do this now as the code is very immature.
For the same reason it's available on request only,
and I would expect packagers to ignore this version.
If you want to test this just drop me a line to get
the sources.
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
(I don't agree about the linux-audio-* mailing list
announcement policy, so from now on, program announcements
will only be posted to linux-audio-announce(a)lists.linuxaudio.org !)
Download from
=============
http://archive.notam02.no/arkiv/src/?C=M;O=D
jack_capture
============
jack_capture is a program for recording soundfiles with jack.
The default operation of the program is executed by writing "jack_capture"
in the terminal without any extra command line options:
$ jack_capture
...which will record what you hear in your loudspeakers
into a stereo wav file.
Most important new features since 0.9.36
========================================
* Direct support for mp3 using liblame.
* Console cleanup. Terminal should not be messy
when quitting jack_capture.
* Better buffering schemes.
* Less used memory.
Features
========
* Autogenerated filenames are unique and humanly readable.
* The 4GB size barrier for wav files is handled by continuing
writing to new files when reaching 4GB.
* Supports all soundfile formats supported by sndfile.
(wav, aiff, ogg, flac, wavex, au, etc.) (option: -f <format>)
* Supports mp3 by using liblame. (option: -mp3)
* Option for writing raw 16 bit data to stdout. (option: -ws)
* Built-in console meter, plus option for automatically starting
and stopping the Meterbridge jack meter program. Port
connections to Meterbridge are done automatically, and
on the fly, by jack_capture.
* jack_capture can connect to any input or output jack port.
When "connecting" to a jack input port (i.e. a writable
port), jack_capture constantly monitors which jack ports
which are connected to the input port, and make sure
jack_capture is always connected to the same ports.
In other words, jack_capture will reconnect its ports
automatically during recording to match the connections
of the ports. This is for instance convenient when
recording the playback ports since jack_capture can be
started first, and then other programs can start and
stop at any moment while all sound still should be recorded.
* No limit on the number of jack ports jack_capture can connect to.
(I.e. the --port argument can be specified more than once, plus
that it accepts wildcard arguments. For instance,
jack_capture --port "*"
will connect to all current jack ports, both input and output
ports, except jack_capture's own ports.)
* Buffers are automatically increased during runtime to prevent
underruns and to avoid wasting memory by preallocating too much.
(handled by using lockless atomic fifo/lifo queues to store
temporary sound data instead of ringbuffers)
* The disk thread is automatically reniced to a higher priority when
using more than half of the buffer.
* Significantly better recording performance than Ardour.
(probably because jack_capture writes all channels into
only one file and that it is not creating peak files).
(tested on athlonXP)
* No problem writing at least 256 channels of 32 bit wav at once to a
local hard drive. (tested on icore7)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- From Sunday evening (UTC) until now we had a server outage of ~20 hours
in which all linuxaudio.org services were not accessible. We apologize
for the inconvenience, the cause of which was hardware failure of the
server (cooling failed and the system halted due to overheating). It
took some time to get access to the hardware, fix it and subsequently
perform a complete file-systems check..
Thanks to Ico who maintains the hardware, the services are up an running
again and there has been no data and email loss.
Sorry for this boring message. You may rest assured that this outage did
not include any major animal involvement and no one was harmed during
the process. The three spiders are alive and well.
Cheers,
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAktd4G4ACgkQeVUk8U+VK0IH3QCgkSNGtNAoM24gpN80XD01YZm9
QncAn38ig9CDxT1bW1TVwh/DD8lLIGPn
=yyzu
-----END PGP SIGNATURE-----
Hi guys,I don't know if my previous message got into the mailinglist,
that why I'll ask again. Can rubberbband analize transients? If not what
other libs exists/are good? I found aubio, but before dwelling on it, I
wanted to here yout oppinion.
Thanx,
Gerald
Hi guys, I was wondering if it is possible to use rubberband to analize
the transients of a sample. I have looked at the vamp example plugin,
but i couldn't really get into it. What other libs exist for this task?
I've downloaded the aubio vamp plugin to play arround, but I'd rather
like to solve the problem with rubberband, since I already use it for
stretching in TerminatorX.
thanx,
Gerald
Hi guys, I'm proud to announce Terminator 3.83pre for testing
(http://www.set-germany.org/TerminatorX/terminatorX-3.83pre.tar.gz).
Changes: support for rubberband, filehandling exclusively through
sndfile, some bugs fixed and i hope none introduced :)
Rubberband is used for timestretching the samples. Each turntable has
now an extra 'tempo' knob to stretch/shrink the sample without change of
pitch. Furthermore a tempo sync option was introduced to sync clients
tempo to that of the master: Select a master -> Select one or more
clients -> Press play (load some samples before ) and turn the master
tempo knob and note the automatic change of the tempo of the clients.
Note that the tempo is actually just the stretch factor of the entire
sample since the samples aren't analized for their transients (that's
the next feature!).
To simplify the code, i decided to rely totaly on sndfile
(http://www.mega-nerd.com/libsndfile/). That means only the formats
understood by sndfile are supported.
I tried to contact Alexander König, but he hasn't answered. Maybe we
should pull up a sourceforge project?
Looking foreward to answers, ideas and complaints.
Yours,
Gerald
Hi, some of you might like to know...
All the discussion of tempo maps and sync in the Jack lists forced me
to get off my butt and finally fix MusE's midi sync in.
(Someone asked recently in the Jack lists if there are any apps
which sync properly. Here is one answer).
Until now, MusE responded to midi sync by calculating the sync's tempo.
Then, this tempo together with the sample rate and current frame,
determined what 'tick' MusE was currently at. And of course, ticks drive a
midi engine to produce the notes at particular times.
Because a tempo value was used, sub-tick (frame) resolution
was available. Trouble is, that was the problem, a too-lofty goal.
It used a complicated 24-stage clock tempo filter while playing,
and a simpler three-stage filter while idling in stop mode.
This meant it could not respond to fast changes in tempo, even a
simple step. It was prone to drift, even without tempo changes.
Considering incoming tempo can drift slightly, I had originally
recorded the incoming tempos to a list so I would have
and exact record of the whole 'time line'.
But the whole idea of using tempo seemed odd.
So my idea was to 'direct drive' (increment) the midi engine's
tick counter by the incoming sync messages.
Drift between master and slave has been essentially eliminated.
Response is instantaneous.
The only slight drawback is the resolution.
I've abandoned any notion of using a tempo or tempo map,
or to obtain sub-tick (frame) resolution, during external sync.
At standard 24 ticks per quarter note, resolution is 1/3 of a
64th note. Not too shabby, acceptable for music.
Now I'm thinking, this is probably how sync was designed to be used,
considering simple old 80's hardware - (what clock filtering?).
Extreme stress tests with a Roland TR-505 which has an
adjustable 'analog' tempo pot, and a complete song in the app,
with extra 'tick' tracks driving external synths:
Rock solid and stable, even when going absolutely nuts
with the tempo knob! No noticeable resolution effects.
In our SVN repo now.
Tim.
