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.
--
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)
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.
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
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
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 ...
>
>
>
>
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
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
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
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..\\\