Dear fellow LA* members,
As some of you may be aware, instead of a static news page, Linuxaudio.org now has a direct LAA feed as its front page. Consequently, I would like to encourage everyone to please put special care in crafting your LAA posts, meaning much more so than those destined for lau/lad lists, as this is in part what everyone sees when they visit Linuxaudio.org (and if our awstats are any indication < http://stats.linuxaudio.org/cgi-bin/awstats.pl?config=www.linuxaudio.org>, then we do get tons of exposure there that is perhaps more importantly steadily growing). I say this not because there have been some grave offenses recently but rather because I think as a community it would really nice if we collectively put extra attention to this facet that is much considerably "public" than a typical lau/lad post. So, I guess what I am trying to say is perhaps having a post on lau/lad lists mirrored on laa may not be always a good idea.
If I had to single-out one post in there that could use some TLC :-) it would be the call for submissions for the upcoming LAC. Namely, suggesting that there has been little interest may end-up looking like a self-fulfilling prophecy--new and incoming potential contributors to LAC who may have come across this post could be easily discouraged by the way this reads despite the fact we all know that most conference submissions are usually uploaded in the last 72 hours before the submission deadline.
At any rate, don't mean to be preaching, so I hope no one will get offended. And if you do, I guess I owe you a pint (hear that Frank? ;-)
Just my 5-cents worth...
Best wishes,
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Assistant Co-Director, CCTAD
CHCI, CS, and Art (by courtesy)
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-6139
(540) 231-5034 (fax)
ico(a)vt.edu
http://www.music.vt.edu/faculty/bukvic/
Hi,
Has anyone tested TerminatorX 3.83pre?
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
Greetings,
A respondent to my latest article for LJ has asked if I can recommend an
audio function generator for Linux. He's using a command-line app now,
but he'd like to know if there's such an app with a GUI.
Any suggestions ?
Best,
dp
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
