Linux-audio-dev October 2002

linux-audio-dev@lists.linuxaudio.org

115 participants
142 discussions

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

by Patrick Shirkey

>> That said, I think Patrick is right to start thinking about this now. Thanks. >I think he's completely right - I'm not sure about this bank account >thing but I do think that now is the time to be demoing, talking up and >generally approaching people and companies about Linux music software. >I wrote us up (and mentioned a few other apps) in the latest edition of >Linux User - John at mstation.org has been very kind so far as well. >Now is the right time to be talking to people and getting the >"products" out there. If it works - why not tell people about it? The reason I believe we need to have various bank accounts are because we cannot afford to waste money on excessive service charges and not everyone has access to credit cards. If we have the accounts in the right countries then people can just donate cash. From a professional perspective we need to show our prospective clients that we have sound financial thinking. It's mostly a subconscious need that consumers have. They want to know that the money they are investing is being given to people/companies/organisations who use it. Most people don't really care how it is used although we have the moral justification on our side too. This is from the Sound on Sound advertising package. "The main target market of Sound On Sound is the professional and semi-professional musician who is the kind of person that will have the spending ability to purchase a large range of products from synthesizers to samplers, mixing desks to microphones, multitracks to monitors, effects to expanders and computer hardware and software. They are not time wasters who do not know their profession - they are serious and mature individuals working with a reasonable budget." If we want to appeal to this audience we need to prove to them that they are investing in professional audio. We need to wine them and dine them (metaphorically). If they look into our commmunity and say these are just amateur geeks who have made some interesting things happen it won't work. If we take the intiative and lead them into our world they will come at it from the perspective that we are professionals who have created a very credible concept that we are proud of and want them to enjoy using. They will ask "What kind of cash have we invested" and if we come back with "Ahh, well we don't actually have a scope on the financial side of our open community." They are just going to look around for a while and leave. If we can show them that not only are we mathematics and logics wizards but that we also have solid business sense then they are going to stick around and see what we have to offer. A lot of them will probably invest just to test the waters or to keep up with the play. I want to see an advertising campaign happen that will educate and encourage the mass of potential user to take the step. I also want to make sure that we have covered our asses when they finally walk in through the doors. It's a choice between being amatuer enthusiasts or professionals. If we come across as professionals people won't give a toss about geekyness. -- 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, 5 months

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

by Patrick Shirkey

Len wrote: >> >If you will be making money from a Linux-based product, then you >> >*should* be investing your own money for promotion. >> >> I am. What's your point? >Other people (people who are not in business) need not and likely won't >invest money to promote Linux Audio. >People here invest their time and effort (but usually not money for >promotion), mostly because they're techies who want to to build >something that they really need/want. Businesses invest money for >another reason, because they want to develop and promote commercial >products. They're mostly two different worlds (though there is >crossover). Would you agree that the commercial side of Linux Audio development is not currently showing much support for the community then? Would you consider it to be partly (if not largely) because there is an image problem. >> I have a small business and there are others out there in similar >> positions. We don't have the financial resources to fund large scale >>ad campaigns on our own. But we do if we work together. >Perhaps there's no need to promote Linux Audio; perhaps instead there >is a need to promote useful products. If those products happen to need >Linux (and ALSA & Jack) as a foundation, then Linux will get promoted >as a side effect of successful products. Much like MacOS. >So if you want Linux Audio to be promoted, either make broadly useful >products or assist the companies that want to turn your work into >broadly useful products. Are you making an offer? ;) While trawling then net today looking at the google search on the word "sound". I saw your site was listed in the first few pages. That's some tough competition there. If we had a community run organisation that lead by example do you think it would make you feel more motivated to promote Linux as a platform to your customers? Esp. If you could show them that your company has an active part in supporting the community? Eg. Official status in the form of certification or advertising space, naming rights, awards in your honour... BTW. Would you like to add your Company to the Tech Support database? http://www.djcj.org -- 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] Interesting USB MIDI master keyboards, do the work with Linux ?

by Benno Senoner

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.

21 years, 11 months

[linux-audio-dev] Viable multi-channel audio I/O boards for Linux ?

by Greene, David L.

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.

21 years, 11 months

[linux-audio-dev] Re: chebychev

by Bill Schottstaedt

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

21 years, 11 months

[linux-audio-dev] Re: recognition, sort of (Paul Davis)

by RonKuper＠Cakewalk.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

21 years, 11 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> > > 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, 11 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, 11 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, 11 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, 11 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 October 2002