Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7513 discussions

[linux-audio-dev] Additional LADSPA hints

by Steve Harris

There have been a few suggestions recently, I'l try to summarise them for comment. MOMENTARY. A hint to suggest that a control should behave like a momentary switch, eg. on for as long as the user holds down the key/mouse button/whatever. Useful for reset or sync controls for example. Would be useful in the DJ flanger. Only applies to TOGGLED controls. AUDIO_RATE_CONTROL. Hints than an audio control should/could be controlled by a high time res. slider or control data, but shouldn't be connected to the next audio signal by default. I can't think of any simple examples off hand, but combined with MOMENTARY it could be used for sample accurate tempo tapping. RANDOMISABLE. Hints that its useful/meaningful to randomise the port if the user hits a button. This is useful for the steps of control sequencers, reverbs, and just about anything that's complex. Allows you to specify which controls can be randomised without anything too supprising happening to the user (eg. sudden +100dB gain would be unpleasent). -- My comments: I really like MOMENTARY and RANDOMISABLE. AUDIO_RATE_CONTROL could be useful, but might be painful for hosts to implement. I dont have any particular use for it right now. - Steve

22 years, 7 months

[linux-audio-dev] Paul D's midi++

by Anthony

Hi, I've been exploring Paul D's midi++ library. I'm trying to compile a test driver roughly equivalent to the miditrace which is provided. Compilation goes fine, but linking is a problem. I get: midi++/libmidipp.a(fd_midiport.o)(.text+0x557): In function `MIDI::FD_MidiPort::list_devices()': /home/avan/src/ardour-cvs/libs/midi++/fd_midiport.cc:95: undefined reference to `PathScanner::operator()(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, bool, long)' So FD_MidiPort::list_devices () has { PathScanner scanner; return scanner (*midi_dirpath, *midi_filename_pattern, false, true); } The first two arguments are strings. The PathScanner is part of libpbd and has the overloaded operator: vector<string *> *operator() (const string &dirpath, const string &regexp, bool match_fullpath = true, bool return_fullpath = true, long limit = -1); which AFAICT should match the call in list_devices(). I'm using gcc (GCC) 3.2.1 20021207 (Gentoo Linux 3.2.1-20021207) and I suspect this may be the problem. Any help would be appreciated. --ant

22 years, 7 months

RE: [linux-audio-dev] Linux Audio Hardware Selection

by Marc Titinger

Hi all, I was looking for a good, up-to-date documentation pointer upon software features provided by alsa. But I'm new to this architecture and I might be "intoxicated" by some kernel streaming architectures : is there a kind of hardware abstraction with ALSA, e.g. features that are managed by the software at usr or kernel level, in a +/-transparent way, when the HW does not provide them ? My understanding is that Alsa does not provide multiple device open (a second open can be blocking, or return with an error, but won't succeed, as no sw mixing is available). is there anything that can be emulated by alsa on user request, when the hw cannot ? (for instance frequency change, frame conversion (n channels to m channels) etc...). How would you implement such thing ? With a kind of abstraction layer daemon, that exports the same api but perform missing hw features ? Could the LADSPA plugin architecture be a solution to implement multiple device open ? tx Marc.

22 years, 7 months

[linux-audio-dev] amp simulator

by Vishal

Hi all, I happen to be both a linux programmer and a guitar freak. Off late the guitar industry has seen these amp simulators some into being: line6 POD, Vamp and the likes... i was wondering whether i could build my own such amp simulator. Could anyone out here suggest me how i can do this...i mean how do i model amps...the algorithms...any info?? thanks in advance. regards, vishal

22 years, 7 months

[linux-audio-dev] New relase of ZynAddSubFX (1.0.5)

by Nasca Paul

Hi. Today I relased ZynAddSubFX 1.0.5. It is a powerfull software synthesizer for Linux. News: - The bug that crashed ZynAddSubFX if you change some effect parameters, it is realy removed (I forgot to update the file before upload) - Other bugfixes and code clean-ups - Added a Global Filter to SubSynth - Added keyresponse limits to Part - Added presets to Effects - The fade is smaller on high frequecy content and larger on low frequecies; so you'll don't hear starting clicks on basses and audible fadeins on higher pitched sounds - Added tunnings to Reverb: you can choose Random of Freeverb If you do something interesting with ZynAddSubFX (nice instruments, for example), please send me parameter files(master settings - *.mas_zyn or instruments - *.ins_zyn or banks) and (perhaps) midi files. You can download it at: http://zynaddsubfx.sourceforge.net or http://sourceforge.net/projects/zynaddsubfx __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

22 years, 7 months

[linux-audio-dev] Linux Audio Hardware Selection

by Matt Gerassimoff

Hello, I've been watching the mail on this list for some time. I've looked at as much documentation on the web as I can find. From alsa's web site to the linux audio developers web site. What I would like to know (or see in a FAQ or HOWTO) is how to setup a linux pro audio system. With different levels of price/performance issues. Things like: sound cards necessary external equipment (amplifiers/interfaces) speaker systems cpu cases with low sound midi interfaces usb interfaces dat interfaces I'm pretty savvy when it comes to computer hardware but the audio hardware is where I'm lacking knowledge. Currently I have a Korg Triton keyboard and a SoundBlaster Live! card. I'm looking at upgrading to a more professional quality setup to handle: multi-track recording/mastering realtime synthesis audio sound/music development/programming possibly portable (19" rack mounted stuff) for live performance I've seen discussions on Digital Audio cards like the RMU Hammerfall and Digi series and the MidiMan Delta series. Some have S/PDIF interfaces and other digital interfaces. What and how do connect to these? What equipment is necessary/recommended? How do you choose one card from the other? Is there a good web page to find this information? Should there be one? A nice page describing various setups for different levels of pro to semi-pro audio systems would be handy. What do you guys suggest? Thanks, Matt Gerassimoff

22 years, 7 months

Re: [linux-audio-dev] MMA membership (rambling reply)

by Patrick Shirkey

>AFAIK no LA-based recording or post-production studio is using Linux on >a daily basis. We need to score a win similar to the Linux wins in the >film industry. A hit song made with Linux software would certainly do >the trick (not that I'm a fan of popular music, but it is the big >market/money that counts for the pro-audio guys). I don't know if that's so true actually. The big movies that use technology designed on top of Linux have to sync their audio somehow. If they are doing all the rendering and post production in Linux envs then they must have some very powerful audio functionality in the apps they use. >I'm reminded of Paul's observation of how small the industry >really is. Considering the narrowness of the market I'd wonder why the >major manufacturers would do anything that might put the jinx on their >cash flow. Because they may not like having to work in the paradigm that has been forced on them. It could actually be that these companies actually do care about their community and resent having to work against the natural flow of the universe in order to put food on their plates. I'm not sure. How many of the developers who contributed significantly to the current selection of professional audio software did it because they love the results of their work and how many did it because they want the cash? In the ideal world we make money from doing what we enjoy. I would like to think that the people creating for musicians have more of a solid grasp of that ideal. I don't like to think that the industry as it currently functions has been created by money hungry musos catering to the pop market. If that is the case then maybe I don't want to use these products that they want to sell me and they should stay the hell away from open source for fear of turning to dust ;) -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== Being on stage with the band in front of crowds shouting, "Get off! No! We want normal music!", I think that was more like acting than anything I've ever done. Goldie, 8 Nov, 2002 The Scotsman

22 years, 7 months

Re: [linux-audio-dev] RE: MMA memebership [was XAP: Some thoughts on control ramping]

by Patrick Shirkey

Ron Kruper said: >The MMA is a trade association, akin to a standards body like the AES. >Do you also object to the fact that AES, IEEE, etc, charge membership >dues, and that they too hold evolving standards discussions for members >only? How does the fact that this happens to be _software_ standard >mandate that dues be waived? I wasn't suggesting that dues be waved but that they may not be neccessary. Paul makes a point in terms of anittrust legal fees but surely the lgpl solves that problem. >This isn't about being for or against open source, or a lack of >understanding. This is about recognizing that developing and supporting >a standard requires legal work, marketing, publications, etc, and that >these cost money. Call it "old economy" if you must, but if you want to >interoperate with the major companies in the industry, the MMA is forum >where they gather, and the MMA has a cost structure associated with it. Where's the legal work involved in applying for example the lgpl to this standard? Sure there is investment in the marketing and publications side of things. We all know that the mass market needs it's eye candy. But there should be very little legal fees associated with a truely open standard. If companies need to purchase the documents and specs to feel that it is worth something then they should be the ones paying for the goods. However I don't won't to appear negative towards the workings of the MMA. I want to suggest that the open source community has been working in the direction you are heading for a while and that maybe the MMA should be looking into why it is working so well. Which is possibly the same reason you are here now. Linux has proven to be the perfect medium for hardware manufacturers to get an equal footing. The truely large corporations are investing big bucks into GNU/Linux because of this. It makes sense that any professional who makes their business around computer technology would want to be here too. >IMO the *worst* possible scenario is that the commercial companies >(many of whom are a one man show) decide that they want to join the >MMA, while a sizeable group of others decide to persue a parallel >effort. That gives us 2 standards, and nobody wins. I'm sure everyone agress this is definitely something we don't want. The developers who created the current music software industry must have felt the crush when PC's first arrived, well it's happening again but this time it's not forcing you into a proprietry business model. This time you actually have a choice. Anyways, it's good to see you and others like yourself arriving here. -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== Being on stage with the band in front of crowds shouting, "Get off! No! We want normal music!", I think that was more like acting than anything I've ever done. Goldie, 8 Nov, 2002 The Scotsman

22 years, 7 months

[linux-audio-dev] RE: MMA memebership [was XAP: Some thoughts on control ramping]

by RonKuper＠Cakewalk.com

>>> Can you explain to us exactely what the MMA is offering in exchange of this money? ... What protection does the MMA provides? <<< MMA provides anti-trust protection. If the major commercial vendors go off in private and work in collusion to influence consumer choice, that is an illegal trust. The trade association gives us a forum to talk among each other, and *everyone* in the industry, with legal protection. >>> I can understand why steinberg and emagic (for example) would prefer to hide a standard war behind closed doors instead of on a public mailling list. <<< Mainly because companies act differently and say different things when they know customers might be watching. Reality of business. -Ron

22 years, 7 months

[linux-audio-dev] RE: MMA memebership [was XAP: Some thoughts on control ramping]

by RonKuper＠Cakewalk.com

>>> In this context it's seems a little ridiculous that the MMA is requiring members of the mailing list to sign on with $450. <<< The MMA is a trade association, akin to a standards body like the AES. Do you also object to the fact that AES, IEEE, etc, charge membership dues, and that they too hold evolving standards discussions for members only? How does the fact that this happens to be _software_ standard mandate that dues be waived? >>> Applying closed methods of communication, or at least requiring a sum of money to be paid to have discussion rights is the equivalent of telling us Open Source developers that either you don't understand what we are doing and why or you totally disagree with the paradigm we work in. <<< This isn't about being for or against open source, or a lack of understanding. This is about recognizing that developing and supporting a standard requires legal work, marketing, publications, etc, and that these cost money. Call it "old economy" if you must, but if you want to interoperate with the major companies in the industry, the MMA is forum where they gather, and the MMA has a cost structure associated with it. Also, the plan is for this process to not be completely closed. We're working on a process whose openness is new to the MMA, but similar in nature to other standards organizations. The current plan is to have 4 phases: [1] Requirements gathering. This will be open to any developer who wants to register on an email reflector. This phase will start as early as next week, and will last several months, I suspect. [2] Design. This will be open to MMA members only. If you want the legal protection that the MMA provides, and you want somebody else to pay for "stewardship" of the spec, then it's worth joining. Even some open-source developers sell products, and those who do will recoup their cost after selling a very small number of units. [3] Review. This will be public like phase 1. We'll probably have several iterations of 2 and 3. [4] Adoption. Once again, private to MMA members only. IMO the *worst* possible scenario is that the commercial companies (many of whom are a one man show) decide that they want to join the MMA, while a sizeable group of others decide to persue a parallel effort. That gives us 2 standards, and nobody wins. -Ron

22 years, 7 months

Jump to page:

2025

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