Hi,
since the webpage for the Linux Audio Conference 2010(*) was unclear on the
deadline for paper submissions, please let me clarify this here:
The deadline for _paper submissions_ is February 14th, 2010. Until yesterday,
the webpage incorrectly mentioned "Call for Abstracts", which should have read
"Call for Papers" instead. This has been corrected now.
Additionally, some information about the desired size and other constraints
for paper submissions has been added to the web page mentioned below.
Please feel free to forward this mail to whatever people/mailing lists are
suitable.
Sorry for the trouble,
Frank, on behalf of the LAC2010 organization team
(*) http://lac.linuxaudio.org/2010/?page=participation
Hi,
Where to start? I have a Dell 7000 laptop and I'm wondering if it can be a
music synthesizer(something like a Minimoog). If not, why not?
I know there are much more powerful machines out but that's beside the
point. If the goal is a dedicated performance grade synth(as in it sounds
good and doesn't cut out or lock up on a whim) is there some intrinsic
reason why such hardware cannot be utilized. The distributions(Ubuntu
studion, PureDyne etc) typically have a heavy footprint and stuff that many
times seems superfluous. If one starts trying to cut pieces out of
distribution(via the standard packaging mechanisms) you end up with slightly
to very crippled systems.
On the other hand, I have a Roland JV1010 tone box that is relatively stable
and I doubt has faster or more sophisticated processing than in the Dell.
Part of the reason I'm asking is I'm wondering if the following would be
viable
1. Implement a synth on a hard real time platform. RTAI or RTLinux. Such a
system would boot up as a dedicated synth aka cut out stuff unnecessary for
other than sound control/production
2. Characteristics of a synth could be set while in a normal Linux
environment.
sorry bout the slight ramble but that's enuff to start off
david
Hello folks,
Right on the heels of big One-O we've decided to release a minor
update with some corrections, main features being some package
improvements and a midi timing issue when running under very high
priority.
MusE : http://muse-sequencer.org
[Fixes since 1.0]
* Removed: Disabled watchdog thread. (T356)
* Changed/Fixed: Thread priorites: Added command line switches
for audio (-P) and midi (-Y). (T356)
- Audio (-P) applies to dummy driver only.
(Else audio priority is fixed by Jack).
Fixes potential issue with midi timing when MusE was assigned
a very high priority.
* Added: Enable/disable LASH command line switch (-L),
(if LASH support is compiled in). (T356)
- Helps prevent some issues like auto-starting Jack, or
automatically routing midi to fluidsynth (observed).
* Fixed: BUG ID: 2879426: *.med does not save meta event types. (T356)
* Fixed: Midi meters now show for each track even if they're all on
same device and channel. (T356)
* Applied: muse-destdir.patch Scripts and utils packaging fix
submitted by Orcan Ogetbil. (T356)
* Fixed: python detection exchanged for script from http://libvirt.org/ (rj)
* Feature: Jack transport enable/disable in Midi Sync settings window.
Stores setting per-song. (T356)
- Should be Ok to use and test. Needs a bit more work. See jack.cpp
and jackaudio.h
* Fixed: Speedups of audio pre-fetch especially when moving the cursor
around (seeking). (T356)
[What is MusE again?]
MusE is multitrack virtual studio with support for:
* Midi
(only Alsa yet)
* internal softsynths, including soundfont player FluidSynth
and sample player Simple Drums
* DSSI softsynths, including VST instruments
* with a patch to DSSI, VST-chunks are handled
* Drum editor
* Pianoroll
* Conventional arranger
* midi automation
* and lots more
* Audio
* Jack
* Jack transport
* LADSPA plugins
* VST plugins through dssi-vst
* audio automation, old sch00l
* and lots more
[ChangeLog]
For a complete list of changes, check the ChangeLog in
the package or online at the sourceforge site:
http://lmuse.svn.sourceforge.net/viewvc/lmuse/trunk/muse/ChangeLog?revision…
[Download]
http://muse-sequencer.org/index.php/Download
The MusE team
bah, was meant for the list.
---------- Forwarded message ----------
From: Paul Davis <paul(a)linuxaudiosystems.com>
Date: Thu, Jan 28, 2010 at 3:08 PM
Subject: Re: [LAD] hard realtime performance synth
To: David McClanahan <david.mcclanahan(a)gmail.com>
On Thu, Jan 28, 2010 at 3:07 PM, David McClanahan
<david.mcclanahan(a)gmail.com> wrote:
> Ok, this may a partial fair point, but I don't think its impossible that
> with a machine with 100+ MB of RAM that one could screw off virtual
> memory(paging) especially since I'm not really after having a soundfont
> library available so much as having something that calculates a sample at a
> time.
>
> The fair part may be the "3 levels of cache" which I assume amounts to a
> buffering delay.
no. it refers to your processors L1, L2 and (maybe) L3 cache. where
the next instruction (and data) is when its time to execute it is
going to make a HUGE difference to long it takes. modern general
purpose processors are not built with the idea of predictable,
deterministic execution in mind.
hi...
since i dont want to let jack1 codebase die in a feature freeze,
i added some features.
- smp aware
- clickless connections
these changes are too radical to be included in mainline jack1.
so it gets a new name.
its approaching beta status now. dunno... maybe someone is motivated to
test it.
http://hochstrom.endofinternet.org/trac/tschack/wiki
--
torben Hohn
Stéphane -- sorry to veer so wildly off-topic... but jackdmp is
expected to work on Solaris, right? Is it actively tested? Is it
expected to build with Sun compilers, or only with gcc?
I switched a machine from Linux to OpenSolaris a few months back and
at the time failed to get jackdmp working on it, but I didn't give it
much time because it wasn't all that important then. I'd like to
revisit it though, and wondered what I should reasonably expect.
Chris
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)
