Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

[linux-audio-dev] Old tracks finaly recorded and mastered

by Thorsten Wilms

Hi! Finaly got around to record a number of old tracks that I created using nothing but a GEM S3 keyboard in 1997/98 (well, and my brother's PC for selecting samples and putting them on a floppy for importing). Previoulsy they only existed on floppy and tape and one floppy is corrupted already ... Still in the process of loading them up to archive.org, but some are there by now: In order of my own rating, best at the top: http://www.archive.org/download/s3_07_the_darkness_surrounding_me/thorwil_s… http://www.archive.org/download/s3_06_multibeatmode/thorwil_s3_06_multibeat… http://www.archive.org/download/s3_05_leaving_it_all_behind/thorwil_s3_05_l… http://www.archive.org/download/s3_04_red_sun/thorwil_s3_04_red_sun.ogg http://www.archive.org/download/s3_02_rave_scales/thorwil_s3_02_rave_scales… http://www.archive.org/download/s3_03_blue_beat/thorwil_s3_03_blue_beat.ogg http://www.archive.org/download/s3_08_where_do_i_want_to_go_today/thorwil_s… The detail pages can be reached from here: http://www.archive.org/search.php?query=creator%3A%22Thorsten%20Wilms%22 I wouldn't mind people writing reviews there ;) All recorded using the focused Timemachine. Cutting and normalizing with the most enjoyable Sweep. Mastering with the amazing Jamin. Need to practice that some more :). I wasn't aware of how much details can be brought to light using compression. The only problem was having to convert the 32bit float WAVs to 16 bit for lame, as it doesn't recognize that format. I used sndfile-convert for that. Too bad it doesn't take a flag for the output format, but requires filenames for that. But thanks to the nice folks at #lad, it didn't take long to arrive at a bash oneliner for converting a whole directoy. --- Thorsten Wilms

20 years

[linux-audio-dev] Re: snd-usb-usx2y on amd64? - Success (more or less)

by Arnold Krille

Hi all, just a note: A got it more or less working. This morning I installed the vanilla-2.6.14-rc4 and I could start jackd in realtime with -n6 -p256 and run ardour and qsampler/linuxsampler in parallel without an xrun during normal operation. It just crashed jackd when I used -n6 -p128 but even after that it didn't ruin the sounddriver so I could start jackd again. That really takes a big stone from my heart as I have to do some serious music with the laptop this weekend and I feared I had to mess around with my old one... So thanks for your patience, 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.

20 years

[linux-audio-dev] Fixed vs. floating point

by cpolymeris＠gmx.net

I am in the early planning stage of an audio processing application and I have come to the point of making the choice between floating point or fixed point (signed 2's complement) processing. What do you think is better, and why? Why does jack use floating point? Why does AES use fixed point in most of their standards? I understand the technical difference between the formats, but... I can't come to a conclussion. The adavantages of floating point I see are: - easier processing, specially amplification and mixing (multiplying by fractions) - more sse support, more packed array arithmetics - relationship to voltage and SPL easier to understand. (1.0f vs. 2^31-1 max. values) And its diadvantages compared to fixed point would be: - generally slower, specially things like addition - 30 bits of resolution for 32 bits of data in IEEE single-precision (exponents larger than 0 not used for audio, neither are denormalized numbers and redundant zeroes, infinities, etc), compared to the full 32 bits of resolution of fixed point. - non-linear saw-tooth-like precission (precission gets higher as mantissa gets larger and then falls abruptly at the point the exponent is increased) I am sure I fail to see the more important points and would be thankful for any comments. If it has been discussed on the list earlier, i am sorry to post it again. I couldn't find it. Greetigs, Dimitri -- NEU: Telefon-Flatrate f�rs dt. Festnetz! GMX Phone_Flat: 9,99 Euro/Mon.* F�r DSL-Nutzer. Ohne Providerwechsel! http://www.gmx.net/de/go/telefonie

20 years

[linux-audio-dev] Re: [ardour-dev] Proposed editing mode, for users with heavy editing needs

by Mike Fisher

Like said before good ideas. One thing that I agree with is to have the playhead snap to the beginning of a region when it is clicked on. This really would speed up the editing process. Maybe something like this could be toggled on or off in the options window. Another thing is in range mode. I'd like to have it so when you select a range that it would play that range just by hitting spacebar or play from the transport. As this would elimiate two mouse clicks. Seems small but it really. Maybe have this in the options window as well. Also in range mode. Move the play head with a single click would save alot of editing time. I know that if you hit p this will happen whereever the mouse is, but just clicking would be alot quicker. I'm not complaining about the existing operations. Ardour is awesome. I just like to be able to make quick edits. And eliminating clicks and keystrokes may not seem like much. But when you make possible hundreds of edits a day, it makes a huge difference in time. --- AES_24_96 <pipelineaudio(a)hotmail.com> wrote: > edit mode > > I propose an edit mode or maybe its a mouse mode > that would > allow editing tasks to be performed with MUCH higher > speed > and quite a few less keystrokes. A similar scheme > has been used > before to create an app with exponentially less > clicks and > keystrokes to perform many editing tasks than any > other. > > In this mode, playback cursor and edit cursor would > be > one and the same, a VERY skinny line that drops, and > stays > wherever you left click the mouse in the edit > window, either > on the ruler or on a region itself. > > Windows type conventions would apply to the > selection process. > Click a region, then shift click another region, and > those two > regions plus any region in between would be > selected. click a > region and control click another region for > selecting non > contiguous regions, and keep control clicking till > you have > selected all the regions you want. Click a fader and > shift click > or control click another fader to move multiple > faders at once. > > Simple stuff, some of which Ardour already has, m to > drop a > marker, s to split, r after making a range selection > to define a > storable range. "g" groups all selected regions > together, > whether on the same track or not, u ungroups > selected regions. > > Let me flesh some of these out a bit. For grouping, > all grouped > tracks would be moved as one of them is, either in > time or > between tracks. As groups overlap each other they > would be > auto-crossfaded where relevant, according to the > already > excellent Ardour autocrossfade options. Very > importantly, > there would be a "overide group" button in the > Ardour menu > bar, to perform actions on regions without bothering > other > regions grouped with them. Turning the button off > would > restore the group action. > > Splits can be made in several ways. Clicking on a > region and > hitting s will split right where the cursor sits. > Clicking in a > trackspace without a region in it, or along the > ruler then hitting > s will split all regions under the cursor. Dragging > a range > along the ruler then hitting s will put a split at > the very > beginning and end of the selected range. Selected > regions, > selected by click shift click and/or click control > click as > described above would also be split by hitting the s > key. > > Region editing would be similar to the way ardour is > now. > Resize by clicking and dragging on edges (would > group with > groups and selections). Control-click and drag on > edges will > time stretch or time compress, also groupable with > groups and > selections. Click dragging on the top edges of > either side will > control the fade in or fade out handle, same as > now. Click > dragging on the very top middle area of a region > would control > a per region volume trim. Right clicking a region > will bring up > a menu including things like reverse region, and > open copy of > region in audio editor. > > Mouse wheel editing would be somewhat different. > With no > modifier, scrolling the wheel will zoom time in and > out, > keeping the zooming centered around the cursor. In > the event > that zooming goes too far to keep centered, it will > go back to > the cursor center upon zooming back in. > > Snapping: Right clicking the "snap to" button brings > up a speed > menu where you can select whether to snap to ruler > marks > ( as defined in the ruler speed menu), time, SMPTE, > measures, half notes, quarter notes, 8th notes, 16th > notes, > 32nd notes, 64th notes and 128th notes). Holding > shift while > dragging a region overrides snapping. The "show > grid" next to > the snapping button will show a grid *VISIBLE > THROUGH > REGIONS* with its points set according to the "snap > to" > speed menu. > > Time display: Somewhere on ardour will be a time > details > screen. Top bar will show the timestamp of the > beginning of a > range selection. In the event of no range selection, > this will > show the timestamp at the cursor. The middle bar > will show > the timestamp at the end of the range selection. The > bottom > bar will show the duration of the range selection. > The main > time display as Ardour has now can be right clicked. > In the > speed menu that pops up, you can select between > SMPTE, > MTC, time(hour, minutes, seconds, miliseconds), > samples, > and musical time( measures, quarter notes, 8th > notes, etc...). > Separately the ruler can also be right clicked to > display the > same options. > > More to come, but I think with these basics ardour > would be > more than workable for those of Linux Noobs us who > have > been abandoned by our parent software company. > > I know it sounds like a lot, but I think this would > certainly > result in many fewer commands to accomplish the same > actions we have now, and actually be simpler to work > with > and use. > > _______________________________________________ > ardour-dev mailing list > ardour-dev(a)lists.ardour.org > http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org > __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/

20 years

[linux-audio-dev] Documentation of the PADsynth synthesis algorithm

by Paul

Hi. I am Paul, the author of ZynAddSubFX software synthesizer. I wrote a complete documentation of how the PADsynth synthesis algorithm works. It includes the full description of the algorithm: overview, text description, diagrams, pseudocode; example C/C++ implementations and a ready-to-use C++ class. Also, I included some audio examples into the page. Please tell me your opinion about it. I tried to make it to be easy understood and ready to be implemented and/or used into your software synthesizers. Everything (the algorithm, the examples, the implementations, diagrams,etc) from this page are released under Public Domain. You are welcome to include and use this into your programs and I invite the companies/developers who write software synthesizers to use it. Also, I guess that the sound banks producers will be very interesed about this ;) I don't require anything for using it ;-) ; I just want this to be spread, to be used to make beautiful sounds. It's page is at: http://zynaddsubfx.sourceforge.net/doc/PADsynth/PADsynth.htm Enjoy! Paul __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

20 years

Re: [linux-audio-dev] Documentation of the PADsynth synthesis algorithm

by Kjetil S. Matheussen

Paul: > Hi. > I am Paul, the author of ZynAddSubFX software > synthesizer. > I wrote a complete documentation of how the PADsynth > synthesis algorithm works. It includes the full > description of the algorithm: overview, text > description, diagrams, pseudocode; example C/C++ > implementations and a ready-to-use C++ class. > > Also, I included some audio examples into the page. > Please tell me your opinion about it. Wow, this is great work! Especially this one is so impressive: http://zynaddsubfx.sourceforge.net/doc/PADsynth/demos/0km.ogg --

20 years

[linux-audio-dev] file format

by fons adriaensen

Hi all, For one of my current projects (to be presented at LAC2006) I'm looking for a suitable file format. Each file should contain: - A number of short (+/- 10 seconds) chunks of PCM audio. The number of channels will be different in each chunk. The only sample format required is single precision floating point. For multi-channel chunks, non-interleaved is preferred. All chunks will normally use the same sample frequency. - Metadata, both numerical and textual. The format should allow to have several chunks of these, and to add new ones later without breaking compatibility (i.e. readers will ignore parts they do not understand). There is no need for the audio to be usable with normal players - it's not meant to be listened to directly. Is there any standard file/container format that would provide for this sort of thing ? I've been looking at ogg, but it's a bit over the top - I don't need any streaming features. The alternative is of course to have separate WAV files and some text file for the metadata, and combine all of this into a directory that would then be handled as a unit. But I'd prefer to have all data in a single file. -- FA

20 years

[linux-audio-dev] Help on csound real time front end project?

by Iain Duncan

Wondering if anyone on hear is interested in working with me on my c/c++ front end for real time improvisation using csound5 as the audio engine. The concept in a nutshell is like a cross between say Doepfer step sequencers ( or Softwerk ) and Ableton live, except multi user and designed for speed and improvisation and a more musician oriented way of thinking. Proof of concept has been done and used on gigs, now it is time to do it properly in C/C++. I think my c/c++/fltk/midi/csound api chops are up to the point now of making a usable framework that will be useable for a serious sequencer, but I am definitely more of a designer then experieced coder, so it would be great to collaborate. if there is interest I can start a list and site for this. Feel free to contact me here or off list. Thanks Iain

20 years

[linux-audio-dev] Re: [linux-audio-user] Smack 0.2 released.

by federico

federico ha scritto: > Loki Davison ha scritto: > >> Hi all, >> Smack 0.2 is now out. Smack is a drum synth, 100% sample free. It's >> built with LADSPA plugins and the Om modular synth. New in this >> release are Noise and resonate filter based metallic percussion, ring >> modulation based drums, velocity sensitivity, control ports for all >> drums and random other goodness. Get it at http://smack.berlios.de/ >> There are also some new sound demos on the site including a physical >> modeling based djembe. The gui is no longer included due to huge >> improvements with om_gtk, and lack of time for maintaining it. Please >> just use om_gtk or the emacs bindings. >> >> Cheers, >> Loki >> >> >> >> > i got this error trying to load some of your patches: > > ERROR: Unable to make connection > /808kit/808hihat/midi_trigger_in0/Gate -> > /808kit/808hihat/adenv_lvl_0/Reset Level > ERROR: Unable to make connection > /808kit/808hihat/midi_trigger_in1/Gate -> > /808kit/808hihat/adenv_lvl_1/Reset Level > ERROR: Unable to make connection /808kit/808hihat/OH gate/in -> > /808kit/808hihat/adenv_lvl_0/Reset Level > ERROR: Unable to make connection /808kit/808hihat/CH gate/in -> > /808kit/808hihat/adenv_lvl_1/Reset Level > ERROR: Unable to make connection /909bass/midi_trigger_in0/Trigger -> > /909bass/adenv_lvl_0/Reset Level > ok i solved the errors above by installing omins-cvs. but still hear no sound. i lift up all volume slider, twiddled with sliders, checked that all the output are connected to a soundcard output, and checked that for midi connections too. there aren't any error message in the om console and in the om_gtk console, except (om_gtk:21016): Gtk-CRITICAL **: gtk_range_set_range: assertion `min < max' failed, but everything seems to work fine, except for the audio :| > i see the audio outputs and the alsa input (triggers), i send midi > notes to them, but it doesn't output any sound. > > can you help me? >

20 years

[linux-audio-dev] [ANN] DSSI 0.9.1 release

by Sean Bolton

Announcing the DSSI Soft Synth Interface version 0.9.1 release: http://dssi.sourceforge.net/ DSSI is an audio plugin API for software instruments and effects, based on LADSPA, the ALSA sequencer event types, and OSC (Open Sound Control) communications. This release does _not_ contain any changes to the DSSI API itself, which has been stable now since the 0.4 release fifteen months ago (with minor additions at 0.9). Instead, it contains numerous clarifications to the specification and documentation, and the included reference host and example programs have become significantly more robust. Specific changes in 0.9.1 include: - The distribution now has a full autoconf/automake/libtool build system. - FluidSynth-DSSI has been moved into its own package, and no longer depends upon the FluidSynth source. - The reference host, jack-dssi-host, now supports plugins with audio inputs, as well as LADSPA-only plugins (with or without custom DSSI GUIs.) Available hosts and plugins --------------------------- More exciting than the changes in this release, is the recent growth in DSSI implementations. Items marked with '*' are new since the DSSI 0.9 release. Available hosts are: - jack-dssi-host, included in the DSSI distribution - the Rosegarden 4 sequencer * Om, a modular synthesizer * ghostess, a lightweight GTK+ host * dssi~, a Pure Data external Efforts are underway to add DSSI hosting to: - the MusE sequencer * Csound5 * GNU Classpath Available plugins include: - the simple synths and sampler in the DSSI distribution - FluidSynth-DSSI, a soundfont-playing plugin - Xsynth-DSSI, an analog-style synth - dssi-vst, a wrapper plugin enabling the use of many Windows VST plugins - hexter, a Yamaha DX7 modeling plugin * ll-scope, an oscilliscope plugin * Sineshaper, a waveshaping soft synth * dssi_convolve, a DSSI wrapper around libconvolve * xy-controller-dssi, a GUI controller plugin which translates mouse input into X-Y control outputs * WhySynth, which offers a number of synthesis methods The Future ---------- In the year and a half since its initial introduction, DSSI has met a number of challenges to its adoption: the continued (perpetual?) forthcomingness of GMPI, apprehension about adopting a standard with 'Disposable' in its name, some "wait and see if takes off" attitude, and numerous gripes that it won't do this or can't do that. Even so, the creative potential available through DSSI today is great. In part due to this success, there has been a noticable commitment voiced in recent discussions on the DSSI email list to keeping any future enhancements backward-compatible with the existing DSSI API. In the author's opinion, this indicates DSSI will continue to be a stable API, at least until such time as a '2.0' version is considered. With regard to possible future enhancements, interest has been highest in two areas: providing plugins with transport position and tempo information, and allowing plugins to send MIDI data. If you're interested in helping shape these or other developments, please join us on the DSSI discussion list.

20 years

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