> good god. know an alternative source for calculating the
> coefficients? Bill?
The classic article, in this context, is
"Digital Waveshaping Synthesis"
Marc Le Brun JAES 1979 April, vol 27, no 4, p250
Daniel Arfib, at the same time but independently, did similar work --
I don't know a reference. I think DiPoli wrote a good overview --
perhaps in Roads "The Music Machine"?
CLM has code both for the table-oriented and polynomial-oriented
approaches. There's an example "brighten" instrument in clm.html.
>From: Fernando Pablo Lopez-Lezcano <nando(a)ccrma.Stanford.EDU>
>Is anyone out there trying out this combination?:
>
> kernel 2.4.20-rc1
> capabilities patch
> low latency patch
> preemptible kernel patch
> almost current alsa cvs [20021028.170432 usa pacific time]
>
>If I start jackd and then use the freqtweak jack client I get a completely
>dead machine in a very short time (from a few seconds to 10 or 20
>seconds).
>
>...
>
>Interestingly enough just the jack server running is not enough to kill
>the machine. Adding a jack client (just tried alsaplayer, same problem as
>freqtweak) kills the machine really fast.
>
I have excactly the same problem since i upgraded my machine to SuSE 8.0,
which is based on: kernel 2.4.19-SuSE + capabilities patch + low latency
patch.
Stefan
_________________________________________________________________
Surf the Web without missing calls! Get MSN Broadband.
http://resourcecenter.msn.com/access/plans/freeactivation.asp
i don't want to blow my moderator points this time, so get busy. there
is lots of confusion, mis-information and general cluelessness in the
responses so far. get to it, provide me with some stuff to moderate
upward ...
--p
Havent been receiving any news lately, please help.
-----Original Message-----
From: linux-audio-dev-admin(a)music.columbia.edu
[mailto:linux-audio-dev-admin@music.columbia.edu]On Behalf Of
linux-audio-dev-request(a)music.columbia.edu
Sent: Saturday, July 27, 2002 9:00 AM
To: linux-audio-dev(a)music.columbia.edu
Subject: linux-audio-dev digest, Vol 1 #127 - 2 msgs
Send linux-audio-dev mailing list submissions to
linux-audio-dev(a)music.columbia.edu
To subscribe or unsubscribe via the World Wide Web, visit
http://music.columbia.edu/mailman/listinfo/linux-audio-dev
or, via email, send a message with subject or body 'help' to
linux-audio-dev-request(a)music.columbia.edu
You can reach the person managing the list at
linux-audio-dev-admin(a)music.columbia.edu
When replying, please edit your Subject line so it is more specific
than "Re: Contents of linux-audio-dev digest..."
Today's Topics:
1. Re: runtime / compiletime processing proof of concept (Paul Winkler)
2. Re: runtime / compiletime processing proof of concept (Juan Linietsky)
--__--__--
Message: 1
Date: Fri, 26 Jul 2002 13:00:10 -0400
From: Paul Winkler <pw_lists(a)slinkp.com>
To: linux-audio-dev(a)music.columbia.edu
Subject: Re: [linux-audio-dev] runtime / compiletime processing proof of
concept
Reply-To: linux-audio-dev(a)music.columbia.edu
On Fri, Jul 26, 2002 at 01:21:46PM +0200, Maarten de Boer wrote:
> Hello,
>
> Juan Linietsky (reduz on #lad) talked on #lad about an idea of
> Benno to have processing graphs generate source code, compile
> it on the fly, thus taking advantage of all compiled optimizations,
> as an alternative to runtime processing. Especially for sample
> based processing instead of block based processing this can be
> very useful and a lot faster.
John Lazarro tells me that sfront does something similar.
He says it's described here:
http://www.cs.berkeley.edu/~lazzaro/sa/pubs/pdf/wemp01.pdf
--PW
--__--__--
Message: 2
Date: Fri, 26 Jul 2002 14:38:40 -0300
From: Juan Linietsky <coding(a)reduz.com.ar>
To: linux-audio-dev(a)music.columbia.edu
Subject: Re: [linux-audio-dev] runtime / compiletime processing proof of
concept
Organization: Codenix
Reply-To: linux-audio-dev(a)music.columbia.edu
On Fri, 26 Jul 2002 13:56:55 +0200
Maarten de Boer <mdeboer(a)iua.upf.es> wrote:
>
> What i forgot to mention:
>
> The most interesting thing is that the code used for runtime, and
> the generated code used for on the fly compilation is actually the
> same! Which ensures that the result of runtime execution and
> compiling generated code -> execution is the same, and everything
> has to be written only once.
>
> maarten
>
Hi! Thanks for taking the time of writing a proof of concept program.
So far from what i've been reading it seems ok (didnt have much time
to check the entire code in detail) althought the real
advantage of compiling such graphs is when they are very large and
stack/buffer and indirection operations start to really slow it down.
Still, even whith this, i get (please tell me if these are correct):
realtime code: (./main)
real 0m1.005s
user 0m0.970s
sys 0m0.030s
runtime code: (./gen)
real 0m0.435s
user 0m0.370s
sys 0m0.060s
three seems to be quite a difference!
Juan Linietsky
--__--__--
_______________________________________________________
linux-audio-dev Mailing List Digest
http://music.columbia.edu/mailman/listinfo/linux-audio-dev
End of linux-audio-dev Digest
> -----Original Message-----
> From: Josh Green [mailto:jgreen@users.sourceforge.net]
>
>
> On Thu, 2002-10-31 at 19:09, Benno Senoner wrote:
> > Perhaps old news but I saw these interesting USB MIDI
> master keyboards
> >
> > http://www.harmony-central.com/Newp/2002/PCR-30-PCR-50.html
> >
> > I'm considering getting one so my questions are:
> >
> > - What's the status of USB MIDI on Linux ? Are such kind of
> keyboards fully
> > supported ? (eg transmit all the params as midi events or
> use special USB
> > message)
> >
> > - what kind of Note-on MIDI latency do these keyboards have ?
> > (standard midi keyboards 1.1msec)
> >
> > thanks,
> > Benno
> >
>
> New news to me! I was thinking of getting an Oxygen 8 for use with my
> laptop but was bummed about it not having a MIDI input or pedal
> controls. Both of which I see are included with those 2
> keyboards. Looks
> like I'll be getting one of those if they work in Linux of course :)
the specs say they have midi in/out (in addition to usb) so they should
work with linux, right?
quote:
"MIDI Interface (in/out), USB Interface"
erik
http://plugin.org.uk/releases/0.3.0/
Includes the most often requested thing, compressors.
SC1 - mono in, mono out variable knee compressor
SC2 - mono in, mono out variable knee compressor w/ permenantly wired
sidechain.
SC3 - stereo in, stereo out etc. with selectable sidechain.
Many thanks to Mark K. for extensivly testing the algorithm.
There are also a couple of new, very low level plugins, quality
improvements on the gong and plate reverb, serious speed improvements on
the valve plugin, and noticable, but not stunning improvements to various
other things.
Oh, and I finally fixed the prefix stuff in the configure.in. Its still
broken for MacOS X, and I no long have access to a box, so if anyone
fancies fixing the autoconf I can point you in the right direction.
- Steve
Perhaps old news but I saw these interesting USB MIDI master keyboards
http://www.harmony-central.com/Newp/2002/PCR-30-PCR-50.html
I'm considering getting one so my questions are:
- What's the status of USB MIDI on Linux ? Are such kind of keyboards fully
supported ? (eg transmit all the params as midi events or use special USB
message)
- what kind of Note-on MIDI latency do these keyboards have ?
(standard midi keyboards 1.1msec)
thanks,
Benno
---
http://linuxsampler.sourceforge.net
Building a professional grade software sampler for Linux.
Please help us designing and developing it.
linux-audio-dev'ers,
I am working in an Operations Center where we want to record 16-20 separate
analog audio voice nets/channels along with a few ethernet-based
display-data(not video) streams and play them all back individually,
selectively or all together for training purposes.
The audio nets are better than phone-quality, but not hi-fidelity and 22Khz
sampling should be sufficient. There are many turnkey voice-loggers and
pc-based "studio" applications but I need the audio recordings
closely-coupled with my own recordings of display-net data. I won't be doing
a lot of audio processing and would consider a higher rate system with
signal processing on board if it just works multi-channels well under Linux.
I suppose a multi-channel digital audio I/O board would be just fine as long
as I can get 16-20 analog channels converted up front. I am proposing
developing this application under Linux but need suggestions on the most
viable multi-channel audio in/out boards for use under Linux.
Any suggestions ?
Thanks !
Dave.
> >It would be more efficient to just calculate the corect chebyshev in
> >realtime, the problem is that they have lienar CPU cost with the number of
> >harmonics, 20 harmonics for example will be pretty expensive.
>
> there's one problem i see: if we employ a chebyshev, it is going
> to create harmonics no matter what amplitude our incoming signal
> [...]
> it seems hard to come up with a wave shaper that favours higher
> harmonics,[...]
I have only been skimming this discussion, but these caught my eye,
and I'm wondering what you mean by "chebychev" here. If you're
driving a sum Chebychev polynomials with the original signal, none of
these statements is necessarily correct -- you can preload a table
with the polynomials, so the computational load can be unrelated to the
harmonic content; the content will depend on the input amplitude; high
harmonics are easy -- just emphasize the relevant polynomial --
probably I don't know what you're talking about.
My brother pointed this out to me... The Agnula project was supposed to
have a November release. But neither he nor I are able to connect to
their Web server, http://www.agnula.org/. It resolves to the IP address
62.94.60.107 for me but doesn't connect. Is this a technical problem or
is this project dead?
=====
-- kwconder at yahoo dot com
__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/