Linux-audio-dev July 2005

linux-audio-dev@lists.linuxaudio.org

72 participants
64 discussions

Re: [linux-audio-dev] 3D fft analysis program

by Downer

> I'm hoping that you're thinking of a realtime display, in which the > peaks roll off to create a true waterfall effect. Baudline (http://www.baudline.com) is a fantastic viewer that does fft cascade. I've used it for a couple of years, and it is great for figuring out how different sounds "work", and it has an oscilloscope-type display as well. Cheers, Jason Downer

19 years, 3 months

[linux-audio-dev] Drum synth

by Dmitry Baikov

Hello. I finally started making my pet music project and realized I need a drum synth to make some cool sounds. psindustrializer is good but also need some tr-909-style sounds. I remeber from my old windoze days I used a nice piece of software called Stomper. Does anybody know any software for linux with comparable capabilities? Or we need to write one? Stomper does not work under wine :( Thanks.

19 years, 3 months

[linux-audio-dev] Re: Drum synth

by Juhana Sadeharju

Hello. I had a couple of articles on drum synths. Check ftp://ftp.funet.fi/pub/sci/audio/devel/lad/drumsynth/ I built the circuit in a00*.jpg at the time when this article was fresh. The article b00*jpg mentions an earlier article. I will check that out at library. Hmm.. I coded a drum synth for Commodore VIC-20 at the time. VIC provided an audio chip with three oscillators, noise, and a common volume if I remember correctly. What I did was to modulate osc pitch and volume parameters with a fast and accurate (compared to Basic) assembly code. The drum sounds were assigned to the keys. This was about 1984, inspired by Yamaha's digital RX drum synths, not by analog drums. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software

19 years, 3 months

[linux-audio-dev] Re: lad design patterns

by Juhana Sadeharju

>From: "Levi D. Burton" <ldb(a)puresimplicity.net> > >does the idea of documenting various lad design patterns make >sense to anyone? Such "LAD Gems" doc would be much needed here too. (For audio dsp gems, take a look at "musicdsp.org".) I would appreciate if somebody would take a look at Ardour and document best gems found there. E.g., the GUI and audio thread separation and start up sequences. Likewise for Linuxsampler and one of its GUI frontends. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software

19 years, 6 months

[linux-audio-dev] Proffessionals?

by james＠dis-dot-dat.net

Hi everyone, Can anyone give me any examples of Free audio software being used by professionals? Anywhere where it performs better, or simply doesn't cost two or more body parts to use? Quick answers get bonus points. James -- "I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you." (By Vance Petree, Virginia Power)

19 years, 8 months

[linux-audio-dev] Real time delay tutorials?

by Iain Duncan

Anyone have a good suggestion for a tutorial for making accurate high-resolution high-priority clocks in C? I found some tutorials but they were kinda old, so wondered if they might be out of date as to how far real-time scheduling has come on linux. I want to be able to wake up a pthread very accurately. Thanks Iain

19 years, 11 months

[linux-audio-dev] ALSA MIDI latency correction

by Peter Brinkmann

Hi, I've been contemplating the problem of reconciling different latencies of various sound sources, but so far the only solutions I have been able to think of seemed sort of awkward, and googling didn't help much, either. Specifically, here's the issue I'm looking at: I have a sequencer application that has several MIDI output ports, each connected to some device that accepts MIDI input. Those devices may have vastly different latencies (for instance, I may want to use my digital piano, without any noticeable latency, together with timidity, which has serious latency, even when started with options like -B2,8, never mind the latency introduced by my USB sound card), but of course I don't want to hear a time lag between those devices. I don't mind a little bit of overall latency; the piano may wait for timidity as long as they're in sync. I'm currently scheduling all my events through one queue (is that the recommended method? I've been wondering whether it would make more sense to have, say, one queue per output port, but I don't see how this would help), and the only solution I have been able to think of is to explicitly schedule events for faster devices at a later time. This is clumsy, and it's exacerbated by the fact that I'd like to schedule events in terms of ticks rather than milliseconds. Since latencies are usually measured in milliseconds, that means I have to convert them to ticks, considering the current tempo of the queue. There's gotta be a better way. Ideally, there are two things I'd like to do: 1. Assign a delay dt to each output port, so that an event scheduled at time t0 will be sent at time t0+dt. Like this, I could compute the maximum latency of all my devices, and the output port attached to a device would get a delay of (max latency - latency of device), so that everything would be in sync. 2. Automatically determine the latencies of the devices I'm talking to. In theory, this should be possible. For instance, if timidity is connected to jack, it could get jack's current latency, add its own latency, and report the result. Is this science fiction? Any thoughts on these issues would be appreciated! Best, Peter

20 years

[linux-audio-dev] IO priorities

by Lee Revell

Disk IO priorities have been discussed on the list before, and they are now in the mainline kernel (search LKML for "IO priorities" for details). I think they're only supported by the CFQ scheduler. This might be fun for someone to experiment with, I'm sure any HDR application would like this feature. Lee

20 years, 1 month

[linux-audio-dev] [ANN] E-Radium V0.61d

by Kjetil Svalastog Matheussen <k.s.matheussen＠notam02.no>

http://www.notam02.no/radium/ INTRODUCTION ------------ E-radium is Radium and a special version of E-UAE. Radium is a midi music editor for the amiga and E-Uae is an amiga emulator. CHANGES ------- 0.61c -> 0.6d: -Increased amount of Z3-memory from 32 to 64. Also increased the amount of chip-mem from 2 to 8 to let there be more time to quit/save after getting a warning about too little memory. For now, this seems to work... -Lowered the keyboard repeat rate a bit. -Fixed make install -Use standard mouse pointer. -Upgraded Radium from 0.61c to 0.61d: -Added scroll-mouse support. Scrolling up is exactly the same as pressing arrow up, and scrolling down is exactly the same as pressing arrow down.

20 years, 1 month

[linux-audio-dev] [OT] 2-D slider widget?

by James McDermott

Has anyone written code for, or even just seen, a 2-D slider widget? What toolkit was it in? Do people around here prefer QT to GTK+, or vice versa, and does anyone use FLTK, or something else? I think the ideal widget would allow the user to click or click-and-drag a cursor around the 2-D area, returning x and y coordinates of course; and would allow a bitmap to be displayed underneath the cursor; and would allow some way to constrain the cursor movements (eg within a circular area inside the widget). Such a thing would be great for lots of audio applications, like controlling filter cutoff and resonance at the same time. That's what I'll be doing, only a bit more complicated..!

20 years, 1 month

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 July 2005