Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

[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. --

19 years, 9 months

[linux-audio-dev] ANN: Csound 5.00 Release

by Istvan Varga

After what has seemed a very long time (because it was...) we are releasing csound5.00 The binary, manuals and source files are on http://sourceforge.net/projects/csound and look for the csound5 files. The opportunity has been taken to tidy up the assembly of csound4.23 and earlier files and we are leaving the 4.23 files for a short while. Main message -- everyone should change to csound5. More robust, faster, more facilities, more fun, more music. ==John ffitch Release Notes for Csound 5.00 ----------------------------- The developers are very pleased to be releasing Csound5, for Linux (32 and 64 bit), Mac OSX and Windows, together with an uptodate manual. The system can be downloaded from http://sourceforge.net/projects/csound More details and further information can be found in the csound-devel mailing list at sourceforge and the main user mailing list at csound(a)lists.bath.ac.uk The changes from version 4.23 are extensive. The internal structure of the code has been radically changed, but the language remains compatible with Csound4, and all old orchestra/scores should run unchanged. The main visible change is that we are using a plugin style of system. Many of the opcodes are now loaded at start-up. This opens the way for private opcode libraries, and opcodes released under other licences than LGPL. The other major change is a move to the use of external libraries where possible. All the internal code for sound files, realtime audio etc has been replaced. We are now using libsndfile for audio file I/O, and one of ALSA, PortAudio, CoreAudio, MME or ASIO for realtime. MIDI may be handled by PortMIDI as well. The incorporation of Open Sound Control facilities uses the liblo library. A number of opcodes from csoundAV and csoundVST are now part of the main system. Another major change is that Csound5 is embeddable in other programming systems, using an API for information linkage. We are including Python, Java and other bindings for the API. Csound5 can also have multiple instances and is re-entrant. In addition there are a number of new opcodes, and of course bug fixes. We believe that csound5 is faster than csound4, and we encourage all users to move to it. NOTE: IT MAY BE NECESSARY ON SOME PLATFORMS TO HAVE EITHER ENVIRONMENT VARIABLES OPCODEDIR OR OPCODEDIR64 SET TO POINT TO DIRECTORY WHERE OPCODES LIVE. THE RELEASED FILES ARE BELIEVED TO BE SAFE AND CORRECT IN THIS RESPECT BUT BEWARE! New features: ------------ Access to multiple ALSA devices FLTK widgets reworked and synchronised with csoundAV User defined gens with names (rather than numbers) --expression-opt command option Information on time for each phase of csound if required Command line options to set ID tags in output soundfile (title/copyright etc) Jack available as output device --sched option now accepts a priority value -+rtaudio option to select output system Many new command line options Utilities to create csd files from orc/score Tcl/TK frontends (cstclsh and cswish) Can use looping structures in WAV files as well as AIFF Increased number of possible input and output audio file formats named channels #ifdef in orchestra removed limitation of only one track in MIDI input files MIDI output can also be written to a file (this is somewhat limited) MIDI-style extra time and release (xtratim, linsegr, etc.) is now also possible with score notes string variables (of type S) automatic conversion of some C-style escape sequences (\n, \r, ASCII code in octal \ooo format, etc) in string constants made internal indexes to orchestra variables 32 bit (was 16 bit in Csound 4), allowing for larger and more complex instruments replaced old PVOC format with PVOC-EX in all related opcodes SADIR SSDIR and INCDIR can now be a sdemicolon separated list of directories New Opcodes: ----------- maxk tab, tabw, and tb0()..tb15() vst4cs plugin opcodes pconvolve ftconv loris opcodes Python opcodes fluid opcodes chani and chano; chnset and chnget (string indexed) GEN43 a number of pvs (streaming phase vocoder) opcodes moogladder statevar fofilter syncgrain miditempo event_i reverbsc (Sean Costello's waveguide reverb) freeverb gentune GEN operation GEN51 GEN52 diskin2 turnoff2 a-rate int() and frac(), and round(), floor(), and ceil() << and >> operators STK (Perry Cook) instruments available from original code k() function Mixer opcodes OSCrecv, OSClisten, OSCsend loop opcodes printf, printf_i string hacking opcodes Bug Fixes: --------- Error in tablew fixed Minor fixed in dcblock Include files were confused by sections Improved reading of command line Fixes in dynamic fgen numbers gogobel and vibraphone amplitude fix Arguments to schewhen were wrong Better checking in bqrez minor checking in grain wguide2, wguide1 avoid very low frequencies wgpluck bug fix Some error messages corrected and typos fixed FLsetVal arguments were wrong outo missed out channel 6 fixed bugs and improved error reporting in ^+ and ^- code. kread, kdump and a number of other opcodes will take string arguments from the score bug fix in sinc window (gen20) Added iskip options to moogvcf, vco, bqrez, pareq, tbvcf and rezzy values rounded rather than truncated in deltap, comb, and delay removed spurious initial values from some MIDI opcodes Joystick was upside down lpshold and loopseg changed to agree with csoundAV marimba now allows zero probability of a multiple strike Added skipinit argument to diskin and soundin wave-terrain fixes for phase error accumulation (on long notes) new optional argument to delayr and all deltap opcodes, to allow delay taps to read from any of the nested delayr/delayw pairs, not just the last new optional argument to distort1 opcode (defaults to zero), to select amplitude scaling mode (0: default, compatible with original version; 1: relative to 0dBFS, same as mode 0 if 0dbfs is 32768; 2: unscaled) valpass fixed parameter overwriting Improved accuracy in some filters Improvements in bowedbar JPff -- 1 Feb 2006 Files on Sourceforge ==================== Sources: Csound5.00_src.tar.gz Csound5.00_src.zip Csound5.00_OS9_src.smi.bin Csound5.00_src_all.tar.gz (including Loris and STK code) Csound5.00_src_all.zip (including Loris and STK code) Manual Csound5.00_manual_chm.zip Csound5.00_manual_html.zip Csound5.00_manual_pdf.zip Csound5.00_manual_pdf_A4.zip Csound5.00_manual_single_file.zip OS9: Csound5.00_OS9.smi.bin OSX: Csound5.00_OSX10.3.tar.gz Csound5.00_OSX10.4.tar.gz Linux Csound5.00_i686.rpm Csound5.00_x86_64.rpm [Linux for non-root users Csound5.00_x86_64d.tar.gz Csound5.00_x86_64f.tar.gz ] Windows Csound5.00_win32.i686.zip Csound5.00_win32.exe (with installer)

19 years, 9 months

[linux-audio-dev] beatfish (codedump :)

by Conrad Parker

Hi, a few years ago I made a drum machine with scrubbing, and showed it to some people at the LAD booth at LinuxTag 2003. Recently (at linux.conf.au 2006) I realized I've sat on the code and not released it. This is not a "release", but a challenge; here's some code, and some instructions for building it: http://trac.metadecks.org/wiki/BeatfishInstall Beatfish is built on libremix (which is also not-quite-released; I'd like to freeze the API sometime this year though ;-) and Evas (a very high performance graphics canvas built for Enlightenment 17). The plan is to make a way of developing cute music machines, using DSSI and all that's good. For now, beatfish is a pretty basic Jack toy. enjoy :) Conrad.

19 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

19 years, 9 months

[linux-audio-dev] Re: [linux-audio-user] rosegarden dssi problem

by Emanuel Rumpf

Chris Cannam wrote: >On Tuesday 24 Jan 2006 13:17, Emanuel Rumpf wrote: > > >>The problem occures on all files, that have dssi-plugins assigned. >>Here is a simple test file with a track "bass" that has the "Less >>trivial synth" applied. >>If I open and play it, there is no sound. >> >> > >I can't reproduce this at all. The example file works fine for me. That's >rather troubling. > >Did you build this from CVS yourself? Are you in a position to build it again >with some debug output enabled? If so, I'd like to see what is printed by >the sequencer process when the two lines > >#define DEBUG_DSSI 1 >#define DEBUG_DSSI_PROCESS 1 > >at the top of sound/DSSIPluginInstance.cpp are uncommented. > > >Chris > > > Did the output I've sent help somehow? Has anyone else reported a similar problem? If this is related to my system only, do you have any idea why/how this could be? Dssi is working on my system, also in rosegarden, only when loading a new file, the tracks with dssi-plugins are muted somehow... then I have to re-assign the plugins for each track for the sound to come back. Emanuel

19 years, 9 months

[linux-audio-dev] Re: [linux-audio-user] LAD site, linuxdj.com needs a new home

by Benno Senoner

I mailed Paul the link to fetch the whole LAD web tree and files, about 5.7GB ( the content that was on www.linuxdj.com/audio ) next step should be deciding wheter to put the content on a nicer domain. ( and having linuxdj.com/audio redirect to that domain/site so that search engine and website links get redirected to the correct place). I'll wait for Paul's reply how to proceed (redirect linuxdj.com etc). cheers, Benno Paul Davis wrote: >On Mon, 2006-01-30 at 17:44 -0500, Paul Davis wrote: > > >>On Tue, 2006-01-31 at 01:10 +0100, Esben Stien wrote: >> >> >>>Benno Senoner <sbenno(a)gardena.net> writes: >>> >>> >>> >>>>consumes so much bandwidth >>>> >>>> >>>Why don't we put these videos on archive.org?. >>> >>> >>I currently have 1870GB/month bandwidth, and it climbs by 16GB/week >>right now. Last month, I used 0.1% of my bandwidth. Its not an issue. >> >> > >lets get this transfer started ... > > > >

19 years, 9 months

[linux-audio-dev] LAD site, linuxdj.com needs a new home

by Benno Senoner

Hi LADers, During the last months the LAD website ( http://www.linuxdj.com/audio/lad ) was hosted on the lionstracs.com server. Domenico from Lionstracs told me that he does not want do host the LAD site anymore since it consumes so much bandwidth, 200 GB in January, see here. http://www.linuxdj.com/webstat1/ its probably due to the audio/video material from the conferences (100MB a pop). Anyone willing to host the site ? As I did in the last years, I'll pay the for the linuxdj.com domain fees. cheers, Benno

19 years, 9 months

[linux-audio-dev] Launching DSSI GUIs via OSC?

by mlang

Hi. Is there anything planned for the DSSI standard which would allow DSSI hosts to launch GUIs just by sending a OSC message to some kind of GUI launcher? I am asking because I'd like to write a whysynth frontend in SuperCollider Language. That should be all doable, since the whole GUI->DSP->GUI process happens over OSC. Now there is only the session initiation left. I know its pretty trivial to write a wrapper WhySynth_osc which just sends off its argv to SCLang via OSC, but this feels kind of clumsy to me. In fact, for what I'd like to do, it would be quite pretty if jack-dssi-host just had an additional command-line argument which would tell its startGUI routine not to call exec, rather send the 4 strings to the specified osc url. $ jack-dssi-host -o osc.udp://localhost:57110/dssRequestedI/ whysynth.so How does this sound to you, worth a patch? Or should this really be done with wrappers, ugly as they may be? -- CYa, Mario

19 years, 9 months

[linux-audio-dev] Re:LAD site, linuxdj.com needs a new home

by Maluvia

On 1/30/06 Paul Davis wrote: >i have the space and capacity to host this at dreamhost under my >account. start the ball rolling. I think this would be the best solution - it will keep Paul with us for a long time to come. :) >btw, i happen to think that the current website is ugly and a mess. it >would nice if some people could spare several hours and clean it up to >make a really useful resource for people interested in linux audio >development. Agreed. -Maluvia

19 years, 9 months

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

by cdr

i know design by committee can be horrible but these situations usually utilize vastly similar yet incompatible formats, so its sort of biting off something small, i hope.. :) (1) Peak Files some of my favorite wav files have 10 metafiles each. peaks generated for peak, spark, wavelab, soundforge, cubase, ableton live, samplitude, rezound, sweep, ardour, plus a dir for "Apple Loops" data etc. it would be great if each time an audio file enters a new app, the user wasnt greeted with a 30 second burst of disk activity as peak files were generated yet again..what exactly is needed? here are some thoughts - average amplitude per time-slice to generate the waveform overview * what granularity is useful? peak files seem to run a few % of filesize.. - spectral centroid for comparisonics/freesound style colorization - annotations (OPML etc) - timing (tempo, cue points, beat markers) rather than invent some new arbitrary plaintext (or XML) format, i'm interested in using OSC (as described at http://www.cnmat.berkeley.edu/OpenSoundControl/OSC-spec-examples.html ) to encapsulate this data, at which point this is simply an exercise in selecting a schema/namespace... beside faster load-times (eg one could pregenerate this data before a performance or composition session via a recursive shell command and 'sox'), a commonly understood format would enable easier sharing of CC-licensed material among a variety of users and apps without useful metadata being 'lost in translation'. additionally web and other interfaces could be developed using the metadata hints (see archive.org, NI's KORE) (2) Instruments compatibility and reuse of sample-based instruments between chionic, specimen, DSSI samplers, PD samplers, LinuxSampler, and seperation between editor and engine allowing more highly specialized apps - the 'nix way. - get rid of arbitrary region / bank / instrument boundaries which seem derived from MIDI (the amount of times you see 1-16 and 0-127 in modern software instruments is appalling) - sample regions pointing to audio files or groups - grouping (nesting / tags) - volume / filter / lfo stuff once again i am thinking OSC could be suited to this.. (3) 'project' components monolithic binary files still seem to remain the norm, eliminating all hope of reuse without tedious exporting of settings or components, things like: - pointers to regions (audio files, control streams, other projects) - note and controller-data streams - instrument / filter settings ive thought about this a bit and am leaning towards using a directory on disk, with a format for each of the above, which would enable revision tracking via SVN or darcs.. note/control data will likely be OSC (and MIDI encapsulated in OSC where necessary), instrument/filter settings would be closely aligned with what is fed to LADSPA/DSSI modules, and the pointer 'glue' file linking others and assigning filter and routing data to tracks, channels, regions..\\\

19 years, 9 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