Linux-audio-dev January 2006

linux-audio-dev@lists.linuxaudio.org

83 participants
66 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

18 years, 6 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.

18 years, 6 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

18 years, 6 months

[linux-audio-dev] python and jack, performance report

by Leonard "paniq" Ritter

-- oops, the first one was sent as a reply, here's the whole thing as a new thread. frustrated by the poor implementation of the jack bindings for python (pyjack), i wrote my own in native python using ctypes. the first test client mixed a 440hz sine wave using native python lists, and the cpu usage was about ~11%. i reimplemented the sine generator with numerics, and got it down to ~2%. i believe that considering the overhead of the python implementation, that result isn't too bad, and maybe allows for more than just prototyping. i attached the jack wrapper with the test client contained for those who are interested. its not entirely wrapped and lacks some functionality. -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org

18 years, 7 months

[linux-audio-dev] Call for help for LinuxTag2006

by Arnold Krille

Hi all, as every year the famous german LinuxTag is taking place. This year in Wiesbaden from 3. to 6. May. Yes, this is just one week after LAC2006, which has several advantages and disadvantages: + It is a good chance to come to Germany for LAC, have one or two days of holiday and then join the LA-Group at LinuxTag! + Maybe even repeat your LAC-Talk at LinuxTag? (see www.linuxtag.org for details on the Call-for-Papers but be aware that it ends January 15...) + Wiesbaden is more in the center of germany so perhaps some LA-folks from the north of germany can join us? - The new place for LinuxTag together with LAC being a week before enforce two of the main-booth-members of the last years (Christoph Eckert and Frank Neumann) to be only a visitor at LinuxTag or even less... That leaves a hole in the organisational part. :-( So here is my call: I am willing to do some work organizing a booth and a group of staff but I need YOUR help! If you are a german LA[DU]-member and have some spare time, join in! A booth at LinuxTag is a good opportunity to present Linux Audio to the people, not only to developers but more to users. The crowd is mostly industry (producers, technicians, musicians) at the weekdays and home-recording-users at the weekend. Don't be afraid, there won't be much questions about setting up drivers for consumer-cards (and If there are, we usually send them to their distributions booth :-) ). But there will be a lot people thinking about using your app in studio! So you definitly don't want to miss this chance! If I get positive answers from at least two other people by weekend, I will apply for a booth and things start rolling, so don't hesitate, check your calendar, plan for another week of holiday and join me (us?). So long and thanks for all the fish, Arnold -- visit http://dillenburg.dyndns.org/~arnold/ --- Wenn man mit Raubkopien Bands wie Brosis oder Britney Spears wirklich verhindern könnte, würde ich mir noch heute einen Stapel Brenner und einen Sack Rohlinge kaufen.

18 years, 8 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

18 years, 9 months

[linux-audio-dev] portmidi app i/o ports

by Carlo Capocasa

Hi, I would like to know whether it is possible for portmidi based applications to have their own sequencer i/o ports to connect to. Thanks, Carlo

18 years, 9 months

[linux-audio-dev] Re: templates - little bit OT

by Kjetil S. Matheussen

Lars Luthman: > > On Thu, 2006-01-19 at 00:41 +0100, conrad berhörster wrote: >> class MyClass >> { >> MyClass(); >> MyClass(n,n); >> private: >> matrix<n,n> >> }; >> >> this means, at runtime, i want to set the size of the matrix. is this >> possible? this are divers concepts (templates and runtime) , aren't they? > > It is not possible. Templates are instantiated at compile time. > Nah, its possible on the fly to generate code, compile the code, and link it. I have done that many times. --

18 years, 9 months

[linux-audio-dev] [ANN] jack_capture v0.0.1

by Kjetil S. Matheussen

http://www.notam02.no/arkiv/src/ ABOUT ----- jack_capture is a small simple program to capture whatever sound is going out to your speakers into a file. This is the program I always wanted to have for jack, but no one made. So here it is. USAGE ----- jack_capture [-f filename] [ -b bitdepth ] [-c channels] [ -B bufsize ] Filename is by default auotogenerated to something like "jack_capture_<date+exact_time>.wav" Bitdepth is by default FLOAT. Channels is by default 2. Bufsize is by default 262144. ACKNOWLEDGMENT -------------- Mostly based on the jackrec program in the jack distribution made by Paul Davies and Jack O'Quin. Automatic filename generation code taken from the timemachine program by Steve Harries. --

18 years, 9 months

[linux-audio-dev] Re: open standards for file formats

by Item State

hello, yes, peak/overview files and metadata is two different things. metadata should be stored in a open and extensible format such as XML. the problem with peak files is, different programmes rely on different resolution and representation. to give an example, in eisenkraut i use four peak files in four decimation scales ; only the highest resolution (1:256 (?)) is saved permanently, the others are created on the fly. since i want to support floating point files, i decided to store peak waveform in float32 format, which is rather big ; other sound editors will decide to not do this. also i store both peak and RMS information, others wish to store only peak, or peak and spectral focus or whatever. so unless two programmes are rather similiar, i wouldn't be too optimistic about using a uniform peak display. also i wouldn't deal with commercial software, honestly. if two software companies, say bias (for peak) and emagic/apple (for logic) are too dumb to agree on one format, i see no point why open source software should go and beg those companies to share their format. rather, if there are a few de facto standard open source softwares, it would make sense that they define a standard that they share. for eisenkraut i use normal AIFF files als overviews, i think that's pretty straight format, and since most programmes will store some form of PCM data, it shouldn't be too difficult to sync two -- if they work in a similar resolution and representation. there are some standards already, like SDIF for spectral information for example. best, -sciss- ____________________________________________________ Do you Yahoo!? Never miss an Instant Message - Yahoo! Messenger for SMS http://au.mobile.yahoo.com/mweb/index.html

18 years, 9 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 2006