Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7439 discussions

Re: [linux-audio-dev] I think that what he means is even more important than recognition...

by John Lazzaro

> 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 -------------------------------------------------------------------------

21 years, 10 months

Re: [linux-audio-dev] I think that what he means is even more important than recognition...

by John 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 -------------------------------------------------------------------------

21 years, 10 months

[linux-audio-dev] recognition, sort of

by Paul Davis

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

21 years, 10 months

[linux-audio-dev] console JACK metering using ecasignalview

by Kai Vehmanen

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!

21 years, 10 months

[linux-audio-dev] [ANN] TiMidity++ now on sourceforge

by Takashi Iwai

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

21 years, 10 months

Re: [linux-audio-dev] Free Publicity - DJCJ Linux Audio Developers Tech Support Database.

by Patrick Shirkey

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.com Http://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

21 years, 10 months

[linux-audio-dev] [ann] unmatched - a LADSPA amp tone

by Tim Goetze

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

21 years, 10 months

[linux-audio-dev] LinuxSampler project back, seeking for developers, volounteers and enthusiasts !

by Benno Senoner

As promised, I'd like to revive the linux audio sampler I was working on about 2 years ago. I was forced to take a long pause (almost 2 years) from LAD stuff because I had to finish my CS degree before the retirement age. But speaking speaking with various developers on LAD there seems big interest for a high quality software sampler for Linux, especially one that can play samples from disk since there are now many huge sample libraries out that only work with samplers that can stream. (Halion, GIG). As some of you probably remember at that time, I wrote some proof-of-concept code that demonstrate that it is possibile to achieve sub-5msec latencies while streaming samples from disk under Linux given a lowlat enabled kernel. But my (and other's) vision is to write a sampler that is both efficient and offers flexible modulation and routing plus that it can interact with jack and other audio/midi sw present in your linux virtual studio setup. I was toying with the idea of using some sort of recompilation techniques where the user can graphically design the sampler's signal flow (routing, modulation, FXes etc) which in turns get translated into C code that get loaded as a .so file and executed within the sampler's main app. This would make up for a very flexible engine while retaining most of the speed of hard coded ones. I have set up a site and a mailinglist for the sampler at http://linuxsampler.sourceforge.net Without the help of all you LAD geniuses LinuxSampler will not become the sampler I (and others) have in mind, so if you are interested to contribute code, ideas, designs or want to give advices because you have lots of experience with hardware samplers or windows/mac applications, with the please subscribe to the linuxsampler-devel mailing list at: http://lists.sourceforge.net/lists/listinfo/linuxsampler-devel Since LinuxSampler will support JACK from the beginning, I hope that the jack core members sign up to the mailing list too in order to solve issues related to jack more quickly. PS: I suggest to go into planning mode for a while in order to sort out things a bit and lay out an elegant design concept in order to avoid the usual spaghetti code projects. thoughts ? cheers, Benno http://www.linuxaudiodev.org The Home Of Linux Audio Development

21 years, 10 months

RE: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] hel p for a levelmeter]

by STEFFL, ERIK (SBCSI)

> -----Original Message----- > From: Patrick Shirkey [mailto:pshirkey@boosthardware.com] > > >IMO it would be much better if the link to details about > the card would > >not say "Install' but instead indicate that details about > the card can > >be found there (alsa soundcard matrix), I mean the column is named > >appropriately drivers&docs but the item in column is always > 'Install'. > >It has mostly install info but also module options, known bugs etc. > > But it's hard to think of another word that is more appropriate. > > I think that for many people once they have found the link for their > card they will bookmark that and use the matrix very rarely > after. Once > that is done the Matrix becomes near meaningless to an average user. > > For people who haven't found the page yet they are most > likely looking > for instructions about how to install the card. So INSTALL seems very > appropriate there. > > However if people only want information about a prospective > card it is a > different story. In that case a different word could be more > instructive. It would be nice to find the right one :) IMO it would be better if it would say something like "more info", "docs", "details" etc. I also think that it would be very useful to have more info for prospective buyers because at this point it is basically impossible to find out which soundcard to buy. I am not saying you should do something about it right now, but I hope you'll think about it:-) erik

21 years, 10 months

RE: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] hel p for a levelmeter]

by Patrick Shirkey

>IMO it would be much better if the link to details about the card would >not say "Install' but instead indicate that details about the card can >be found there (alsa soundcard matrix), I mean the column is named >appropriately drivers&docs but the item in column is always 'Install'. >It has mostly install info but also module options, known bugs etc. But it's hard to think of another word that is more appropriate. I think that for many people once they have found the link for their card they will bookmark that and use the matrix very rarely after. Once that is done the Matrix becomes near meaningless to an average user. For people who haven't found the page yet they are most likely looking for instructions about how to install the card. So INSTALL seems very appropriate there. However if people only want information about a prospective card it is a different story. In that case a different word could be more instructive. It would be nice to find the right one :) -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://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

21 years, 10 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev