> >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/
Paul Davis wrote:
> Whoa! Someone's paying attention! We love you Ron! When can we get
> Sonar on Linux? :))
Hey, thanks! I actually only subscribed to this list about a week ago...
trying to keep on top what's going on in the world.
When can I get some Linux plugs on Windows? :-) (Had to say that...)
-Ron
> Paul Davis <paul(a)linuxaudiosystems.com>
>
> at what point do you expect Digidesign TDM plugins
> to fall by the wayside?
DigiDesign may be the special case here, assuming that
Avid stays independent -- the ProTools business model
offers them refuge from consolidation forces, being
hardware-restricted and embraced by the high end.
Avid's market cap is 370M -- an order of magnitude
higher than what Apple paid for Emagic, but still
digestable for the likely suitors (Microsoft and
Adobe). I use "likely" as a relative term -- the
hardware-centric nature of Avid makes it an
unnatural fit for both of those companies ...
-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
> Paul Davis <paul(a)linuxaudiosystems.com> writes:
>
> its finally dawning on some people that whatever
> benefits specific plugin APIs bring to particular products and
> hardware, the proliferation of them is actually *more* harmful. i am
> skeptical that anyone in the commercial side of things really has the
> will to do anything about this, even though they may say they do.
Watching the Apple Emagic acquisition, followed by news that Logic
would transition to AudioUnits, followed by a mass influx of new
AudioUnits developers into the coreaudio-api list, was very
enlightening. The economics of commercial plug-in development
is such that once Apple owned Logic and made its intentions clear,
developers could not help but be interested in supporting the
plug-in architecture.
There's a natural follow-on move here -- Microsoft buying one or
more of the PC flagship applications, and moving them all to
support one new or existing standard, that Microsoft licenses
freely to all comers (with an anti-GPL poison pill). Then we're
back to familiar territory, Microsoft owning one way to
do it, Apple owning a second way to do it, and everyone else
supporting one or both. The natural reason to expect this not
to happen is the small absolute size of the audio content market
to a company like Microsoft. However, strategic issues may come
into play in Redmond to make this happen --
-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
Ron Kuper, VP of Engineering at Cakewalk writes, on vst-plugins:
----------------------------------------------------------------------
That said, we would welcome any effort to unify
VST/DirectX/DMO/OPT/MFX/ReWire/TDM/RTAS/MAS/AU/JACK/LADSPA/... ad-infinitum
into a single cross-platform plugin API, developed and maintained by an
appropriate trade organization or standards group. The proliferation of
incompatible standards makes VHS vs. Betamax look like child's play. Our
industry needs to unite on this point for more reasons than I can list here.
----------------------------------------------------------------------
Whoa! Someone's paying attention! We love you Ron! When can we get
Sonar on Linux? :))
--p
Hi,
yesterday I released ecasound-2.2.0-pre4 (approaching
next stable release, yay!), which has a few JACK-specific
improvements:
- new command-line syntax for specifying inputs and
outputs, see:
http://www.wakkanet.fi/~kaiv/ecasound/Documentation/users_guide/html_uguide…
- uses the new alsa_pcm:capture_x + playback_X syntax
(requires JACK 0.40 or newer ==> CVS!)
You can find the package at:
http://ecasound.seul.org/download/ecasound-2.2.0-pre4.tar.gz
And now to the main point: 2.2.0-pre4 comes with an updated
version of ecasignalview. Combined with the new JACK syntax,
ecasignalview now suits quite well for monitoring JACK-clients.
The basic syntax is:
ecasignalview -b:XXX -f:32,YYY,ZZZ jack_auto,foo_client null
... where:
XXX = buffersize (jackd's -p:XXX)
YYY = number of channels you want to monitor
ZZZ = sample rate (jackd's -r:ZZZ)
foo_client = any JACK client which uses out_X
style port names
The meters are drawn with ncurses, while values are queried
through the ECI API (ie. ecasignalview is only linked
against libc and libstdc++, not for instance against
libjack). The output looks like:
http://eca.cx/screenshots/ecasound-2.2.0-pre4_ecasignalview.png
... there are a few known bugs, but in general it works
quite well. While not really a huge challenge for Steve's
meterbridge ;), should be of interest to some of you.
--
http://www.eca.cx
Audio software for Linux!
Hi,
the development tree of the latest TiMidity++ was moved onto
sourceforge now.
http://sourceforge.net/projects/timidity/
there is a cvs branch, "R2_12_0_pre1b", which includes bunch of
enhancement patches. the patches sent on the timidity developer ML
(in japanese) are (occasionally) sync'ed with this tree.
also, an english mailling list was opened for non-japanese-speaking
developers and users:
http://lists.sourceforge.net/mailman/listinfo/timidity-talk
hope many people have interest and join to this project.
ciao,
Takashi
Thanks for all the helpful feedback.I have updated the main page for the
djcj site. I have tried to compromise as much as possible.
I also found an annoying bug in the Technical support database which was
dropping some of the variables before they were inserted and added a
table for notes in case you want to be specific about things :)
The database is now working properly again. For those of you who
submitted info but did not see yourself appear you can either resubmit
and I will clean up by hand or you can wait for a couple of weeks until
we have the login scripts working.
Any suggestions for the wording on the page to make it more
representative are appreciated. I want the database to be accesible to
anyone who can provide professional support in any way shape or form for
Linux Audio.
http://www.djcj.org
Best regards.
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.comHttp://www.djcj.org - The Linux Audio Users guide
========================================
"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem
pleased to announce the release of 'unmatched'.
'unmatched' is a simple effort to recreate some aspects of
the tone shaping of a real instrument amplifier. unlike
classical convolution techniques, it uses an IIR filter
to emulate an original impulse response, trading impulse
response fidelity for execution speed. it will easily
allow realtime setups combining compression, reverb and
other cpu-bound effects even on an aged system.
http://quitte.de/unmatched.html has the rationale and
implementation (GPL).
tim