RE: [linux-audio-dev] Poll about linux music audio app usability
-Original Message- From: David Olofson [mailto:[EMAIL PROTECTED]] ... That said, the XMMS/WinAmp model *is* in fact of the first kind I mention above; GUIs with custom graphics. A skin for such an application is basically just a set of images that replace the original custom graphics. ... freeamp is the application that has IMO good implementation of such a model, xmms/winamp are IMO sucky (in this area) - the biggest usage problem being that it's always the same size (too small for my taste) [and, of course, all the skins look basically same:-)] what I don't like about it is that all it provides is superficial change of look - all the items (buttons etc.) are in the same places (and of course, they are all the same buttons with same functionality) - very shallow and useless - basically a hint of what can be done. freeamp allows you to specify bitmaps of arbitrary size/shape for gui elements and place them where you want (there's an xml file that specifies the GUI), you can omit the GUI elements you don't need/want in particular skin etc. - that makes it possible to really make a difference - e.g. you can create a skin that would make it easy to dock/swallow it in some launch pad/task bar/whatever (e.g. small play/stop and volume controls) or you can create a big full screen art work that also serves as mp3 player etc... erik
RE: [linux-audio-dev] Poll about linux music audio app usability
-Original Message- From: David Olofson [mailto:[EMAIL PROTECTED]] ... However, there's one thing that's seriously worrying me: Software piracy. I saw a poll somewhere, that indicated that a vast *majority* of computer users considered piracy more or less OK. It's like they simply don't consider it a crime at all. What this means to us is that we're effectively competing with high end professional software *ON EQUAL TERMS*! Actually, worse than equal terms: They make money, while we do not. * Most of these users couldn't care less about Open Source (if they even know what it's about), so that's not an advantage for us. * Most of them don't give a damn about paying for the software they use anyway, so we have no advantage there either. As to true professionals, I believe a large portion of them don't have a real problem with paying for good software - and either way, they'll just pay what it costs to get a sufficient solution. Doesn't matter if it's free, Free/Open Source or whatever, if it doesn't quite cut it. obviously, it has to be better. I think you can make the same argument in all other areas where opensource software is used and IMO it will be successfull in multimedia apps for the same reason it is successfull in other areas - the user is in control. that's what everybody likes - from joe to disney (they are switching to linux, you would think the big corp like them can afford to pay for window, yet price is one of the reason they are changing, not the only one of course). the fact that it's free makes it more convenient then non-free to work with it (support!) and to get upgrades - note that apart from paying for upgrades it's usually not that easy to upgrade non-free apps (because of different mindset), even less easy when you want to pirate it (you have to a friend who has the software, get it from warez sites etc., not hard but not as easy as apt-get dist-upgrade). that said I have to admit we're not there yet, I am just trying to get soundblaster live! to record something (audio) and it just doesn't:-) but the inmportant part is that it works a lot better then it used to recently - most of the reports that I read are pleasantly outdated - most of the stuff they list as not working already works. erik
RE: [linux-audio-dev] Poll about linux music audio app usability
-Original Message- From: Joern Nettingsmeier [mailto:[EMAIL PROTECTED]] STEFFL, ERIK *Internet* (SBCSI) wrote: that said I have to admit we're not there yet, I am just trying to get soundblaster live! to record something (audio) and it just doesn't:-) assuming you use alsa, try scrolling a little to the right in alsamixer: there is another control named capture that needs a capture flag as well (not just the line or mic you're recording from). thanks, I'll try that. Is there any place where the mixer controls for SB Live! are described? It's quite hard to figure out what they are doing, some are obvious but lot of them are not - e.g. this Capture control, then there are capture controls for some of the input (e.g. there's Line LiveDrive Line LiveDrive Capture, but there's only Line LiveDrive 1 - no capture control for this one), the headphone controls (Headphone LFE 1, Headphone 1, Headphone Center 1) , LFE, etc... I've checked the live! web page, creative webpage but found no details (yet) - any pointers? erik
RE: [OT] RE: Latency [linux-audio-dev] RFC: API for audio across network - inter-host audio routing
-Original Message- From: Charles Baker [mailto:[EMAIL PROTECTED]] ... 1) Humans can and do play instruments with much worse response than the 10ms we want as minimum in out linux apps. ... most (all) naturally introduced latencies are fairly constant in time, one can get 'feel; for them. However the latency introduced by linux (computer) is not 10 ms but as you say _up_to_10_ms_, I guess the random delays would be very annoying - imagine having latency about 4ms and then suddenly jump to 10ms for few notes and then back to e.g. 3ms etc. erik
RE: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing
-Original Message- From: Lamar Owen [mailto:[EMAIL PROTECTED]] ... The idea is that you get the integrated value of the amplitude of the sine wave, since a sine wave always has the same shape. But the amplitude, at the Nyquist frequency, cannot change. Yes, I really said that. If the amplitude of the sine wave changes, you get an upper sideband above the Nyquist rate that you cannot sample -- of course you also get a lower sideband that you can sample, but then the recovered envelope is distorted. Amplitude changes at the Nyquist frequency violate Nyquist's theorem. Thus the Nyquist frequency itself is an asymptote and cannot be accurately reproduced except in the steady state. nyquist theorem doesn't say that you can get EXACT same signal if your sampling frequency is twice the highest frequencey of signal. It says (roughly) that you wouldn't miss any bumps (of frequency half of your sampling frequency), you can't be sure about the shape of those bump (amplitude). which is basically what you say, it's just that there is no violation of nyquist theorem there... erik
RE: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing
-Original Message- From: Bob Colwell [mailto:[EMAIL PROTECTED]] Sent: Friday, June 14, 2002 4:39 PM To: [EMAIL PROTECTED] Subject: RE: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing Nyquist says that if you sample a repeating waveform, ANY repeating waveform, at a sampling rate greater than or equal to the highest not sure what you mean by 'repeating', it does not have to be periodic, it just has to be continuous. frequency partial present in the waveform, you can exactly duplicate that waveform. Yes, exactly duplicate the original. in theory (i.e. not exactly, it says that you can reconstuct a continuous function) reality brings two important factors: 1) the sample we have is not of infinite length - error is introduced (see http://www.digital-recordings.com/publ/pubneq.html) - nyquist theorem is for functions (with no beginning and no end). 2) the real signals are not really limited to exactly half of sample frequency, the higher frequency (above half the sampling frequency) are 'transformed' into lower frequencies - so the frequencies that you would not hear in original sound would be in hearing range ion reconstructed signal (aliasing). (there might be other reasons why exact signal cannot ber reconstructed) I don't have time to search for it but I recall something about the 'exact' is not exactly what one would expect, something along the lines that you don't miss any frequency (when you do fourier transform) but that the signal you can reconstruct doesn't have exactly the same shape or something like that... erik Lamar's comments are correct, but then, what difference is there between amplitude modulation at the sampling frequency and a partial at that frequency? Both contain information that cannot be captured by the stated sampling frequency. Why would you amplitude modulate anything that fast? -BobC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of STEFFL, ERIK *Internet* (SBCSI) Sent: Friday, June 14, 2002 12:01 PM To: '[EMAIL PROTECTED]' Subject: RE: [linux-audio-dev] RFC: API for audio across network - inter-host audio routing -Original Message- From: Lamar Owen [mailto:[EMAIL PROTECTED]] ... The idea is that you get the integrated value of the amplitude of the sine wave, since a sine wave always has the same shape. But the amplitude, at the Nyquist frequency, cannot change. Yes, I really said that. If the amplitude of the sine wave changes, you get an upper sideband above the Nyquist rate that you cannot sample -- of course you also get a lower sideband that you can sample, but then the recovered envelope is distorted. Amplitude changes at the Nyquist frequency violate Nyquist's theorem. Thus the Nyquist frequency itself is an asymptote and cannot be accurately reproduced except in the steady state. nyquist theorem doesn't say that you can get EXACT same signal if your sampling frequency is twice the highest frequencey of signal. It says (roughly) that you wouldn't miss any bumps (of frequency half of your sampling frequency), you can't be sure about the shape of those bump (amplitude). which is basically what you say, it's just that there is no violation of nyquist theorem there... erik
RE: [linux-audio-dev] SuperClonider
-Original Message- From: James McCartney [mailto:[EMAIL PROTECTED]] On Saturday, April 27, 2002, at 02:50 PM, John Lazzaro wrote: submit the SuperCollider language to be an open standard Without taking this step, you're condemning the SC language to a lifetime limited to the practical lifetime of your implementation(s). Which of these languages has this been done for: Python Ruby Perl? I think that there is only one code tree for each of these languages. Are they condemned? those are free so their life does not end with particular person's interest in them. It's not the same as if they were strandardized though... erik application/ms-tnef
RE: [linux-audio-dev] ALSA vs OSS/free
-Original Message-
From: Paul Davis [mailto:[EMAIL PROTECTED]]
...
haven't you understood the stupidities that OSS has forced on people
because of this assumption that a program should access /dev/foo? this
works when the kernel side of /dev/foo embodies all that /dev/foo is
supposed to do. this is true for filesystems, disk drives, tape
devices and more.
but in the case of audio, linus, alan and others have made it clear
(and most of us agree with them) that they do not accept the idea that
format conversion, channel mapping, {de,re}interleaving, device
sharing (*not* h/w multiplexing) etc. should live in the kernel if at
all possible. therefore, there are really useful aspects of an audio
API that under Linux *cannot* live in the kernel. where do *you* think
they should be?
the user space device drivers are coming (not sure if there's anything in
2.5 yet).
the convention of accessing an inode that directly talks to a driver
is what stops OSS apps from being used flexibly, since nothing can
interpose between the app and the device without using
LD_PRELOAD (gack!)
except of user space device driver (once it exists:-)
I don't mean to imply anything one way or another but I think it's an
interesting twist...
erik
RE: [linux-audio-dev] LJ Firenze report
one of the presentations was for demudi (debian based multi-media distro) - I just checked their web page and it seems like the latest update was on october 2001. anybody knows more details? is the project dead? on hiatus? erik -Original Message- From: Dave Phillips [mailto:[EMAIL PROTECTED]] Greetings: Those of you who attended the event may recall that I promised to submit my notes to the Linux Journal. I did so, and never heard about it again. I mistakenly assumed that Richard rejected the article: While searching for something else I came across this URL: http://www.linuxjournal.com/article.php?sid=5355 Perhaps LJ was going through one of its periodic shuffles, but I never heard from anyone there about putting the notes on-line. Too bad they didn't publish the pictures... Best regards, == Dave Phillips The Book Of Linux Music Sound at http://www.nostarch.com/lms.htm The Linux Soundapps Site at http://sound.condorow.net
RE: [linux-audio-dev] need setup recommendations for realtime audio on linux box
-Original Message- From: Paul Davis [mailto:[EMAIL PROTECTED]] ... than 100ms requires a kernel patch. i don't know why you'd want to use 2.4.8 - the VM system is fundamentally broken until about 2.4.15 or definitely, I had quite a few problems with IIRC 2.4.5/9/10, now I am at 2.4.14 and it works much better (haven't seen any problems). erik
RE: [linux-audio-dev] Still I cannot understand why...
-Original Message- From: Ivica Bukvic [mailto:[EMAIL PROTECTED]] care != contribute According to the English dictionary, you are right. But analyzing a brick out of the buiding perspective is what gets you in trouble: if you were more sensitive to the context and realized that this discussion is being held in the Linux audio DEVELOPMENT list, it would be easy then to assume that both you and I ARE contributing to the Linux community by developing/coding. So, if you don't have anything better then providing a thesaurus to this list, please either use LAU list, or start using that free time churning code (or even better providing ports to all of your alternative OS's that you so dearly care for). please stop being ridiculous. BTW what I provided is what dictionary provides, not thesaurus. contribute: writing actual code (or docs etc.) for other platform care: picking up portable language, writing portable code, choosing libraries etc. that are available for different platform etc. (not that portability should be the only reason to choose tools, all I say is that it should be taken into account) BTW2 I mostly use intel pc, I care for other platforms for reason hinted above... Well then you surely have a lot to care for. Good luck! Designing a well implemented driver/app is one thing, while porting it is other, and as such they should be held separate. Design should always take precedence, obviously, while porting should be a project of the benefactor [at least in the non-paying world], not of provider, and as such, again should be separate. Thus, not caring for the porting part of the endeavors simply means that this should not be my priority or something I need to worry about. People who ported first audio apps to Linux (i.e. Mxv), were simply persons who HAD some interest in Linux and thus did so, regardless of OSS. Case and point: RT which is originally Paul Lansky's creation that ran on SGI and had nothing to do with OSS since SGI's audio architecture is/was way better than the OSS's -- its port was done by both Mike Peterson and Doug Scott, people who actually cared about/used Linux and worked out their own ways of porting it to Linux architecture using whatever they had at their disposal in terms of audio API). Paul Lansky, according to your messed-up view, should be then proclaimed selfish [or whatever that means for you] for not providing ported app to the Linux OS [both architectures are it might be messed up but it's not my view. please do not attribute to me views that I explicitly wrote I do not hold. I've already written few times that I don't say anybody should provide ported application. *nix, after all, right? -- even more so nowadays, since SGI is switching/ has already switched to Linux]... Quite on the contrary, my friend, Paul Lansky provided a great tool that is still being used nowadays (and should be under no circumstances called selfish for doing so), and thanks to Mike and Doug are of course. and nothing I've written implied that he should be called selfish for providing the program. he, theoretically might have been selfish in not caring about portability, but when you sum it up (providing the tool, but not caring about portability) it is still quite positive (i.e. over-all not selfish). I have already written this same thing already which makes your statement above quite surprising. we able to enjoy the same app on our favorite OS. Since you are so well versed in the usage of your thesaurus, next time be more careful in the usage of the words within the given context... don't talk non-sense. please. erik
RE: [linux-audio-dev] Hard-drives and soundcard support
-Original Message- From: Wa Ditti [mailto:[EMAIL PROTECTED]] ... is an obstacle for some PIII motherboard BIOS's which can only handle up to 32 Gigs, I don't know if there's a way to go straight to the operating system without the BIOS being involved, if there is I like to know about it, as I have 16 Gigs of storage languishing in my machine. you can disable the HD in bios but you cannot boot from it then. so you might want to get one more HD that would be recognized (smaller, I guess you can get those very cheap) and use the bigger HD as non-boot drive. I had the same problem with 60GB Matrox (but they said it straight away - if you have problems, make the disk appear smaller), luckily I still had an original 2GB HD that I used for booting. erik
RE: [linux-audio-dev] Still I cannot understand why...
-Original Message- From: Ivica Bukvic [mailto:[EMAIL PROTECTED]] that's very shortsighted. also selfish (in contrast to sharing ideas that are behind linux). I do not see it being that way since there is no way that I could, for instance, write a good Alsa port for crapple architecture when I do not even own one. I see nothing selfish or shortsighted about that, neither do I think it contrasts with the idea behind Linux. Linux never stood for selected few should write a driver for everything and everyone, while the rest of us should then just use it and complain how the implementation sucked. It stands for here's my code that works for me, hack away and port it so that it works for you and others who use architecture like you, and while doing so, ask them to help you, just as people who have architecture like me have helped me. that's not relevant to what I wrote. I don't think I wrote (or implied) that you should write a good Alsa port for crapple or that linux stands for selected few should write driver so I am quite confused why you have chosen to answer in this way. Please think about how other systems are important for linux instead, I am pretty sure you can come up with the reasons easily. erik
RE: [linux-audio-dev] Still I cannot understand why...
-Original Message- From: Ivica Bukvic [mailto:[EMAIL PROTECTED]] ... I have to completely disagree with your statement here. I could not care less for BSD, Solaris or any other flavor or *nix. I use Linux and that is all I care for. Neither do I see any similarity with Windows since I that's very shortsighted. also selfish (in contrast to sharing ideas that are behind linux). I would much rather see Alsa developers invest their time into perfecting Alsa's architecture, than use the same time for porting an API that is yet to be completed/widely used to other OS's. IMO that's reasonable approach at this point. erik
RE: [linux-audio-dev] Still I cannot understand why...
-Original Message- From: Mark Constable [mailto:[EMAIL PROTECTED]] ... Please, no more half-way compromises with OSS... kill it, do not even consider backwards compatibility for old OSS apps! Are there any worthwhile salavaging in light of newer developments ? Every ounce of effort towards maintaining (crappy) backwards compatibility for old OSS mainly/only systems takes away effort from enhancing true ALSA apps. the problem is that alsa is a moving target, it's just beginning to stabilize now (the API). At least that's what they claim. btw what is the reason for alsa to be constantly changing its API? I mean it's going on for years. erik
RE: [linux-audio-dev] [ANN] AlsaPlayer 0.99.52-cvs20011126-jack
-Original Message- From: Andy Lo-A-Foe [mailto:[EMAIL PROTECTED]] Howdy, AlsaPlayer 0.99.52-cvs20011126-jack was released on the website, http://www.alsaplayer.org just wondering - I tried alsaplayer yesterday (after long time) and I couldn't find any way to remotely control it from command line (something like xmms does - e.g. xmms -s will stop the currently playing xmms etc.). IIRC there was some sort of scripting supported in kde, is there anything similar in gnome (or more precisely gtk)? is anything like that planned? erik
RE: [linux-audio-dev] suggestion for developers: real quad-channel output on an SBlive
-Original Message- From: Josh Whiting [mailto:[EMAIL PROTECTED]] i am a list-lurker, primarily a windows multimedia user, but with an interest in audio software development and hence an interest in linux. anyway, i have and idea that has been provoked by my recent explorations into quad-channel audio output. Basically, the idea is to write a driver to interface with the SB-Live EAX bus that converts the SB live into a more-or-less 'true' four channel output device. How? 1 - setup two stereo virtual audio input ports, 2 - assign each channel a status in the EAX bus as a sound source with a specific spatial position so as to emulate the direct dispatch of each channel to its respective output in the dual-output SB live DACs. You may not even need two virtual ports, as you could probably assign the main output (sb live wave out) to the front stereo outputs and then just send the second (virtual) stereo stream to the rear outputs. and bam - the SB live is now a (low cost) four channel output device, overcoming the (idiotic, painful) limitations imposed by creative's engineering of the board only support a single stereo output even though the card has two of them... ? sb live provides 5.1 output under windows (you can set output under speakers in eax control center (headphones, two speakers, 4 speakers, 5.1 speakers), there's also a demo for that somewhere there). Not sure how it works under linux (I don't have linux installed on that computer yet). erik
RE: [linux-audio-dev] suggestion for developers: real quad-channel output on an SBlive
-Original Message- From: D. Stimits [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 21, 2001 11:17 AM To: [EMAIL PROTECTED] Subject: Re: [linux-audio-dev] suggestion for developers: real quad-channel output on an SBlive STEFFL, ERIK *Internet* (SBCSI) wrote: -Original Message- From: Josh Whiting [mailto:[EMAIL PROTECTED]] i am a list-lurker, primarily a windows multimedia user, but with an interest in audio software development and hence an interest in linux. anyway, i have and idea that has been provoked by my recent explorations into quad-channel audio output. Basically, the idea is to write a driver to interface with the SB-Live EAX bus that converts the SB live into a more-or-less 'true' four channel output device. How? 1 - setup two stereo virtual audio input ports, 2 - assign each channel a status in the EAX bus as a sound source with a specific spatial position so as to emulate the direct dispatch of each channel to its respective output in the dual-output SB live DACs. You may not even need two virtual ports, as you could probably assign the main output (sb live wave out) to the front stereo outputs and then just send the second (virtual) stereo stream to the rear outputs. and bam - the SB live is now a (low cost) four channel output device, overcoming the (idiotic, painful) limitations imposed by creative's engineering of the board only support a single stereo output even though the card has two of them... ? sb live provides 5.1 output under windows (you can set output under speakers in eax control center (headphones, two speakers, 4 speakers, 5.1 speakers), there's also a demo for that somewhere there). Not sure how it works under linux (I don't have linux installed on that computer yet). EAX is proprietary. It isn't available under Linux, and unlikely it ever will. The OpenAL code is probably the closest you'll see in the near future, but something of a similar idea could probably be used there (just not EAX). aha. but if eax can do it then there has to be hw that supports it, right? otherwise eax would be able to output 5 separate channels (and it does, even though I don't know how well separated they are). the original post was talking about more-or-less true 4 channel and I was saying that 5 channel output is possible (using sb live HW, there might be software issues involved that are not easy to solve). or are you saying that using information available to opensource developers it is not possible to use the same HW that eax uses? erik
RE: [linux-audio-dev] Re: [Alsa-user] gsmp release 0.0.1
-Original Message- From: delire [mailto:[EMAIL PROTECTED]] just trying to install GSMP on a suse 7.1 box at another studio and ./configure produces the error: cannot find STL file sstream i've never come across this before..any solutions? has all the same gtkmm / alsa / and libsigc++ libs etc as the debian box it compiled successfully on.. on a debian unstable: jojda:~locate sstream /usr/include/g++-3/sstream jojda:~dpkg -S sstream libstdc++2.10-dev: /usr/include/g++-3/sstream jojda:~ erik
RE: [linux-audio-dev] LAAGA or JACK or...(was: LADMEA revisited...)
-Original Message-
From: Paul Davis [mailto:[EMAIL PROTECTED]]
...
that's why i think JACK should be renamed to LAIC, which stands for
Linux Audio InterConnect
1) there's nothing Linux specific about it.
that's a very valid point. IMO good enough to not go with LAIC.
2) JACK = JACK Audio Connection Kit
3) Most people would have no idea how to say LAIC
why not? it's an english word, not very common one but not obscure either
(well, maybe it's not obsure to me 'cause we have the same word in slovak
[ahoj, marek]):
jojda:~dict laic
3 definitions found
From The Collaborative International Dictionary of English [gcide]:
Laic \Laic\, n.
A layman. --Bp. Morton.
[1913 Webster]
From The Collaborative International Dictionary of English [gcide]:
Laic \Laic\, Laical \Laic*al\, a. [L. laicus: cf. F.
la[i]que. See {Lay} laic.]
Of or pertaining to a layman or the laity. ``Laical
literature.'' --Lowell.
[1913 Webster]
An unprincipled, unedified, and laic rabble. --Milton.
[1913 Webster]
From WordNet (r) 1.7 [wn]:
laic
adj : concerning those not members of the clergy; set his collar
in laic rather than clerical position; the lay
ministry; the choir sings both sacred and secular
music [syn: {lay}, {secular}]
erik
RE: [linux-audio-dev] LAAGA/JACK/LAIC
-Original Message- From: David Gerard Matthews Jr. [mailto:[EMAIL PROTECTED]] Marek Peteraj wrote: 3) Most people would have no idea how to say LAIC Laic - of or relating to the laity - all those who are not members of a profession or specialized field. I think it should be a symbolic word for how LAAGA/JACK works (see above). It should not be a problem for those who speak english...But one can still visit www.webster.com, they have audio-pronunciations online :) Actually, those who speak English would have the most trouble figuring out how to pronounce LAIC, because ai doesn't have a standardized pronunciation. Is it pronounced like lake? Or is it like? Or lae -ik? Etc you can argue against quite a few english words using this argument (break-breakfast, blood-boot, great-freak etc...) laic IS english word so you cannot excuse yourself out of knowing how to pronounce it. erik
RE: STL / Qt flame-war (Re: [linux-audio-dev] Audio-related widgets with Qt ?)
regarding protability: stl is fairly new and not properly supported everywhere but it's getting better. erik -Original Message- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 9/17/01 8:30 AM Subject: Re: STL / Qt flame-war (Re: [linux-audio-dev] Audio-related widgets with Qt ?) On Mon, Sep 17, 2001 at 05:02:37PM +0200, jelle wrote: Hope i'm not getting too much off topic I just want to mention one reason why I don't like using Qt myself, not as flamebait but just to make it clear. Qt was written before the Standard Template Library (STL) was reasonably standardized. Most librarys that omit the STL tell you that it is because of portability reasons. Is this true, is STL so unportable? It is written in C++ right? So should it be easy to use the reference STL lib and use it for whatever platform that has a C++ compiler? Except for the stream io maybe? (Ofcourse optimized implementations would have system specific calls) As a result, it contains implementations for things like lists, vectors and many other container classes, that are part of the STL. For similar I guess it depends on what one is used to. I have always found STL totally painful It really isn't. It's a bit complex at start, probably because of the template use and the iterators. However, both of there are powerfull things and you should understand them both anyway (not that hard). , the headers are unreadable That is because of two reasons. a) it is a template b) all logic code (that would normally reside in a .cc file) is in the header as well since templates cannot be compiled into libraries. You shouldn't attempt to read the headers, instead buy a book such as The C++ Programming Language by Bjarne himself. It has some intense chapters on the STL which explain why and how you should use the STL. Oh, wait, read this document, it's a chapter from the mentioned book, Introduction to the standard library It's a good starter, however you really need some detailed reference material to appreciate the STL. The ease of use is in the numerous specific functions. and some of the most simple operations take enormous amounts of effort (like removing the n:th element from a list). from pg 454 of the book. ;) // remove element n from container c: c.erase( c.begin()+n ); // ok if iterator supports + // or use c.erase( c.begin().advance(n) ); You see, it's not that hard. :) cheers -- defekt
RE: STL / Qt flame-war (Re: [linux-audio-dev] Audio-related widgets with Qt ?)
but stl is not 'each new library'. stl is part of c++ standard. erik -Original Message- From: Tommi Ilmonen To: [EMAIL PROTECTED] Sent: 9/17/01 8:05 AM Subject: Re: STL / Qt flame-war (Re: [linux-audio-dev] Audio-related widgets with Qt ?) I guess it depends on what one is used to. I have always found STL totally painful It really isn't. It's a bit complex at start, probably because of the template use and the iterators. However, both of there are powerfull things and you should understand them both anyway (not that hard). We are in the middle of a project where we use STL. So I am learning the tricks. STL is fine if you are prepared to spend the time it takes to learn the ins and outs. If I had to spend similar amount of effort on each new library I'd never get to write anything. from pg 454 of the book. ;) // remove element n from container c: c.erase( c.begin()+n ); // ok if iterator supports + // or use c.erase( c.begin().advance(n) ); You see, it's not that hard. :) Can you recommend an online-version of this information? Just names of the classes and their member functions and types in readable format. It would be very much appreciated (since at least SGI's on-line docs are lengthy, but difficult to understand). Tommi.
RE: [linux-audio-dev] Re: lawsuit
-Original Message- From: Kevin Conder ... i'm planning my sequencer-synthesizer-multitracker stuff since cca 2 years, What's CCA? cca = approximately erik
RE: [linux-audio-dev] DSP resources
-Original Message-
From: Juhana Sadeharju [mailto:[EMAIL PROTECTED]]
...
Anyone know how to get overloaded complex number operations to C
without rewriting everything in pure C++ style. It is possible
just to switch compiler to g++ for those files which uses the complex
number operations? Can those object files (functions) then be included
to a program compiled with C?
I already have c_mul(), c_add(), etc. functions but they are really
boring to use. I also have simple wrapper routines for using Pari/Gp
for (non-realtime) computations; Pari/Gp can be found from
www.parigp-home.de. Because it can compute with complex numbers
it is as easy to use as overloading (but not as efficient).
...
you can combine C++ and C easily - most of the C code is valid C++ code so
you can have a basically C program that uses some C++ classes (e.g. complex
numbers).
you just compile the whole thing using c++ compiler (g++) (I don't mean
the whole project, just the files that use C++ classes)
for C libraries, use extern C { } in include file (most of the standard
C include files already use it (should use it) - see e.g. stdio.h)
you have to be more careful about typing, some of the 'looser' definitions
are not accepted by C++ compiler.
erik
RE: [linux-audio-dev] How non-programmers use documentation.
-Original Message- From: Paul Sladen [mailto:[EMAIL PROTECTED]] On Tue, 28 Aug 2001, dany wrote: I believe the new filetree-standard under linux will help a lot: if I know my distro is compliant, if I know the prog I try to install is compliant, then I can say there's a bug or not. Elsewhere I'm in doubt. The other alternative is to standardise on Debian, and then just wait until the rest of the world catches up. that's basically the current situation:-) erik
RE: [linux-audio-dev] How non-programmers use documentation.
most of the below seems quite reasonable, I just have few comments: -Original Message- From: Kevin Conder [mailto:[EMAIL PROTECTED]] ... 08. Non-programmers don't want detailed explanations, they want simple answers. then you can only do simple things... as simple as possible but not simpler (forgot who said that...) ... 16. Non-programmers that I talked to have never sent a bug report or a feature request to a software company. The idea of sending one directly to a programmer or a technical writer was a completely foreign concept. this is one area where non-programmers should change if they want good programs. communication is crucial, even more so in free software world. Lot of free programs provide fairly good support for bug reporting and public bug repositories where user can check whether the problem they encountered is already being worked... there are irc channels, newsgroups, mailing lists for various programs there are of incredible value to anybody (programmers and non-programmers) who want to use some program. The feedback is crucial for: - bugs being fixed - features being implemented - user's understanding of program functionality it's just a matter of foreign concept becoming a familiar one... erik
RE: [linux-audio-dev] OSS question
-Original Message- From: Richard Guenther [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 31, 2001 1:25 AM To: '[EMAIL PROTECTED]' Subject: RE: [linux-audio-dev] OSS question On Mon, 30 Jul 2001, STEFFL, ERIK *Internet* (SBCSI) wrote: Iain Sandoe schrieb: I wrote: Do I have to setup a signal handler for SIGTERM to close the audio device properly? This shouldn't be necessary either. Ok a replied too quickly - it is (only) when you get SIGTERM that you have the problem? I am sorry, actually it is a SIGKILL :( But a SIGTERM makes no difference. you cannot catch SIGKILL, but generally you shouldn't kill application using SIGKILL (only if it does not respond to SIGTERM) - precisely for that reason - it does not have a chance to exit gracefully. as for you problem - I guess setting a signal handler that closes audio device (if still opened!) is the right way to go. It should be done by the default exit routine though so I am not sure if you gain anything. You're on a UNIX system, so the kernel generally cleans up after you (i.e. it closes open fds, frees your memory, etc.), so if your soundcard /driver is not happy with being SIGKILLed then thats a driver bug I'd report to the appropriate place. he was complaining about timing (soundcard device is actually closed about 2 s after program exits). if he closes device explicitly in program it might happen (significantly for him) sooner than when the default exit routine does it (or kernel). erik
RE: [linux-audio-dev] what's wrong with glame
yes! instead of rigid menus or menus with last N open files etc. there should be a menu re-arranging functionality that changes parts of the menu so that the most often used functions are easy to access. For one-prupose application that's already done, sort of, by designing the menu according the common usage but for more complex apps that can be used in many ways (e.g. start/root menu in window manager) it would be really nice to have the menu changed according to your usage of the menu (since there is no good default). it should be able to remember how many times you use the menu items and have some sort of frgetting mechanism. I was thinking about implementing something like that for fvwm (in debian (almost) all X apps and lot of text mode apps have menu entries in pre-defined category so I was thinking about putting the most often used ones into top level menu... there an interesting user interface used for one of the midi apps, forgot the name, where you can rearrange all the menus, pin the menus or individual buttons to workarea etc... it might be interesting to have something like that in gnome or kde (qt, gtk) or other toolkits... erik -- Time flies like an arrow but fruit flies like a banana... -Original Message- From: Patrick Shirkey [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 26, 2001 12:54 PM To: [EMAIL PROTECTED] Subject: Re: [linux-audio-dev] what's wrong with glame Richard Dobson said: and, wherever possible, ensure that the most frequently performed tasks (which may be the most argued-over parameter, of course) require the least number of steps. A sub-menu requires at least four, possibly five steps: How difficult would it be to add a statistical analysis function to the program which tracks the most used menu items and organises them into a seperate menu specifically for the most used items? -- Patrick Shirkey - Manager Boost Hardware. Importing Korean Computer Hardware to New Zealand. Http://www.boosthardware.com - Cool toys to fufill every geeks fantasy.
RE: [linux-audio-dev] It's time to vote (n. 1)
-Original Message- From: David G Matthews [mailto:[EMAIL PROTECTED]] What about using UDP instead of TCP/IP? I don't know a whole udp instead of tcp. both udp and tcp are part of tcp/ip (along with ip, icmp, ...) erik lot about networking, but I do know that jMax uses UDP for interprocess communication, and I know some people who have experimented with audio over UDP for real-time work. AFAIK it's a little less reliable than TCP/IP, but gives lower latencies. -dgm On Thu, 24 May 2001, Steve Harris wrote: On Thu, May 24, 2001 at 01:53:56PM +0200, Jörn Nettingsmeier wrote: Over ethernet it seem to be only the first packet that is slow, probably depends on the make of switch though. Unswitched private networks should be fine. But as Paul said these times are too slow to be useful. are there any obstacles in this setup i have overlooked ? from my experience, ping latency is well below 500 usecs. if that's a measure for the actual audio latency, we'll be doing fine. Thats a measure of the minimum extra overhead, in practice it will be a lot higher as you will have to pull the data from the packet process it wrapper it back up again and send it back. Also remeber you have to reassemble the packets in the right order as the ordering is not guaranteed. I might try some benchmarks if anyone is interested. I'm guessing that you really need gigabit though. IP over SCSI or 1395 might be an option, but that's far more exotic. - Steve
