Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7501 discussions

[linux-audio-dev] the bandwidth of the each harmonic

by Paul

...a simple, but powerfull paradigm that helps to make simple algorithms that produces very beautiful sounds. Hi. I want to open a topic about what I call "bandwidth of each harmonic", to say some ideas that helped me to make beautifull sounds. I am Paul, the author of ZynAddSubFX software synthsizer ( http://zynaddsubfx.sourceforge.net ) and I wish to share some ideas ;) Referring to musical sounds,usually the harmonics are considered simple sine function. Of course, the reality shows different thing, and so, the harmonics was started to be considered as sine functions modulated by a lower frequencies (I saw some time ago a link that describes that the choir sound is beautifull because of the "micromodulations",etc...). A very good thing is to "have a look" in a frequency domains. Let's take for example a choir that sing same note (like A=440Hz). Because all are human, even they are very well trained singer, they will not sing exactely the same note; for example one will sing at 435 Hz or other, at 443 Hz, and so on. Now, the first harmonic (the fundamental note) is not longer a sine of 440 Hz, but a narrow band signal that has a certain bandwith. For example, let's take a very simple case: if all sing at same loudness, and they sing from 435 Hz and the 445 Hz. In this case, the bandwidth will be 10 Hz. Of course, in real choir the frequency distribution of the harmonic will be not flat, but usually will be a curve that looks like a normal (gaussian) curve(found this after I did some research= very fine frequency analysis with very long FFTs). Now, let's go to the second harmonic: if you multiply 435 and 445 with 2, the difference will be 20 Hz. So, the bandwidth of the second harmonic is 20 Hz. So here a important rule of real instruments (esp. ensembles): the bandwith of each harmonic is proportional to the it's frequency; so in this example the first harmonic has bandwidth 10Hz, the second 20Hz, the third 30Hz, and so on. Here I made a very fine frequency analisys of a synthsized sound(a real orchestra sound will give similar results): [img]http://zynaddsubfx.sourceforge.net/doc/paul1.png[/img] You see, that the harmonic's bandwith increase according to their frequency. If you don't increase the bandwidth of higher harmonics, the resulting sound will be unpleasant especially on higher bandwiths of the first harmonic. So, not all quasi-periodic sounds are good, usually only if you increase the bandwidth of the harmonics. Now, what's happens if there are a lot of harmonics or the pitch of the sound is enough low? Let's see: [img]http://zynaddsubfx.sourceforge.net/doc/paul2.png[/img] The upper harmonics will merge to a single frequency band that will sound like a hiss, that is pleasent to the ear(eg. choir). I found that bandwidth of each harmonics can go even greater than 50 cents (quater of a tone) and still sound musical - I can give you some example wavs. Please note that this a different situation than 2 notes detuned by 50 cents (that sound very dissonand). Also, the best is that the phases are random. In real life this is ensured by the reverberation of the hall, for example if a instrument plays with a vibratto (a flute). Perhaps you noticed that always if more instruments plays the same note(as a enseble), the sound is very pleasant. I consider that this is the cause: the bandwidth of each harmonic. Unfortunately, there is very little on the internet about this stuff, because, I think, that are used more complicated paradigms (like some statistics on how sine harmonics modulates, or so). Now I want to give examples on how you can synthesize sounds, using this ideea. You can use zynaddsubfx or another synthesizer in most cases. Of course: I don't claim that I invented the bandwidth of each harmonic (or frequency distribution of each harmonic), because the ensembles, the choirs, the reverberations, exists since thousands of years (or more :) ). I just consider this a very important fact on how sounds are beautifull and it helped me to synthsize good sounds even since I was on highschool :D. You can make bandwidth of each harmonics by: 1) make more oscillators and detune them a bit (and a slight vibratto helps alot). Most synth use this and allows this, and perhaps it is known by you. This is one of the simplest method. This is implemented in ZynAddSubFX as "ADDsynth" module 2) generate white noise and filter each harmonics with a bandpass filter and mix the results. Be carefull to make higher harmonics to have higher bandwidth. This is implememnted in zynaddsubfx as "SUBsynth" module. 3) You see that above graphs. You can represent them as numbers in the frequency domain that represent the amplitudes of the frequencies, add random phases and do a SINGLE IFFT and voila! A very beautifull sound will "born". This new ideea is implemented in ZynAddSubFX as "PADsynth" 4) you can do other things, like a vibratto on a periodic oscillator and do a FFT to all sound, put random phases, and do a IFFT. For more information, I made few years ago a page that describes above things at: http://zynaddsubfx.sourceforge.net/doc_0.html Good luck. Paul __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com

20 years, 4 months

Re: [linux-audio-dev] LADSPA stereo-expander

by Stefan Turner

> Hi! > > Is there some kind of LADSPA plugin with stereo base > expansion > capabilities? > > Thanks! > Andrew > Is this what you mean: http://www.plugin.org.uk/ladspa-swh/docs/ladspa-swh.html#id1422 Stefan Turner ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

20 years, 4 months

[linux-audio-dev] [ANN] QjackCtl 0.2.15 released!

by Rui Nuno Capela

Hi, QjackCtl 0.2.15 has been released. As a major new feature you are now allowed to rename (alias) the JACK/ALSA connections client/port names to something intelligible. Another nice one is about actual ALSA hardware device names which are now presented for selection as a pull-down menu on the setup dialog. Grab it from: http://qjackctl.sourceforge.net As taken from the change log: - JACK/ALSA client and port name aliasing (renaming) is now an optional feature for the connections window; all client/port aliases are saved on a per preset basis (as proposed for Lionstracs' Mediastation). - Server state now shown (back gain) on the system tray icon tooltip; speaking of which, tooltips are now also featured on connections, status and patchbay windows. - New actual hardware device selection menu featured on setup dialog; these new button menus are only available for the ALSA driver settings. - Server path factory default to jackd instead of jackstart; preset setup button icons are back. - Fixed rare connection port item removal/disconnection dangling pointer bug. Have fun. -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

20 years, 4 months

[linux-audio-dev] LADSPA stereo-expander

by Andrew Gaydenko

Hi! Is there some kind of LADSPA plugin with stereo base expansion capabilities? Thanks! Andrew

20 years, 4 months

[linux-audio-dev] Trying to get midi input using OSS

by airplays55＠yahoo.com

I've been trying for months to get my midi input (using OSS/free) on a knoppix liveCD so that I can record midi in the included rosegarden2.1, and here is where I am now: I found a very short program that all it does is simply print out the bytes recieved at the midi input - its at http://ccrma.stanford.edu/~craig/articles/linuxmidi/input/section1.html My /dev/sequencer is working fine for output (verified with playmidi -e) however this program does not display any midi input. Actually what happens is BEFORE running the program, I verify that my Roland sound module (connected to the midi output of the midi cable plugged into the soundcard) DOES recieve input from the midi keyboard plugged into the midi input, BUT then when I run the program, the midi input is no longer passed through to the midi output. I've verified that the test program displays no midi input using /dev/sequencer, or /dev/midi, /dev/midi00 (I changed the device in the code) Here are the only steps I followed which succeeded in getting the ESS1868 midi output working. modprobe sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330 # OR dma16=-1 modprobe -v mpu401 io=0x330 irq=7 modprobe -v opl3 io=0x388 I guess that if I just get this sample program to display midi input, then I will be able to start using rosegarden2.1 to record midi? But why would the test program use /dev/sequencer for input (I thought /dev/midi was the input?) Why would my midi output (/dev/sequencer) but my midi input wouldn't work? here is the relevant output of sndstat: Synth devices: 0: Yamaha OPL3 MIDI devices: 0: MPU-401 0.0 Midi interface #1 Any advice would be VERY appreciated! __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

20 years, 4 months

[linux-audio-dev] support for non-root realtime scheduling; struggle continues

by Kai Vehmanen

Hello all, on lwn.net's latest kernel page, under 'Quotes of the week', there's the following message from Jack (O'Quin) to linux-kernel: --cut-- We argued that the owner of a Digital Audio Workstation should be free to lock up his CPU any time he wants. But, no one would listen. We were told that we didn't really know what we needed, and were asking the wrong question. That was very discouraging. It looked like LKML was going to ignore our needs for yet another year. --cut-- The whole post is at: http://lwn.net/Articles/121652/ I hadn't been aware of these latest developments. I then found also this: http://lwn.net/Articles/120797/ Really interesting stuff. I just want to say a big thanks to Jack for pushing the lad requirements forward! As we can all see from the mail threads, it has been, and still is, quite a struggle. In any case it's great that this has now got more attention also outside lad/lau and linux-kernel lists. -- http://www.eca.cx Audio software for Linux!

20 years, 4 months

[linux-audio-dev] aeolus with sse reverb code

by Karsten Wiese

hi, on my pIII laptop this gives 20% less cpu usage. patch is a bit intrusive still :) cheers, Karsten

20 years, 4 months

[linux-audio-dev] ignorance is bliss..

by mimo

I have a really stupid problem here and thought maybe you guys could help me improve my understanding.. I have a tiny audio program. It consists of two threads. The first thread uses the xinelib for audio output and reads its input from a fifo. The second thread creates a sine wave, "converts" it into WAV/PCM16 format and sends it to the fifo. After it has sent the first WAV/PCM16 chunk it keeps on looping but only sends the PCM part of the sine wave without the WAVE header. Now my problem: the second thread (=sine thread) uses a buffer where it generates the sine data. Once that buffer is full it writes the whole buffer to the fifo. What I experience is that what I hear depends on the size of this buffer. When I set the buffer size to 44100 samples (which I think equals 1 second of sound) then I hear a proper sine wave at the right frequency. When I change it to 22050 still ok. But once I choose for intance 11025 or 16384 or 8192 or 4096 I get strange stuttering, clicks or a somewhat modulated sound. So I thought the problem is my sine generator and compared the output using different buffer sizes. But it's the same no matter what buffer size I use. I can post some code too if that helps and would be grateful for any help. Thanks mimo

20 years, 4 months

[linux-audio-dev] cool plugin from Waves

by Paul Davis

http://namm.harmony-central.com/WNAMM05/Content/Waves/PR/Q-Clone.html

20 years, 4 months

[linux-audio-dev] Developing a music editor/sequencer

by NadaSpam

Sorry if multiple copies of this appear. The spam filter doesn't like my choice of titles. I've tried a few variations so far. I'm looking to develop a music editor/sequencer somewhat in the vein of Cakewalk/Rosegarden, but looking more towards the future of MIDI and audio capabilities. I've been thinking about this for a long time, and I think I have enough of a plan now to make a go at it. This is a rather long post, so I've divided it into four parts: Why Not Rosegarden?, Project Overview, Design Goals, and End Notes. Why Not Rosegarden? Why not just join the Rosegarden devlopment team? While Rosegarden has a lot of promise, it's design goal is different than what I'm thinking of. To put it crudely, Rosegarden's goal is to be a better Cakewalk. This isn't meant to be disrespectful to the Rosegarden developers. I like Cakewalk. (If you don't, substitute CueBase, or whatever professional tool of that genre.) Music is a language. While music itself is much more complex and vague (like natural language) than a programming language such as C, I will use the analogy of a programming editor. Rosegarden (and all similar tools) is like a C editor. When it's mature, it will be a very good C editor. In addition, the modularity and generalized approach that Rosegarden uses will make it possible to also be a good C++ editor. I'm thinking of something more like a multi-editor that will work for Perl or lisp. It will have it's own limitations, so I'm not trying to create the be-all end-all of music editors. But there are some fundamental things that Rosegarden will never be able to accomplish. (An most users won't have any reason to want an editor that will accomplish these things.) The first involves the way meter and tempo are handled. There are several pieces of 20th century music that incorporate 2 or more voices playing simultaneously in 2 or more meters. An example that chokes every editor I know of (though I'm told lilypond can do it with difficulty, but it has no sequencing capability and isn't a WYSIWYG) is Bartok's "Music for Strings, Percussion, and Celeste". I'm not saying that you can't create a Rosegarden file that will play this piece. What I am saying is that the notation will be extremely ugly. The issue is that not all of the voices are playing simultaneously in the same meter. To notate this in all in one meter means that some of the voices will look extremely complicated with myriads of ties and accent marks. Another interesting thing is to have 2 voices playing with different tempo. No examples come to mind, but I can think of some cool effects that could be achieve by having one voice race ahead of another. Again, Rosegarden could play such a piece, but the notation would be ugly. A third thing revolves around scales and tunings. Rosegarden has some plans for different tunings and perhaps support for quarter tones. And I think, again, that a Rosegarden tuning would be applied to an entire composition, not a single instrument. But I'm thinking of things more general. Suppose each track had an element called "tuning". Suppose also that each note is stored as an integer in a note event (as it is in Rosegarden). The tunings element contains a mapping between the note number given in the event and what is actually played. Microtones and temperaments could be stored in the tunings file as a MIDI note number plus a pitch bend. (Or we could store frequencies, and some function converts frequencies to MIDI note numbers plus pitch bends.) More novel things (such as octaves that aren't quite perfect frequency multiples) could also be accommodated. The tunings file could also be used to define scales that include added scale degrees. (e.g. for a Pythagorean tuning, we have to include extra values, so we can notate, say, an F## instead of a G, as these tones may not be equivalent in a non-equal temperament.) Rosegarden is trying to be fairly general about instrument definitions, which is good. I'm thinking of somewhat different approach that looks to the future of MIDI, in which we want to achieve more realism of the performance. Each Track has this abstract thing called an Instrument. Instruments may be atomic (a string) or composite (a guitar, which is composed of several atomic string instruments). Let's suppose we use soundfonts. We could create a soundfont with banks 1-6 for the strings of a guitar. Each single-string Instrument gets mapped to one of the tone banks, and the guitar Instrument is composed of these single-string Instruments. In this way, it would be possible to achieve a playback in which an open D chord sounds different than a 5th position D chord played a string lower, just like on a real guitar. Instruments should have "modes" which can be selected (and changed within the song). A guitar might have pickstyle (perhaps which eventually get mapped to tonebanks 1-6) and fingerstyle (which eventually get mapped to tonebanks 7-12). An organ could have modes for various configurations of the stops. We could get very elaborate here and have organs with multiple keyboards, etc., but I'm falling into a dreamy state here. The idea is that the design should allow for this type of functionality to be added. So, how can we accomplish such a beast? Let's take a tour of what's in my brain. No, no! Not over there! Don't open that door. That's the basement where all the beastly details hide. Whatcha mean it's empty? Of course it's empty. No, not that door either. That's the closet of confusion and inconsistency. This way, this way. Here's the beautiful entry... Project Overview No pretty pictures, so you'll just have to imagine. We begin with a main window. The document-view model is appropriate. We'll have the typical views that you'd expect -- TrackView, ScoreView (StaffView), MixerView, and some sort of EventView. TrackView should look similar to that of Rosegarden, but we need to implement it differently. The window needs to be some sort of split window, in which each track gets its own pane. At the top, should be a time ruler which can display in seconds, SMPTE, or beats/measures of a track. It should default to displaying beats/measures of track 1. Each track pane displays its clips similar to Rosegarden/Cakewalk. But it should hold a TrackGroup instead of a single Track (Byt default each Track is in its own group). Additionally, it should have a hideable ruler that displays time (default to beats/measures) and tempo markings for that TrackGroup. This means that the TrackGroup data structure needs to hold info about its meter and tempo. TrackGroups can be expanded to show each track. They can also be hidden to reduce clutter. TrackGroups can be nested (e.g. strings, violins, violin1). During playback, big vertical ruler bar should follow the sequencer, similar to the appearance in Rosegarden. ScoreView should display like a score with staff notation. Tracks can be grouped, and it should be possible to hide groupings. Expanded track groupings should show each track. When compressed, a single staff with multiple voices (1 for each track) should be shown. In this way, 4-part harmony, drums, etc. can be displayed as is most convient to the user. Tracks should be displayed with appropriate staves (single 5-line staff for voice, optional tablature for stringed instruments, etc.) Non-MIDI tracks such as wav audio should be displayed as a simple line or bar. We should include typical musical symbols, dynamics, guitar tab symbols, lyrics, section markers, and effects markers (things like echo, flange, etc.) Each track should have an option to hide various things (e.g. hide the tablature, lyrics, or effects markers). Eventually, we should be able to print out sheet music. The MixerView should be pretty typical, but again, with the ability to create a nesting of sub-mixers. Each track should get its own effects rack. Additionally, each sub-mixer (or track group) should get an effects rack. This way, we can set effects for individual instruments. Then we can layer another level of effects (say panning or delay) to a group. Finally, we can add a layer for everybody (say reverb). As much as possible, we shouldn't care whether we're dealing with wavs or MIDI. If we have a MIDI track, the popup menu should only display MIDI effects. For aggregate groupings, only effects that can be used on either MID or wave should be available. (Perhaps we can take existing MIDI or audio only effects and put wrappers around them that select which effect is actually used.) Supporting plug-in effects would be very good. In the end, though, I think effects should be handled in the same way as instruments. That is, we build complex effects out of simpler components. This leads me to instruments. Instruments and effects should be stored in definition files. Then we can set up our instruments once and use them in multiple compositions. Ditto for tunings. Files should be stored as XML (probably compressed, as Rosegarden does). Design Goals 1) Flexibility is paramount. A rigid desisn isn't going to work here. There are too many unknowns and open-ended issues. 2) Modularity. Keep the pieces as independent as possible. Try to make generic base classes that defer as much of the details as possible to derived classes. 3) Begin with a generic framework. Determine how the system should operate. Do we run the whole thing like an IDE for a programming language? How separated should the editor and sequencer be? Do we edit, save to file, and compile (sequence)? Or should the sequencer be more closely coupled, causing the data structures in memory to be shared between editor and sequencer? The first approach would make it difficult (or impossible) to do realtime mixing of MIDI tracks, but it would provide for very efficient playback. All of the MIDI tracks would be compiled to a MIDI file, so the on-the-fly processing would be minimal. Efficient, but limiting. Perhaps it should run more like an interpreter, processing the file on demand. A "mixdown" option could be added, that would compile everything down for a final release. Then anyone with the sequencer could play the file. (Analoguous to Windows Media Player, in which you can play .avi files, but you can't create or edit them.) 4) Simple things should be simple. The default should be that every track plays at the same tempo and in the same meter, instruments should map to General MIDI bank, and equal-temperament tuning with standard key signatures should be used. Recording, playback, and basic editing should be easy and intuitive. The most common features and feature groupings should appear in the menus. An advanced tab should be present to allow for lesser uses features. 5) Don't lose sight of the big picture. The end goal is to have a product that allows for audio and MIDI tracks that will play in sync. Other types of tracks (such as video, or images) could be included as well. 6) Get something that's useful and provides basic functionality up and running quickly. Add features step by step. A brilliantly conceived program isn't worth much if it doesn't run. 7) I'm leaning toward C++ as the primary language, though it may be better to use a scripting language such as Perl (which I know) or Python (which I don't know) for certain portions. My most common methodology involves writing a core engine in C++, then developing a simple scripting language (usually in Perl) to access the features of the core. I'm not sure such an approach is appropriate here, though. End Notes for the Curious I used to be a software designer and programmer. I've been stagnant for several years now due to an illness that's taken away my presenability in job interviews. (It's hard to make a good impression in today's world of corporate fluff where appearance is more important than ability when you look haggard, shake like an addict in detox, and have periods of brain fog that never fail to appear in an interview.) I don't know all that much about the down and dirty of audio programming. I wrote a little media player tool with DirectX in Windows, a linux tool that converts files between MIDI and XML (I should probably stick this out there one SourceForge, as someone else might think it useful. How do I do that?), and a few other little audio utilities. I know a good deal about software design and maintenance, and I'm proficient in c++ (and a few other languages as well). I've been project leader on a few different pieces of software of substantial (100k-200k lines) size, with teams of 10 people of less. My degree is in applied mathematics. For any university professors out there, I think this would be a great master's (or phd) thesis. And I just might know a pretty good candidate. ;)

20 years, 4 months

Jump to page:

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