Linux-audio-dev January 2003

linux-audio-dev@lists.linuxaudio.org

99 participants
111 discussions

[linux-audio-dev] Re: Audio s/w ui swallowing

by Chris Cannam

> the big problem is that writing even a simple WM is not > trivial. still, i would guess that taking twm and hacking it to > enforce window sizes and position can't be that hard. twm would be an awful choice -- the code's completely unreadable and surprisingly huge. There are plenty of ultra-minimal window managers around these days that have far better code. Practically anything written since 9wm (a pivotal app in the window manager world). Hacking on one of those need not be hard at all. http://www.plig.org/xwinman/others.html The newer ones are generally nearer the top. I wrote wm2 and wmx which have far too particular a look for the sort of thing you want, but the code's not _too_ bad and I'd be happy to answer questions (though I haven't the time to work on any actual coding of this sort). They're in C++ with BSD-style licensing. They're getting on a bit now though and there are doubtless easier choices even than wm2 these days. http://www.all-day-breakfast.com/wm2/ Chris

21 years, 2 months

[linux-audio-dev] fruityloops on linux?

by lobotomi＠suomi24.fi

I use my PC as a multitrack-recorder and the only program I miss from windows OS is the fruityloops. I tried to ask from fruitydevelopers about linux-support and the answer I get was: "(I wrote)do you think that linux users won´t pay for a good program? is it time, do you have hands full of work in windows versions? (reflex wrote)These two are probably among the main reasons. Also, you'll have to admit that Linux isn't as mature a platform as Windows yet." I´m not a programmer, but If I were, I´d try to do some co-operation with fruity-developers and do an linux-support to the fruityloops. ´cause it´s only the question of time&money. Is there anyone who could do something about this? or is there any program on linux already which works like fruity? you can check our conversation on fruityloops-site(click the "linux, why not?") http://forum.e-officedirect.com/forum.exe?forumname=Fruityloops_DevelopersA… I could give my other testicle for the one who does the linuxversion of fruity. thanks. ,Tomi _____________________________________________________________ Kuukausimaksuton nettiyhteys: http://www.suomi24.fi/liittyma/ Yli 12000 logoa ja soittoääntä: http://sms.suomi24.fi/

21 years, 2 months

[linux-audio-dev] [ANN] amSynth 1.0 rc2

by nick

amSynth - Analogue Modelling SYNTHesizer **************************************** amSynth 1.0-rc2, code-named "jack", is now available!! Get the source code at http://amsynthe.sourceforge.net/amSynth Changes in this release: * you've been waiting for it -- JACK audio output support!! * completely revised ./configure & build system - will adapt features to libraries installed, proper 'make install' target... * launch a virtual keyboard from the amSynth menu! * transparent per-user installation for first time users * build fixes galore, now compiles fine on latest GCC versions Enjoy! (and any problems with it please get in touch, details on website) -Nick d-.-b __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com

21 years, 2 months

[linux-audio-dev] Added Jack support to zynaddsubfx

by Nasca Paul

Hi, I added Jack support to ZynAddSubFX (1.0.6). See at http://sourceforge.net/projects/zynaddsubfx or http://zynaddsubfx.sourceforge.net. Paul. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

21 years, 2 months

[linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15

by Kjetil S. Matheussen

k_jack is a jack reimplementation, and mammut is a very special sound transformating sound editor. Download from http://www.notam02.no/arkiv/src/ New in mammut v0.14->v0.15: --------------------------- -Removed the synth transform. It was not supposed to be there and had no function. -Fixed the wobble transform. Segfaulted with mono-files. (Bug found by Dave Phillips) k_jack V0.0.0.5 ALPHA - EXPERIMENTAL ------------------------------------- ABOUT k_jack currently consists of k_jackd~, libk_jack and libaipc. k_jackd~ is a jack server external for pure-data. libk_jack is (supposed to be) a (somewhat) libjack compatible library. Jack applications that want to contact k_jackd~ instead of jackd must (somehow) be linked with libk_jack and libaipc instead of libjack. k_jackd~ does not speak with libjack, and jackd does not speak with libk_jack. libaipc is a library for audio interprocess communication, based on code from the vstserver. A preview version is included with this version of k_jack. (API is not settled.) By using libaipc for interprocess communication, and letting PD take care of various low/mid/high-level audio-stuff, only a few hundred lines of code is currently used for this implementation of a simple jack system. k_jackd~ and libk_jack are not based on the jack sourcecode found at jackit.sf.net, except for protos in the header files. COMPILE 1. Go into the aipc/src folder and write make to compile up libaipc.a 2. Go into the library folder and write make to compile up libk_jack.a 3. Write make to compile up k_jack~.pd_linux. 4. Relink you jack application(s) somehow. USAGE 1. Start pd with the "-lib k_jackd~" option. 2. Start a jack application linked with libk_jack. 3. Make an object in pd called "k_jackd~ <clientname>". Correct number of inlets and outlets will be made automaticly. That should be it. Later, when things get more stable, point 3 can do point 2 automaticly. WHY use k_jackd~ ? 1. Simple. Only the clientname is used, not the portnames. 2. Easy and powerful interface to control the audioflow. 3. Good performance. Shouldn't be necessary to run as root. TESTED CLIENTS simple_client, freqtweak, ceres. BUGS Crashes pretty often. Does not clean up. Huge risk of not freeing shared memory in the current implementation: Client must exit before server, and client must not crash. And server must not crash. CONTACT Send ideas (especially about the k_jackd~ object syntax), comments (especially about the libaipc API), questions, code, food, etc. to k.s.matheussen(a)notam02.no --

21 years, 2 months

[linux-audio-dev] Happy about MADI

by Tom

I just noticed the announcement from RME about their Hammerfall DSP MADI PCI card. From the announcement: "MADI, the professionals' multichannel audio interface, offers 64 channels of 24 bit audio at a sample rate of up to 48 kHz and 32 channels at up to 96 kHz. Transmission is done via a single line, either coaxial with BNC plugs or with fibre cable. In both cases more than 100 m cable length can be achieved. Hammerfall DSP is fully compatible to all devices with MADI interface." This will make seriously high end gear available for use with standard PC's. As ardour nears readiness, I have been contemplating a total upgrade of my recording gear but I don't like the idea of Toslink in general (short cable length), or adat optical in particular (high jitter), but I do like the idea of optical coupling of audio gear to computer gear (cleaner electricity for the audio gear). I'm glad I waited. Availability is predicted to be within the next 6 months. Now if manufacturers of reasonably priced a/d converters can offer something with a MADI interface within the next 6 months... Tom

21 years, 2 months

Re: [linux-audio-dev] Happy about MADI

by Tom

> >Argh, what's the great thing about standards again. I still prefer mLAN, as > >it uses generic, consumer i/o cards, and firewire is fitted to almost all > >laptops without needing expensive audio only hardware. A single firewire standard would be great, but it hasn't happened yet. MOTU, Digi, Metric Halo, and Yamaha all have incompatible proprietary implementations. Plus there is the minor 4 or 6 conductor thing courtesy of Sony. Starting to look like a mess to me. > it all still sounds pretty dubious to me, Me too. > hopefully, this should echo the fact that i'm with steve: MADI is an > audio-only system, its expensive, and i don't think it has any > particular technical benefits over mLAN. its sole advantage at this > point is that anyone (as i understand it) can implement it without the > licensing and other uncertainties that surround mLAN at this time. The gear that uses it is expensive, but it isn't. RME will sell theirs for the same price as a hammerfall. There is no reason why budget gear can't use it. Audio-only systems are all that's available right now. MADI and adat optical exist as open solutions right now. S/MUX support for adat is spotty. mlan, and 1394 in general, doesn't exist as an open solution. Sure I would like midi and audio on the same cable, but it's not available right now. 6 months from now I will go with mlan if it is openly available. If not then I will go with madi if I can afford it. Otherwise I will go with adat optical. I have been postponing new gear purchases for a long time waiting for an open 1394 solution. Eventually I will have to stop being a cheerleader and actually acquire some gear. The current favorite, adat optical, simply doesn't impress me. If development stays on course, and I am ready to start using ardour in 6 months, mlan will be the only solution of the three that will *not* be available. Tom

21 years, 2 months

[linux-audio-dev] XAP: Some thoughts on control ramping

by David Olofson

I realized a few more things about ramping when messing with Audiality's voice mixers: 1) The STOP event *is* rather handy, as it has no value argument to be calculated or processed. If you're doing internal ramping (or coefficients) instead of using the ramped value directly, STOP just means you stop ramping your internal controls. SET (which is what you must use if you don't have STOP) is supposed to *set* a new value, obviously, and would normally result in the coefficients being recalculated, regardless of current stat. 2) RAMP events with a <target_value, duration> aim point do not guarantee *anything* but the value hitting the aim point. Plugins are not required to perform truly linear ramping; only something that "sounds similar". If you would SET halfway to the aim point, you would get a click, unless the receiver is doing *truly* linear ramping internally! 3) Ramping with aim points means you don't have to know where you are, to set up an accurate ramp to a desired value. You don't even have to know if the current value is above or below the target value. Now, a STOP event before the aim point of a ramp in progress would not always give you *exactly* what you want, but close enough. (Provided the receiver "fakes" linear ramping well enough - which it basically *must* do anyway, for ramping to be usable.) Remember that if you set up a new ramp, it will take you to the new aim point regardless of the current value. So, as long as you don't *SET* before (or after) the aim point, you're safe. 4) Normally, you'd probably re-aim with RAMP, but in some cases, you really just want to hold where you are indefinitely. That's when you would use STOP - or fake it with a "long" ramp to what should be the current value. Both should work, but STOP is easier and faster. 5) A more serious issue is that if control events are not allowed while ramping, except at the time of the aim point, there is no way to avoid sending one RAMP event for each block while ramping. You can't aim further ahead than the first frame of the next block, or you might have to break in and adjust the aim before you hit the aim point. This could potentially be a serious performance issue with low latency hosts, since it means 1000+ RAMP events (and the related transformation overhead) per ramping control. As a real life example of the alternative, the RT envelope generator in Audiality uses one event per node. (DAHDSR currently, which means 7 nodes.) Extra events will have to be inserted to handle real time modulation of the envelope (volume and pan controls, at the very least), but there's never a need for more than one extra event per linear section added. Questions: A) Is it necessary to require that aim points are within the current block, to avoid "re-aiming"? B) Is STOP useful enough to be in XAP? Anyway, I think I have answered my own questions by explaining all this (A: Yes, or complex effects won't mix with low latency, and B: no, you'll probably end up using RAMP all the time anyway) - but I'm still interested in comments. This might not be all there is to it. //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' --- http://olofson.net --- http://www.reologica.se ---

21 years, 2 months

[linux-audio-dev] Simple reverbs

by David Olofson

Well, I got the new device subsystem working in Audiality, although I've only finished the SDL audio driver. ALSA 0.9 rawmidi more or less finished, OSS audio is a mess, and there's no OSS rawmidi yet. (Although that's rather trivial; basically a stripped down version of ALSA rawmidi.) Anyway, I got sidetracked - as usual. ;-) First, I started playing with a noise modulated delay line, but didn't find the results very interesting. So I decided to run a bunch of fixed feedback delay lines in parallel - and that sounded a lot more interesting: It became a pretty neat reverb. :-) With 16 delays and exponential or exponential +/- Golomb ruler, it sounds great for "normal" sounds, but has some problems with transients; it's not dense enough. However, with these uneven delay time distributions, it doesn't sound metallic at all. It rather turns the transients into some sort of "noise" (sounds like random granular synthesis, basically), that soon becomes this "shhhh" most of us desire. With even/linear delay time distribution, it still sounds pretty good, but it starts to remind of a gong simulator or something. Plate reverb, maybe... Interesting, but not what I was looking for - although I'm throwing all interesting variants in, so they can be selected through a plugin control. With 32 delays, it starts to sound *real* interesting - but it also starts to abuse my PC133 RAM pretty seriously. It won't run real time on my P-III 933 above some 48 delay lines, although this is with 32 bit buffers of 8192 samples each. This can be improved upon a lot, since I'm only using a tiny fraction of the maximum delay times with that dense settings. (Like 300 +/- 100 samples.) Also, it's all integer, so I could probably use 16 bits. I have no feedbacks in beetween delays; just one local, LP filtered feedback per delay. Every other pair of delays is stereo reversed. Tried some network feedback setups, but I couldn't figure out any truly useful configurations. Untested idea: Have multiple feedbacks for each delay line. (The old "reverb" of Audiality is actually just one stereo delay line with multiple feedbacks, BTW.) The idea is that, while not as effective as separate delays, this is a lot cheaper, so I might get more density/cycle. Oh, and I'll try the well known delay time modulation trick, of course. Maybe using filtered noise instead of periodic LFO waveforms? Thoughts? Any ideas for useful cross feedback configurations? //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' --- http://olofson.net --- http://www.reologica.se ---

21 years, 2 months

[linux-audio-dev] Tkeca 1.0.2 released!

by Luis Pablo Gasparotto

Changes: - Bug when .ecasoundrc was not in ~/ directory (Ecasound 2.2.0) - Bug when no ladspa directory defined in ecasoundrc http://www.sourceforge.net/projects/tkeca Regards, Luis Pablo Ahora pod�s usar Yahoo! Messenger desde tu celular. Aprend� c�mo hacerlo en Yahoo! M�vil: http://ar.mobile.yahoo.com/sms.html

21 years, 2 months

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