Re: [linux-audio-dev] anyone interested to develop a new apps ?
Hi there, what was the problem of using my plugin inside PD? Cheers, Alex On Sun, 24 Oct 2004 18:59:49 +0200, Frank Barknecht [EMAIL PROTECTED] wrote: Hallo, [EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote: Hey thanks a lot ! I tried it and I must admit that PD with your patch gives me the best results in term of cutoff :) Now I need to add effects on each track... thats another story :) You can do this inside Pd as well, if you like. I already had a version using the GLAME plugin ready, but the plugin didn't work here inside Pd at all. Maybe you have more luck. I attached the plugin~-based version, for which you need the plugin~ external. On Debian it's part of pd-externals, otherwise get it from pure-data.sf.net xover-vol.pd from my previous mail is needed, as well. Even if it doesn't work with all plugins, plugin~ can be used for adding LADSPA effects in Pd generally by following the model of my example. Ciao -- Frank Barknecht _ __footils.org__
Re: [linux-audio-dev] wcnt linear filters
I've not had much chance to uDse ladspa. I've compiled glame to use it's filter network, but there seems to be inputs and outputs Olacking, many are mono, I can't read a stereo file, through a reverb and out to another stereo Tfile, or from a stereo input on soundcard, through fx, to file, so I've given up on glame (again), plus I don't like how it wont delete the deleted things. I browse through this mailing list rather seldom now due to lack of time. Glame does all the things, you didn't get done, so why don't you ask on the glame-users mailing list, or glame-devel mailing list? There's not much going on so we usually answer rather quick :-) Which glame version did you try? To read a stereo file you just open the read_file plugin from input. Then you add a reverb from the LADSPA section. And to connect them you simply left click into the right (blue) area of read_file a drag a connection to the plugin. For a second channel you just drag a second arrow to whatever other plugin. Really easy.. Cheers, Alex --
Re: [linux-audio-dev] 8bit sound wav playing to a 16bit sound card...
Or you can use glame to import it and resample it to 44kHz, 16bit Cheers, Alex Am Donnerstag, 12.06.03, um 23:11 Uhr (Europe/Berlin) schrieb Derrick: I'm playing the file at the Sample rate that is in the header of the wav file.. when I play the file in gnome recorder it reports a Sample Rate of 11025, My program also reads it as 11025 and sets the SNDCTL_DSP_SPEED accordingly... Let me restate.. The sound that does play is so fast that it sounds almost like noise. If you didn't know that the sound bite actually was. On Thursday 12 June 2003 12:42, Tim Hockin wrote: I'm new to OSS Programming, and I'm attempting to play some 8bit wav files. However OSS is telling me that my sound card will not play 8bit , only 16bit. If I force it. The sound changes pitch, and is very fast. ( obviously ). Bit-depth has nothing to do with pitch. If it sounds fast, it is because the file is at a lower sample rate. -- What's another word for thesaurus? -- Steven Wright
Re: [linux-audio-dev] Additional LADSPA hints
On Wed, Jan 15, 2003 at 10:23:37PM +, Steve Harris wrote: That sounds useful, but its a seperate issue. I cant think of a way of generalising it... maybe OPTIONAL? i.e. this plugin will still do something useful if this port isn't connected. I just might be a bit late giving my 2cents to this discussion, but I rather read this list on a non regular basis, too much to do at university... Anyway, why a introduce a ladspa hint for such specific features. Anyway the Sidechain port has a label called Sidechain, so every host wanting to provide special support for the label can just check for it and use it. In GLAME you can just build up a custom network integrating whatever effects and connecting them how you like. And than just save it and use it as new effect. Cheers, Alex
Re: [linux-audio-dev] Software Setup
On Fri, 27 Dec 2002, CK wrote: I read: I'm just curious about the software setup people use here to play around to make music. Furthermore I'd be interested what software setup people use to use jack. I was recently wanted this is sort of a linux audio users question please take a look at: http://www.linuxdj.com/audio/lad/subscribelau.php3 for jack related troules see: http://jackit.sf.net/ Actually I'm just asking because I want to see how good jack is and how it works before we start to add jack support to glame. Cheers, Alex
Re: [linux-audio-dev] Temporary XAP website
On Fri, Dec 13, 2002 at 11:33:38AM +, Steve Harris wrote: On Fri, Dec 13, 2002 at 11:32:10 +0100, David Olofson wrote: Very nice. Logo #2 (with the red A) gets my vote. Hmm... Yeah, that's the first version I made. My ex GF suggested blue, and I thought it might look more serious in a way. I think I prefer the red one too, though... Me too. :) Yeah, me too! The 2nd logo is the best, but the P is a bit too wide :) Cheers, Alex --
Re: [linux-audio-dev] Basic information
Hi, Hi. Could anyone point me to some very basic information to give me some idea of programming for sound in linux. we can't even begin to answer such a nebulous question i'm afraid. why not? I would just start to have a look at other sound applications and try to understand what they do. That's actually how I did it. And then you can get yourself a working installation of alsa and try to build the existing documentation. In the meantime there's even a small primer, how to open a sound device and make some noise. Cheers, Alex ___ linux-audio-dev mailing list [EMAIL PROTECTED] http://music.columbia.edu/mailman/listinfo/linux-audio-dev
Re: [linux-audio-dev] Basic information
Hi, because its far from clear that this is the right thing to do with an SC port. if you don't know what SC is, you might not realize that the Yeah, anyway, I was not pointing in direction of SC, I thought he's interested in sound programming in general. Cheers, Alex ___ linux-audio-dev mailing list [EMAIL PROTECTED] http://music.columbia.edu/mailman/listinfo/linux-audio-dev
Re: [linux-audio-dev] Re: Exact desicption of PCM system for ALSA
Hi Paul, encoding, the value (generally) varies between -(2^N) and (2^N)-1, where N is the number of bits used to store the value. So a 16 bit value will vary between -65536 and 65535. there are other ways of Errr, I think you meant ... between -(2^(N-1)) and 2^(N-1)-1 ... So you get a range between -32768 and 32767 for 16 bit signed or between 0 and 65536 for unsigned 16bit. Cheers, Alex
Re: [linux-audio-dev] LADPSA v1.1 SDK Provisional Release
Hi, I understand your objections, but I think the alternatives (that keep binary compatibility) are just as bad in there own way. Is binary compatibility really an issue right now? We have swh plugins, cmt plugins, what else? It's all open source, so just recompile it. Cheers, Alex
Re: [linux-audio-dev] LinuxTag2002 photos from the LAD/ALSA booth
On Thursday, June 13, 2002, at 01:11 PM, Joern Nettingsmeier wrote: hello everyone ! the photos from the joint LAD/ALSA booth at LinuxTag 2002 in karlsruhe/germany are now available at http://www.linuxdj.com/audio/lad/events.php3 . those who asked for t-shirts will find a link to the image there. it's probably easier to find a print shop close to you and roll your own than to fedex shirts around the world. for some general info about LinuxTag, go to http://www.linuxtag.org/ (in german; there is a link to the english version in the top right corner. the page probably does not reflect yet that the show is over.) we will most definitely have a booth again next year. if you'd like to participate, write to me off-list ([EMAIL PROTECTED]), i'll collect your address and forward it to the organizers when the preparations start (usually around february). best regards, jörn
Re: [linux-audio-dev] Broadcast 2000 successor, Cinelerra available.
On Tuesday, June 11, 2002, at 08:10 PM, Dan Hollis wrote: On Tue, 11 Jun 2002, Vincent Touquet wrote: There is some bad news lurking too, let's hope this posting: http://sourceforge.net/forum/forum.php?thread_id=687636forum_id=164360 doesn't reflect the authors real intentions for the future ... :( if they choose windoze purely for PHB/marketing reasons, then they really are as stupid as i feared... I actually never tried broadcast, I never got it to compile. But that's probably intendend. The author always rants about he's got to make a living of broadcast and no one pays and blablalba, so why did offer broadcast this way if he obviously disliked open source in the first place. Strange guys... Cheers, Alex
Re: [linux-audio-dev] Poll about linux music audio app usability
Hi, something like that, forgot the name), Eyesweb, Glame, pd, jmax, Visual cglame even compiles on MacOSX, the problem is that mmap doesn't work the same way as it does in Linux and so our swapfile backend doesn't work. As richi and I are proud owners of iBooks we might resolve that problem. Another problem is gtk, you could use glame with the XDarwin Xserver, but writing a native GUI, hmm, I don't think so. Maybe we should go commercial for OSX ;-) Cheers, Alex
Re: [linux-audio-dev] Initial relase of Swami
Hi Josh, very nice webpage! Nice design, don't you want to overhaul the glame homepage, too ;-) I'll have a look at swami soon. Cheers, Alex
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
Hi, I'd like some idea how hard it would be to write an ALSA driver either as a compatibility layer on top of our existing driver, or from the ground up. I realise that this is rather a broad question, so please consider this an invitation to enter discussion, rather than a request for you to go off and do a lot of work for me. With that amount of knowledge you have about your card, it actually shouldn't be to hard to develop a driver. I wrote a linux kernel driver for a volume rendering graphics card with reconfigurable hardware and an onboard DSP with less information. I don't know about the interna of your HPI, but surely you need to include some low level code to do the PCI detection and setup of your card with linux. If that's already in your HPI it shouldn't be a problem to adapt that to write a wrapper for the alsa lib. If you want then you provide your dsp code and distribute it with alsa. At least some amount of code goes into the kernel and so has to meet Linus standards :-) Alright, then. If you have any questions, I see no problem supporting you, writing that driver. Cheers, Alex
Re: [linux-audio-dev] MMX, SSE, SSE2, 3DNOW
On Mon, 2002-02-18 at 04:07, Bob Ham wrote: Not really. How are plugins different from programs in this respect? I don't think any OS says to programs do you use SSE instructions? no? I'll not run you then. Instead, programs (or, more usually, build systems) say does this machine support SSE instructions? no? I'll not execute/build them then. I don't think it's sufficient to do the check at build time, that makes packing of plugins for distributions too complicated. As it seems, people prefer that the plugin checks by itself whether the right cpu is available and then run the correct processing loop. This can be done within the init method every ladspa plugin has. And then just select the right callback. That's probably the best solution then, without changing anything in LADSPA. Cheers, Alex
Re: [linux-audio-dev] MMX, SSE, SSE2, 3DNOW
On Sun, 2002-02-17 at 20:52, Jussi Laako wrote: Just use cpuid instruction and switch to correct code block accordingly. Ok, sure, we all know how to do that, but LADSPA doesn't have any knowledge about this things yet, you can't query the plugin whether it wants to use SSE, MMX, 3DNOW, ..., whatever. I'm talking about querying the plugin at runtime and then the hosts should be able to check somehow if it can execute the plugin or not. So we have to set some flags in the plugin. Cheers, Alex
[linux-audio-dev] MMX, SSE, SSE2, 3DNOW
Hi, AFAIK there are no flags whatsoever to indicate which processor a plugin might use. So if someone wants to hack a plugin that uses SSE instructions and someone else tries to use that on a host without SSE support - crash. So wouldn't it be good to add some architecture flags, that could be queried by the host? Cheers, Alex
Re: [linux-audio-dev] Going mono to stereo in LADSPA?
On Fri, 2002-02-15 at 13:19, Steve Harris wrote: Does sin and cos give a reasonable constant power function? It looks about right by eye, but I haven't tried listening to it. In physics the intensity of a signal is give by its square, e.g. the intensity of a sine is I=(sin(x))^2. As sin^2(x)+cos^2(x)=1 the total power of the signal is conserved over both channels. In case you want to split up the signal equally we have sin(PI/4)=cos(PI/4)=0.71, (0.71)^2*2=1 Cheers, Alex
Re: [linux-audio-dev] newbie question on installing glib
On Thu, 2002-02-14 at 20:06, Bob Colwell wrote: Linux audio savants: I have a trivial newbie question. I have Mandrake Linux 8.1 on my P4 machine, and I've downloaded GLIB 1.2.10 and GTK+1.2.10 into two directories on my machine, like so: Why don't you save yourself a lot of trouble and just get the mandrake packages for glib and gtk and install them? I'm sure they have packages. Cheers, Alex
Re: [linux-audio-dev] Going mono to stereo in LADSPA?
On Tue, 2002-02-12 at 13:15, Steve Harris wrote:
Sure, can't see why not. I will change the labels a bit though, a mono to
stereo converter usually does something different.
What does a mono to stereo converter do then, other than that?
But anyway I'd say that channel splitting is something a good host
should do. Now you can start adding another 31 plugins that do 1 to n
channel splitting :) Actually a better option to that splitter would
have been a panning plugin, that splits up the mono stream and
distributes the mono channel with different weights to stereo:
callback event=run
unsigned long pos;
panright = sin(theta)
panleft = cos(theta)
for (pos = 0; pos lt; sample_count; pos++) {
LADSPA_Data in = *(input++);
buffer_write(*(outright++), in*panright);
buffer_write(*(outleft++), in*panleft);
}
/callback
where theta has to be pi/4, to get equal distribution on both channels.
Cheers, Alex
Re: [linux-audio-dev] query
On Wed, 2002-02-13 at 17:39, Taybin Rutkin wrote: bigger than the overlap you used before. So far the basic idea. Happy implementing :-) Is that how the non-pitch-changing one works? That's how sox does it, I suppose. But that only works for a limited range. If you try to stretch it to much this way, you probably get some strange artefacts. Another option are FFT or wavelet based algorithms. Actually, this time stretching question would be something for a FAQ. I'm subscribed to the music dsp list as well, and people frequently ask how time stretching is done. There is a good explanation at http://www.dspdimension.com/ Cheers, Alex
Re: [linux-audio-dev] ardour / ypmfpci
and that's why i use mine as a secondary card for non-rt programs (hey, it puts out good sound with low noise, so it's still useful) like playing cds and mp3s. Yeah, that's what I do, too. I bought a Hoontech Digital XG with the digital bracket. So I have nice optical digital outputs and can record to my mini disk player. And it was quite cheap. Otherwise for RT stuff I use my old ISA SB AWE for sampling and my SB Live for output. That combination works rather well. Cheers, Alex -- It is by the fortune of God that, in this country, we have three benefits: freedom of speech, freedom of thought, and the wisdom never to use either. -- Mark Twain
[linux-audio-dev] Equalizer(was Still blabla...) and more
Hi, lets swap back to interesting stuff. This Still... thread sucks. So I just added some documentation to glame about How to make funny realtime networks. We recently had lots of fun at a party doing some Mickey Mouse Effect on the voice or creating a network that loops a sample input. So you can do sort of voice drum loops, I think we already had that a the Linuxtag. In the meantime though I have less problems with dropouts. Using my SBAwe32 for sampling and my SBLive for output, I can use framesizes of 64. And that with the multithreaded approach of glame. So that's not too bad. Just curious, but could somebody explain *how* delay lines can be used implement EQ? I have a strong maths background, but no DSP experience if that helps. I would suggest to just use a few convolution filters, that are logarithmically distributed over the frequency range. Just setup a FIR/IIR filter for every desired frequency. IIR should be really fast compared to FFT/FIR, but it's hard to get those filters stable over a long time period. IIR is so fast because you only need small kernels for convolution, IIR uses feedback. With FIR and the same quality you need a larger kernel. If you have really large kernels, you have to use FFT convolution anyway to be fast. ok, back to the delay lines Paul mentioned. I haven't implemented that myself, but for eq with delay lines you probably use IIR. For example a biquad IIR looks like that: y[n] = x[n]*a0 + x[n-1]*a1 + x[n-2]*a2 + b1*y[n-1] + b2*y[n-2] If you want a 2 pole bandpass you would setup a0,a1,a2,b1,b2 like this: omega = 2.0*M_PI*center; alpha = sin(omega)*sinh(log(2.0)/2.0*bandwidth*omega/sin(omega)); a0 = alpha; a1 = 0.0; a2 = -alpha; b1 = 2.0 * cos(omega); b2 = alpha - 1.0; gain = 1.0 + alpha; a0/=gain a1/=gain ... center is the normalized frequency of the bandpass: center = center_frequency/sample_frequency bandwidth is given in octaves between the -3dB attenuation levels of the passband Have a look back at the formula, you see that we need y[n-1], y[n-2]. That would be your delay line, y[n] contains your output sample. Now you can aplly gain on that frequency band and sum up all your bands. That should be way faster than FFT. Using FFT your frequency bands are distributed linear over the frequency range. That is untypical for equalizers anyway, as they always use a logarithmic scale. Which is obvious, because musical harmonies are perceived on a logarithmic scale, f.i. one octave up corresponds to a doubling in frequency. Cheers, Alex -- Work consists of whatever a body is obliged to do. Play consists of whatever a body is not obliged to do. -- Mark Twain
RE: [linux-audio-dev] Still I cannot understand why...
Hi, Of course! This is because Alsa is not a part of the kernel. Once it becomes a part of kernel, it will be the same like OSS in this respect. Pff, nothing would change, if alsa is in the kernel? I don't see why this should suddenly make things easier? I don't see the necessity to put in into the kernel, if it installs nicely from a different directory. Compiling the alsa modules for the drivers and installing it with make install does work quite easily. Debian even ships alsa packages with precompiled drivers for the kernel. Installation of alsa-lib afterwards is the problem. The users asks himself, how to setup the modules for the init script, what the heck happends in asound.state, how do I write my own configuration files. And what can I do with all those hw, plughw, share, multi, whatever plugins. And I have to admit, I'd like to read about that, too, cause I have no clue and I actually have better things to do right now than reading the alsa source. Anyway I learnt how to setup a device, configure it and happily read/write to it. But until know I haven't seen what else ALSA can do, that would make it really different from oss. Apart from the possibility to use smaller framesizes, but that's possible with oss too, in case the driver supports smaller framesizes. 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 Luckily the authors of some sound applications thought different. As Paul already stated most of the early ones come from IRIX. 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. You're probably happy with ALSA on Linux/i386. What about Linux on other architectures.. Cheers, Alex -- Kindness is a language which the deaf can hear and the blind can read. -- Mark Twain
Re: [linux-audio-dev] Re: lawsuit
Hi, (http://ardour.sourceforge.net), GLAME (glame.sourceforge.net), or ecasound (eca.cx), rather than start your own. Of these three, ardour is the most ProTools-like in what it attempts to accomplish. Viszontlatasra! You could probably also build your app as a Mustajuuri plugin, depending on what you are after. or you could even implement it as plugin for GLAME ;) Cheers, Alex -- A banker is a fellow who lends you his umbrella when the sun is shining and wants it back the minute it begins to rain. -- Mark Twain
Re: [linux-audio-dev] How non-programmers use documentation.
Hi, 12. Non-programmers don't want to see information about how a feature was implemented. In audio processing they will want if they are professionals. So many things can go wrong if DSP algorithms are incorrectly Definitly, to actually apply DSP you should know what you're doing. That isn't limited to DSP actually :) 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. I consider this a bad attitude in open source land. Cheers, Alex -- Patch griefs with proverbs. -- William Shakespeare, Much Ado About Nothing
Re: [linux-audio-dev] Disk use causes freezes
Hi, I'm a bit worried about it because Debian 2.2 rev 2 is behaving similarly. If I copy large files, or perform md5sums on large files, it may take even 45 seconds before I get the password prompt on the console or get a directory listing. Typically it takes 25-30 seconds. Writing text in Emacs may have 4-5 seconds latency; sometimes larger. What application are you using? If you have on of those editors that loads everything into RAM, that doesn't surprise me. Glame just reads everything into it's on swap. Processing is then done by mmapping the swapfile. If you want to stream an audio file into a network the read is blocking until the next effect in the chain has processed the last block. No problem with swap at all. Cheers, Alex -- ROMEO: Courage, man; the hurt cannot be much. MERCUTIO: No, 'tis not so deep as a well, nor so wide as a church-door; but 'tis enough, 'twill serve.
[linux-audio-dev] Partly Success(was Resampling)
You can try MIDIMAN cards too. please visit www.midiman.com On Wednesday 01 August 2001 09:00, you wrote: Is there any card, that works fine with full duplex 44kHz and small fragment sizes? Not the Hammerfall, I want something cheaper. I use a Trident 4D-NX based card from Hoontech that cost about $60, and it works 100% with 64 frames per interupt. The last couple of days I was tweaking around with my alsa setup and tried to get alsa running on my laptop with Maestro2. So I had to increase the number of fragments. Now using 4 fragments and trying that on my desktop, I can sample with 236 frames with input through my SBAWE32 and output through the Hoontech YM754. Unfortunately I can get good full duplex on both cards. The AWE can't do 44.1kHz, 16bit Fullduplex, the Hoontech could but somehow the driver jerks. Is there a difference between opening a device with full duplex in alsa or opening to handles, one for input, one for output? Cheers, Alex -- Repartee is something we think of twenty-four hours too late. -- Mark Twain
[linux-audio-dev] Resampling
Hi Juhana, sorry with all that gui discussion I totally forgot about this email. What exactly is the algorithm? Does it do a good job? How have you tested it? I just do an n-times oversampling DFT. You can configure blocksize and oversampling(overlap) factor. Then for the resampling process I just add/remove bands in the frequency domain and then do resynthesis. Thats it. In the oversampling and resynthesis code I use Hanning windows. It's all done in float precision atm. For FFT I use the fftw lib, which is really fast. So I can do 32times oversampling with 16384 samples blocks in realtime on a celeron 300. But you don't really need that 8-times oversampling with 1024 samples windows is really enough to get good sounding quality. I never did a frequency analysis on my results, only listening tests and I like the result. If someone feels like thoroughly analyzing it, go ahead :) turning Glame's wave editor, Sweep and Audacity(?) to a SoundForge clone because SoundForge has a quite good user interface. I understand I don't know about that. But I don't want to get in that GUI discussion again. It has some nice features, like nice windows for analyzing and applying effects. We'll have that soon too :) BTW: Yesterday I gave my flanger effect some polishing, you can now change parameters realtime and it has a nice feedback and gain control. Just using it at the limit just before it turns into an oscillator the effect sounds really cool on voice. No it's not a ladspa plugin. Linuxtag people may remember the mickey mouse/darth vader effect I did with that effect. That still works, but I have to separate that into a detuner soon to remove the anoying clicks. Those clicks are additional to the ones trying to do realtime/lowlatency stuff with ALSA. Is there any card, that works fine with full duplex 44kHz and small fragment sizes? Not the Hammerfall, I want something cheaper. Or does someone know a cheaper AD/DA converter than the RME one? Surprisingly the cheap Ensoniq cards work quite well :) Cheers, Mag
Re: [linux-audio-dev] User Interface
Hi, I would like to add that I feel it is the ideas that are more important than the individual apps. Each one has different strong points. Things progress so much faster with the sound editors if we combined these ideas. Yeah thats it and sometimes two different philosophies can't be just married with each other. Mutual exclusive. This is a very good idea. Seperate the gui from the guts and we have a very portable editing app. Thats the point with Glame. It's model view controlled, thats why we need a bit more time to get all the functionality that apps have, where all the editing code is somewhere inlined in the gui. strong editing suite. How unrealistic is it? Is that posibility just too fantastic? Yes. large code base. Of course it will probably mean more concessions but then if it is really good you just have to prove it. It's not just contributing to some code base, someone has to think of software architecture and all the other contributors have to stick with that design. That is the way the linux kernel development goes as well. That is the Linux way. Ah, so why do we have zillions of different shells, editors, desktops then? Anyway this is hobby and people do whatever they like to realize their visions. And as I said before it's not just sticking to programs together and they have double the amount of features :) Cheers, Mag -- If you tell the truth you don't have to remember anything. -- Mark Twain
Re: [linux-audio-dev] User Interface
On Wed, 25 Jul 2001, Paul Davis wrote: Paul Winkler writes: I was just wondering why people on this list seem to ignore glame, when the discussion comes upon waveeditors. [ ... ] Can't compile it without GNOME. I don't like that. I guess that makes me a luddite. Oh well. i *am* a luddite, and i don't like GNOME-dependent audio software either. Harhar, welcome to kindergarden folks :-) So we're back at the stage where we discuss the best widget set for a whole year? Cheers, Mag -- In India, cold weather is merely a conventional phrase and has come into use through the necessity of having some way to distinguish between weather which will melt a brass door-knob and weather which will only make it mushy. -- Mark Twain
Re: [linux-audio-dev] prof multitrack studio
Hi, what could be a Gimp for audio. A montage tool with effects. (do you see my subliminal exhortation toward Glame people ;) We're working on it, but as always it's a matter of time and money :-) As for MIDI support, I'd like to get into it, but I'm still missing some equipment like a Masterkeyboard and stuff to experiment with. Furthermore my audio hardware or the drivers or both is just giving me the creeps... And purchasing a Hammerfall, an AD converter, a Masterkeyboard, ... seems to become a little bit expensive... That's probably the reason why companies charge a lot of money for software, in Open Source World it all takes a bit longer. All in all it's a hobby, at least for me :) Cheers, Mag -- For years a secret shame destroyed my peace-- I'd not read Eliot, Auden or MacNiece. But now I think a thought that brings me hope: Neither had Chaucer, Shakespeare, Milton, Pope. -- Justin Richardson.
Re: [linux-audio-dev] LinuxTag 2001 Infomail #4
Hi, Somebody should bring some adhesive tape... I marked my hub and a cable that way at LinuxTag '99, and the tape's still there :-) Yeah, and some other sticky tape as well, to tape all those audio cables to somewhere, so that people don't fall over it and damage themselves and the hardware. Not that I care a whole lot... I can either lock up my notebook in the back storage area of the booth, or carry it with me. But I'd be willing to add some funds to an insurance for the common good (as far as funds allow, of course... perhaps not 50.-, but some part of that). Same with me. IIRC, the LinuxTag organizers prefer booths to use switches when possible (they said something like hub is okay but if you connect more than a minimum number of machines (or have higher traffic internally ;-) you should use a switch) :) I'm not going to buy one though. Hub is perfectly O.K. Cheers, Alex -- I've touch'd the highest point of all my greatness; And from that full meridian of my glory I haste now to my setting. I shall fall, Like a bright exhalation in the evening And no man see me more. -- Shakespeare
Re: [linux-audio-dev] LinuxTag - Infomail 1
Hi Frank, for the glame team I send a triple ack for these guys: Alexander Ehlert ( [EMAIL PROTECTED] ) Daniel Kobras ( [EMAIL PROTECTED] ) Richard Guenther ( [EMAIL PROTECTED] ) 4) Available hardware I'm building up a list here..more info perhaps in the next mail. Should we bring hardware or do you have enough hardware. We'll bring our laptops, anyway. Let's just discuss details after next tuesday, then I'm hopefully finished with my diploma :) *yippie* Cheers, Alex
