Re: [linux-audio-dev] ANNOUNCE: Sonic Visualiser and Vamp plugin SDK 1.0pre3 released
On Tue, Mar 20, 2007 at 10:12:17AM +, Chris Cannam wrote: > On Tuesday 20 Mar 2007 00:41, Paul Winkler wrote: > > On Mon, Mar 19, 2007 at 11:28:40PM +, Chris Cannam wrote: > > > Sonic Visualiser is an application for viewing and analysing the > > > contents of music audio files. It contains advanced waveform and > > > spectrogram viewers, as well as editors for many sorts of audio > > > annotations. > > > > What does "annotations" mean in this context? > > That's a good question. (snip) Thanks for the explanation, this is very cool stuff. Should be useful next time I have to transcribe something with a particularly baffling rhythm. -PW -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] ANNOUNCE: Sonic Visualiser and Vamp plugin SDK 1.0pre3 released
On Mon, Mar 19, 2007 at 11:28:40PM +, Chris Cannam wrote: > > Announcing the release of Sonic Visualiser 1.0pre3, a pre-release for > the soon forthcoming Sonic Visualiser 1.0. > > http://www.sonicvisualiser.org/ > > Sonic Visualiser is an application for viewing and analysing the > contents of music audio files. It contains advanced waveform and > spectrogram viewers, as well as editors for many sorts of audio > annotations. What does "annotations" mean in this context? -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-user] Re: [linux-audio-dev] Hunt for old list archives.
On Thu, Feb 22, 2007 at 07:44:46AM -0500, Ivica Ico Bukvic wrote: > > As far as I know, there are only the 21 messages from 1998 available > > anywhere. As for 1999, the archives present 2 copies of the same 801 > > mesages from May 1999 through 07 March 2000: > > http://lalists.stanford.edu/lad/1999/05/ > > http://lalists.stanford.edu/lad/2000/19991108-0307/ > > > > This is sort of explained in this thread: > > http://lalists.stanford.edu/lad/2000/Mar/0001.html > > Kai recreated the archive using his mbox starting from the day he > > joined around June 1999. The messages from before that day must have > > come from someone else ... > > Got it. So, do we have anyone else who falls under the heading of "someone > else" who could fill-in the gaps? Dave? I thought I did, but I don't. However, I do have a script that removes duplicate messages from an mbox, which you might find useful for those 801 duplicates. Let me know if you need it. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Python
On Wed, Feb 07, 2007 at 11:57:10PM +0900, David Cournapeau wrote: > tasks. For once, the current implementation relies heavily on dynamic > memory allocation, which makes it hard to control what happens when > memory wise. Whether this is inherent to the language itself, or its > implementation, I don't know, thi is beyond my knowledge. Well, the language itself is highly dynamic, you can rebind pretty much anything to any type of object at any time, so the runtime has to be pretty flexible. > Could be intereseting to ask to the pypy's folks about the possibility > of having a real time capability to python (pypy is an implementation > of python in python, with the goal to have a flexible implementation, > this making changin many key points of python "easy". It's not just flexibility, they also want to make things much more optimization-friendly. It's definitely an important project in the python world, but frankly a lot of what they are doing is way beyond me :-) I suspect if "realtime python" is even possible, there would have to be some restrictions to get things realtime safe... which would still probably be pretty useful :-) Maybe something like the "restricted python" they're using to implement a lot of pypy? http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#restricted-python -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Python
On Mon, Feb 05, 2007 at 12:26:09PM +0100, Lars Luthman wrote: > On Sat, 2007-02-03 at 16:28 -0200, Silver Rock wrote: > > I've been studiyng python and some things are not that clear: > > > > 1- Is python too slow to efectivelly communicate with Jack? PyJack did > > not seem to work right, so i tried PySndObj's JackIO object. It did > > not behave as good as with connection with ALSA. > > Depends on what you mean. Writing the actual process() callback in > Python is probably not a good idea, not as much because of the speed > (although you probably wouldn't want to use Python if you want to > squeeze as much processing as possible out of the computer) but because > of the unpredictability caused by the builtin garbage collection and > memory management. Then again, I'm no Python expert. Maybe it's possible > to tweak the interpreter so it can run in hard realtime. Highly doubtful. Python is fantastic for lots of jobs. This isn't one of them. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] LADSPA needs & wishes
On Mon, Jan 29, 2007 at 08:08:37AM +, Steve Harris wrote: > Ah, well the host is not supposed to change port values during run() > anyway, the idea in LADSPA (and LV2) is that the host should chop the > run() block where port values change. /delurk What does "chop the run block" mean? /relurk -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Recommended books for new audio developers
I would also recommend "The Science of Musical Sound" by John Pierce. it only has a bit of material about computer music, and that is pretty light and pretty dated, but otherwise it's GREAT background for thinking about how sound works. On Tue, Jan 16, 2007 at 12:05:53PM +, Damon Chaplin wrote: > > Hi, > > What are the recommended books to read for people new to audio > development? (Covering things like synthesis techniques, effects > processing and basic acoustics stuff.) > > On the bottom of the Documentation section of linux-sound.org I found > these 2: > > Computer Music Tutorial > by Curtis Roads (1995, 1254 pages) > > Computer Music: Synthesis, Composition, and Performance > by Charles Dodge and Thomas Jerse (1997, 480 pages) > > Though they seem quite old. Is there anything newer or better? > > > I guess for Linux-specific issues you have to read the docs/source for > things like ALSA, Jack, LADSPA/LV2, DSSI & LASH. > > Damon -- Paul Winkler http://www.slinkp.com
[linux-audio-dev] Re: Linux Documentation (was Re: [Consortium] Re: Linuxaudio.org staff updates)
On Mon, Dec 04, 2006 at 11:12:39AM -0500, Dave Phillips wrote: > And let's face it, folks, http://linux-sound.org and its mirrors are > doomed. I'm so tired of the maintenance that I'm just not doing any at > all. I'd like to see the community take over the lists and perhaps use > them as bases for a wiki catalog of Linux sound and music software. > Meanwhile I plan for one more update this month, then I'm unlikely to > continue working with it any longer. A heartfelt thanks for many years of an invaluable community service, Dave. I'm probably not alone in saying your site is what led me to be here. A toast to the host who brought the most! For my part, I apologize that I several times proposed an interactive replacement to the static site and never delivered anything. Sometimes I miss being underemployed :-) -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?)
On Mon, Nov 06, 2006 at 01:39:43PM -0500, Lee Revell wrote: > Real linux drivers reside in the mainline kernel. Out of tree stuff is > is irrelevant. I don't think that's a fair blanket statement given that drivers often begin life outside the mainline kernel tree. ALSA, for example. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Anyone else ever run a THD test on Jamin?
On Sun, Nov 05, 2006 at 09:44:14PM +, Dan Mills wrote: > Hi all, > While hacking around with aliasing effects in digital compressors (Yes > it is real, yes you can hear it!), I happened to run a 10Khz sine wave > into jamin with an instance of Jaaa hooked up to the output. > > The results were 'interesting' as it appears that jamin introduces > easily measurable harmonic distortion even with all compressors and eq > bypassed! Switching the master bypass in jamin however does make the > effect go away. I haven't tried anything like that, but I did notice that listening to the low band soloed (no mids, no highs) there was some easily audible distortion that I couldn't get rid of. When turning off the solo switch, it either went away or was masked by the mids and highs. Not sure which version of JAMIN, this was early 2006 and I haven't used it lately. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Re: Re: alsa, oss , efficiency?
regarding portability... portaudio? -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Paper on dynamic range compression
On Wed, Oct 18, 2006 at 08:28:15AM +1000, Erik de Castro Lopo wrote: > Dan Mills wrote: > > --- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > > > > > You need a low pass filter on the control signal. It > > > should > > > be somewhere well below 1kHz. > > > > Agreed that you need the filter, but a 'brick wall' at > > 1Khz means that anything faster then 50ms or so as an > > attack time (and there are legit uses for such), will > > itself overshoot horrribly due to the gibb effect of > > bandlimiting the control signal. > > This is the way analogue compressors work. If you have a > sound with a fast transient going into a slow attack > compressor, the transient passes throught pretty much > untouched (apart from any clipping that may occur due > to other parts of the design). Conversely, I'll just mention that it's possible to get distortion of low-frequency audio by setting the release time extremely fast, because the compressor is effectively trying to increase the gain at the end of every half-cycle. This is considered a case of giving the engineer enough rope to hang himself, and hoping that he uses it responsibly. See http://www.fmraudio.com/FAQ.htm#question4 for more. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Paper on dynamic range compression
On Thu, Oct 05, 2006 at 07:07:34PM +0200, Fons Adriaensen wrote: > On Thu, Oct 05, 2006 at 05:12:20PM +0100, Steve Harris wrote: > > > The SC* plugins do the same as TAP (calculate the gain every 4 samples), > > but I interpolate the gain values between each computation. The > > attch/deacay times were slow enough in my testing that it was OK to do > > that. > > It should be OK for all practical attack/release times. The only > penalty is 3 samples of delay on the gain change and maybe that's > to be avoided for a hard limiter. For a normal compressor it should > not matter. That is what, 90 microseconds at 44.1 kHz? I don't think there are any analog compressors that react anywhere near that fast. Don't worry about it :-) -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Writing LADSPA plugins in high level language?
On Wed, Jun 14, 2006 at 10:26:15AM -0700, lazzaro wrote: > >There are, of course, languages like SuperCollider and CSound, which > >ARE made for expressing audio algorithms. However, again they are > >generally interpreted. > > > Sfront compiles a high-level music language (Structured Audio) to C, > and there's no reason in theory that audio drivers couldn't be written > for LADSPA. I remember asking you about this a couple years ago and you said it could be done, but you could only run one plugin instance at a time... .is that still the case? or am I misremembering? And, is all the sfront / saol action happening somewhere that I'm not aware of? I was always disappointed that there didn't seem to be a lively community around saol. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Writing LADSPA plugins in high level language?
On Thu, Jun 15, 2006 at 12:02:34PM +0200, Dominique Michel wrote: > > On Wed, Jun 14, 2006 at 10:48:54AM -0400, Paul Winkler wrote: > > > Pyrex is good for making faster python libraries, which is a great > > > thing, but it won't help with the problem that you really > > > don't want to be running a python interpreter inside a realtime > > > dsp system. > > > > That's not entirely true. I once wrote an OS where the filesystem and > > ATA drivers were written in Python, which was accomplished by linking > > the kernel with libpython (no joke). Lower levels, like the memory > > manager, were written in Pyrex. In the end it was pretty slow and > > useless, but it did run, and at one point I managed to get on IRC with > > it :) I didn't say it wouldn't *work*. You're the one who said "pretty slow and worthless" :) -PW -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Writing LADSPA plugins in high level language?
On Wed, Jun 14, 2006 at 09:59:48AM -0400, Steve wrote: > There are, of course, languages like SuperCollider and CSound, which > ARE made for expressing audio algorithms. However, again they are > generally interpreted. You can run them, but they can't really be > considered equivalent to C, able to be compiled to code linked into a > program or plugin. (Though perhaps there exists ways of generating > plugins from CSound code, I wouldn't be surprised.) There's also the compile-to-C approach, e.g. sfront which takes SAOL code (sort of like csound with cleaner / more modern syntax) and generates C. I hacked up an attempt at generating Jack apps with sfront, which I never finished or released. SAOL interest seems to be pretty dead anyway. > One thing I just learned about recently is Pyrex. It doesn't generate > stand-alone programs but is meant for creating libraries that can be > called from Python -- it generates C code from a Python-like language, > which is structured to be called from Python. This makes sense to > me... why worry about supported the millions of CPU architectures out > there when this is already taken care of by GCC. So instead of > generating ML, generate "portable ML" (i.e., C code), and let GCC take > care of the platform-specific work. I think this is a great idea, > except that I'd like to just write a whole program or plugin in it > instead of making something that is meant to co-exist with Python > "glue code". Pyrex is good for making faster python libraries, which is a great thing, but it won't help with the problem that you really don't want to be running a python interpreter inside a realtime dsp system. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] LADSPA 2 name
On Mon, May 08, 2006 at 08:20:43PM +0200, Lars Luthman wrote: > On Mon, 2006-05-08 at 19:28 +0200, Thorsten Wilms wrote: > > Hi! > > > > Requirements in order of importance, highest first: > > - not likely to get us into legal trouble (snip) > L2, where the L is for LADSPA. http://www.waves.com/content.asp?id=139 -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] "LADSPA2" name
On Thu, Apr 27, 2006 at 07:00:42AM -0400, Thomas Vecchione wrote: > My vote is to keep LADSPA. I just dont see enough reason to change it. +1. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] RDF for CAPS plugins
On Thu, Apr 20, 2006 at 08:12:53PM -0400, Taybin Rutkin wrote: > On Apr 20, 2006, at 7:17 PM, Tim Goetze wrote: > > >One thing I don't understand about this lrdf business is how you type > >(or generate) a line that reads > > > >http://ladspa.org/ontology#TimePlugin"; > >ladspa:hasLabel="Time"> > > > >when http://ladspa.org/ontology is (and has been for some time) a 404. > > The URI doesn't have to resolve. It's more a promise that it's a > unique name because presumably, you own the domain name. Yep, that's something that took me a long time to accept about XML. URIs are used as namespaces all over the place, and they very often don't resolve to anything. You get used to it eventually :-P OTOH, it's pretty obvious why this is the case. Imagine if it *did* have to resolve to something. What would that mean? it only works when the server's up? (and DNS, and the end user's internet connection, and and and...) That would suck so bad. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] RDF for CAPS plugins
On Thu, Apr 20, 2006 at 10:51:20PM +0200, Tim Goetze wrote: > The 0.3.0 CAPS release actually comes with an rdf file supposed to > label the enumerated int ports (the Cabinet model switches and the > SweepVF filter modes). Argh! I already had 0.3.0, but apparently the gentoo ebuild fails to install the rdf file. I'll file a gentoo bug. I merged yours with mine and yep, it works - now I get both categorization and useful dropdown widgets on those four plugins. Yay! btw, the guy that wrote yours didn't apparently understand how the categories work. I had it mostly right by copying other files, but I just now stumbled on where the taxonomy is actually defined, it's at: /usr/share/ladspa/rdf/ladspa.rdfs ... which apparently comes with liblrdf. > Re: caps.rdf in general -- > > Paul, your permission assumed I'll recycle some of your python code, > to be run when making the CAPS 'dist' target. A better caps.rdf will > thus be in 0.3.1 (coming to a theatre near you sometime this year). Of course. It should be possible to stub out the rdf for enumerated parameters by looking at the "ports:" output of analyseplugin. That might be handy. > Steve, are the dc:creator, dc:rights, dc:title tags necessary? Paul's > caps.rdf simply copies the data found in caps.so -- is it possible to > simply eliminate this redundancy? dc (dublin core) metadata is generally optional. I just put those in without thinking because it was easy to parse out. I like having at least the title, it makes the rdf much more human-readable. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Re: [ANN] No More Specimen
On Thu, Apr 20, 2006 at 10:01:30PM +0200, Pedro Lopez-Cabanillas wrote: > On Thursday, 20 de April de 2006 13:49:19 -0400, Paul Winkler wrote: > > > > Sorry to disturb your eternal slumber, RIP. > > You are burying the wrong guy. It was Pete Bessman who lived fast, died > young, > and left a good-looking corpse behind. > > Regards, > Pedro Apologies. I take it you're not dead then? -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] RDF for CMT, and slightly improved script
On Thu, Apr 20, 2006 at 01:34:13PM -0400, Taybin Rutkin wrote: > I thought SWH had already provided an RDF file for the CMT plugins. Does > yours have more detail? Interesting... no such thing comes with cmt 1.15. Where'd you see that? Detail - no. Mine is almost nothing but categorization. You're not thinking of steve's swh plugins, are you? That one comes with rdf aplenty. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Re: [ANN] No More Specimen
On Thu, Apr 20, 2006 at 07:30:54PM +0200, Pedro Lopez-Cabanillas wrote: > On Thursday, 20 de April de 2006 09:57:14 -0400, Paul Winkler wrote: > > > > I can understand not wanting to maintain it any more, > > but where'd the download go?? > > http://gazuga.net/files ?--> 404 > > Here are the last files: > http://gazuga.net/specimen/files/ > > And here some old ones: > http://gazuga.net/specimen/oldfiles/ > > There is a pointer from the 'downloads' page: > http://gazuga.net/specimen/downloads.php > > Or I'm not understanding your question? Aha. I didn't happen to find any links to gazuga.net/specimen, only to either the gazuga.net front page (which no longer mentions specimen) or stale links to stuff under gazuga.net/files which is 404. Never mind. Sorry to disturb your eternal slumber, RIP. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] RDF for CAPS plugins
On Thu, Apr 20, 2006 at 06:10:35PM +0100, Steve Harris wrote: > On Thu, Apr 20, 2006 at 12:07:38 -0400, Paul Winkler wrote: > > I also haven't bothered to figure out what to do with all the stuff > > about ports, and ardour doesn't seem to need it anyway, so this version > > of the script doesn't handle that. (Hey Steve, what's all that port > > info in your rdfs used for?) > > Not much, in theory you can use it to make dropdown type boxes for > integer enumeration selectors, but I dont know if anyone does. Ah, I vaguely recall discussion of that now. Too bad. Better auto-generated UIs for some plugins would be a wonderful thing. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-user] Re: [linux-audio-dev] Re: [ANN] No More Specimen
On Thu, Apr 20, 2006 at 01:20:07PM -0400, Eric Dantan Rzewnicki wrote: > On Thu, Apr 20, 2006 at 12:30:34PM -0400, Paul Winkler wrote: > > On Thu, Apr 20, 2006 at 05:19:30PM +0100, Jonny Stutters wrote: > > > I've uploaded a copy of specimen-0.4.5.tar.gz (the most recent on my > > > disk) to: > > > http://jeremah.co.uk/downloads/linux/specimen/specimen-0.4.5.tar.gz > > > > > > I'm happy to host for the foreseeable future. If anyone's got a more > > > recent copy let me know and I'll get that up as well. > > > > Great! > > I found a copy of 0.5.1 on my drive. Email me privately if you want it. > > > umm ... the download just worked for me ... ummm ... where? afaict it has been wiped off the face of gazuga.net. > That said, I agreed a while back to maintain the project after Pete > announced his own death and the accompanying death of specimen. While > Pete resurfaced as a zombie and promptly went over to the dark side, I > have not yet found time to resurrect specimen (mainly due to my job and > preparations for LAC06). > > I fully intend to have a new home for specimen shortly after the > conference. In the meantime, there is a copy of 0.5.1 available here: > http://zhevny.com/specimen/files/ > > tarball, rpm and src rpm are there. > > I will maintain this location as the home of specimen files, so > feel free to point the ebuilds there. Wonderful, thanks! -- Paul Winkler http://www.slinkp.com
[linux-audio-dev] RDF for CMT, and slightly improved script
And here's some quick RDF for the CMT plugins, which greatly
reduces the number of "Unknown" plugins on my system.
Plus a slightly improved script (it takes the plugin filename as an
argument now).
For a couple of plugins I invented a "SynthesizerPlugin" and
"SurroundPlugin", which are (not surprisingly) not recognized by Ardour.
Is there a list somewhere of valid ladpsa RDF plugin types? I had a
look around the lrdf project page on sourceforge and didn't find
anything.
--
Paul Winkler
http://www.slinkp.com
#!/usr/bin/python
from cgi import escape
import os
import sys
HEADER = """
http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
http://www.w3.org/2000/01/rdf-schema#'>
http://purl.org/dc/elements/1.1/'>
http://ladspa.org/ontology#'>
]>
"""
FOOTER = """
"""
plugin_template='''
%(Maker)s
%(Copyright)s
%(Plugin Name)s
'''
def find_plugin(filename):
path = os.environ.get('LADSPA_PATH', '/usr/lib/ladspa').split(':')
for p in path:
maybe_file = os.path.join(p, filename)
if os.path.exists(maybe_file):
return maybe_file
raise IOError, "Didn't find %s on path %s" % (filename, path)
def split_vals(line):
try:
label, val = line.split(':', 1)
except ValueError:
# we don't handle port information for now.
return ()
val = val.strip('\'" ')
val = escape(val, 1)
return label, val
def parse_plugin(astr):
# icky quick hack
lines = astr.split('\n')
pairs = [split_vals(line) for line in lines]
pairs = [p for p in pairs if p]
info = dict(pairs)
return info
def parse_plugins(path):
info_str = os.popen('analyseplugin %s' % path).read()
plugin_strings = info_str.split('\n\n')
plugin_infos = [parse_plugin(s) for s in plugin_strings]
plugin_infos = [i for i in plugin_infos if i]
return plugin_infos
def make_rdf(parsed):
plugins_rdf = [HEADER]
# Sort by ID.
sortable = [(d['Plugin Unique ID'], d) for d in parsed]
parsed = [t[1] for t in sorted(sortable)]
for info in parsed:
plugin_template % info
plugins_rdf.extend([plugin_template % info for info in parsed])
plugins_rdf.append(FOOTER)
return '\n'.join(plugins_rdf)
if __name__ == '__main__':
if len(sys.argv) != 2:
sys.stderr.write('Missing required plugin library file argument\n')
sys.exit(1)
filename = sys.argv[1]
where = find_plugin(filename)
parsed = parse_plugins(where)
print make_rdf(parsed)
cmt-plugins.rdf
Description: application/rdf
Re: [linux-audio-user] Re: [linux-audio-dev] Re: [ANN] No More Specimen
On Thu, Apr 20, 2006 at 05:19:30PM +0100, Jonny Stutters wrote: > I've uploaded a copy of specimen-0.4.5.tar.gz (the most recent on my > disk) to: > http://jeremah.co.uk/downloads/linux/specimen/specimen-0.4.5.tar.gz > > I'm happy to host for the foreseeable future. If anyone's got a more > recent copy let me know and I'll get that up as well. Great! I found a copy of 0.5.1 on my drive. Email me privately if you want it. -- Paul Winkler http://www.slinkp.com
[linux-audio-dev] RDF for CAPS plugins
Hiya,
I'm having a hard time finding the plugins I want when using Ardour,
particularly since the majority of plugins I have installed don't
provide categories via RDF.
So, hoping this is useful to others, attached is a minimal RDF for the
CAPS suite, which I use a lot.
This was generated by a quick python script, also attached; I just
hand-edited the output to change the plugin types from UnknownPlugin.
Wasn't sure what to do with the pan plugin.
I also haven't bothered to figure out what to do with all the stuff
about ports, and ardour doesn't seem to need it anyway, so this version
of the script doesn't handle that. (Hey Steve, what's all that port
info in your rdfs used for?)
--
Paul Winkler
http://www.slinkp.com
caps.rdf
Description: application/rdf
from cgi import escape
import os
HEADER = """
http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
http://www.w3.org/2000/01/rdf-schema#'>
http://purl.org/dc/elements/1.1/'>
http://ladspa.org/ontology#'>
]>
"""
FOOTER = """
"""
plugin_template='''
%(Maker)s
%(Copyright)s
%(Plugin Name)s
'''
def find_plugin(filename):
path = os.environ.get('LADSPA_PATH', '/usr/lib/ladspa').split(':')
for p in path:
maybe_file = os.path.join(p, filename)
if os.path.exists(maybe_file):
return maybe_file
raise IOError, "Didn't find %s on path %s" % (filename, path)
def split_vals(line):
try:
label, val = line.split(':', 1)
except ValueError:
# we don't handle port information for now.
return ()
val = val.strip('\'" ')
val = escape(val, 1)
return label, val
def parse_plugin(astr):
# icky quick hack
lines = astr.split('\n')
pairs = [split_vals(line) for line in lines]
pairs = [p for p in pairs if p]
info = dict(pairs)
return info
def parse_plugins(path):
info_str = os.popen('analyseplugin %s' % path).read()
plugin_strings = info_str.split('\n\n')
plugin_infos = [parse_plugin(s) for s in plugin_strings]
plugin_infos = [i for i in plugin_infos if i]
return plugin_infos
def make_rdf(parsed):
plugins_rdf = [HEADER]
# Sort by ID.
sortable = [(d['Plugin Unique ID'], d) for d in parsed]
parsed = [t[1] for t in sorted(sortable)]
for info in parsed:
plugin_template % info
plugins_rdf.extend([plugin_template % info for info in parsed])
plugins_rdf.append(FOOTER)
return '\n'.join(plugins_rdf)
if __name__ == '__main__':
where = find_plugin('caps.so') # XXX make it a parameter
parsed = parse_plugins(where)
print make_rdf(parsed)
Re: [linux-audio-user] Re: [linux-audio-dev] Re: [ANN] No More Specimen
On Thu, Apr 20, 2006 at 05:04:45PM +0200, Nigel Henry wrote: > On Thursday 20 April 2006 15:57, Paul Winkler wrote: > > I can understand not wanting to maintain it any more, > > but where'd the download go?? > > http://gazuga.net/files --> 404 > > Hi Paul. I'd downloaded the tar.gz while it was still there. If you want it > I'll send it. > Nigel. Thanks, but it's not just me... the recently-mentioned proaudio overlay for gentoo included a specimen ebuild, which no longer works due to the 404 :-( Anybody care to host the tarball? -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Re: [ANN] No More Specimen
I can understand not wanting to maintain it any more, but where'd the download go?? http://gazuga.net/files --> 404 -- Paul Winkler http://www.slinkp.com
[linux-audio-dev] Re: [linux-audio-user] Free Software vs. Open Source: Where do *you* stand?
On Mon, Feb 20, 2006 at 02:55:53PM -0500, Pete Bessman wrote: > WHAT is your NAME? Slink P. > WHAT is your QUEST? To have enough time to play music and hang out with my wife, enough money to pay off my credit cards (and buy more gear), and health insurance. Ideological debates are pretty much de-prioritized for me these days. But I still run 100% free and 99% libre software :-) Why? At this point it's a cultural habit. For me to run anything else there has to be a compelling reason, and frankly I have not seen any. I was toying with the idea of getting a Mac, because I'm tired of investing so much time in my computers, but after what's happened with my wife's ibook lately*, I don't think the alternative is any better. Running linux can be time-consuming and maddening at times, but I hate feeling helpless and ripped off even more. > WHAT is your FAVORITE ALBUM? The Who, "Live at Leeds", preferably the 2-CD set. * US $300 to replace a faulty inverter, and it came back with a broken wireless antenna. This conveniently happened just two months after the overpriced extended warranty plan expired, and just barely cheap enough to justify not buying a new laptop yet. And this is apparently relatively *good* service? No thanks. Now back to your regularly scheduled soapboxes. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Re: [linux-audio-user] LAD site, linuxdj.com needs a new home
On Wed, Feb 01, 2006 at 08:43:22PM +0100, Joern Nettingsmeier wrote: > also, the linuxaudiodev.org domain has expired a while ago, it would be > nice if someone were to reclaim it and point it to the new location as > well. (benno, i've been trying to contact you about this for months, but > you're a little hard to reach these days.) It's not showing up as available. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] db gain controls.
On Fri, Dec 23, 2005 at 03:39:33AM +0100, David Kastrup wrote: > Lee Revell <[EMAIL PROTECTED]> writes: > > He said sensible not possible. > > If you are using ramp gains, then you don't want to use courser steps > than available because you are buying additional noise in that > manner. My guess is that you don't actually disagree: the O.P. didn't say whether he meant "gain control" in the sense of user interface or in the sense of DSP. Lee seems to be assuming the former. David seems to be assuming the latter. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?
On Tue, Jun 14, 2005 at 02:20:13AM +0200, Jay Vaughan wrote: > WHAT OSS guys, The guys that wrote it. http://www.opensound.com/ -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Re: [linux-audio-user] disaster day #1
On Tue, Jun 07, 2005 at 08:40:31AM -0400, Dave Phillips wrote: > Greetings: > > Interesting stuff. I'm learning more about mobos than I ever wanted to > know. :) > > However: No brown goo on the caps, no bulging components, so I don't > think it's the capacitors. The fact that the machine is dying right at > the start seems to indicate that the problem may be either RAM or the > power supply. I'll check the RAM in another machine within a day or two, > if it's okay then I'll try switching out the power supply. > > What a PITA. Yep, hardware failures are no fun. I'd guess the RAM too; I had a bad stick several years ago that gave me gradually increasing kernel panics. Stupidly, I had no way to back up everything at the time, only small documents to floppy, and a forced reboot after one panic triggered a fsck on startup during which the system crashed AGAIN rendering the disk unmountable. That was fun I can tell you. I did eventually retrieve all my data after replacing the RAM, but it took about two days of nonstop work. since then I have set myself up with redundant hard drives, occasional CD-RW and DVD-R backups, and journalling filesystems :-) -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
On Mon, Jun 06, 2005 at 04:12:27PM -0500, Jan Depner wrote: > I just have to respond to this. I have been writing code for 27 > years and every time I get a neophyte programmer in they want to cut > corners to save programming time. Here's the bottom line - if it saves > you a day in coding but costs the user 3/4 of a second in application > time would you consider that a good tradeoff? Not if you have over 100 > users and they're having to deal with that 3/4 of a second 20 or so > times a day, every day for a year. Remember, it's only hard for you to > program it correctly once - it's a PITA for the user many times a day. I sort of agree, with the very large caveat that "once" is unlikely. The time to write the code is often dwarfed by the time to maintain the code. So your optimizations had damn well better be as readable as you can make them, and well-commented. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
On Sat, Jun 04, 2005 at 04:59:06PM +0200, Tim Goetze wrote: > Scene II: > > Our hero puts years of work into an all-round realtime audio and MIDI > library that expands the Python programming language. (snip) > said library dies a slow and painful but equally unsung death. I was wondering what the reason was for dropping midithing. I played with it briefly and quite liked it. Sad indeed. btw, the links leading through these series of pages have a certain comical value: http://www.quitte.de/midithing.html "The Thing is dead!" ... "Something much better" at: http://www.quitte.de/mandala.html "Rechristened ... Please go to the nam page for the latest info on this package." http://www.quitte.de/nam.html "Superseded: Please look at the milk project instead." http://www.quitte.de/milk.html Leading me to wonder, how long before Milk is superceded, or at least renamed? ;-) I usually just drop my projects completely after one pre-release. I greatly admire your tenacity :-) -- Paul Winkler http://www.slinkp.com
Re: Minimum reasonable latency Was: Re: ZynAddSubFX was: Re: [linux-audio-dev] some new soundfiles on-line
On Sat, May 14, 2005 at 11:58:45AM +0200, Benno Senoner wrote: > Plus due to the nature of the sound, low frequency oscillations take > longer to get recognized since in theory you > need to hear a full cycle of the wave to "measure" the frequency. > at 100 Hz it means 10msec ... an eternity for your standards :) I agree with a lot of what you said, but I don't think this part is relevant. When we're concerned with latency, it's typically for rhythmic reasons; pitch is not an issue. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] [ANNOUNCE] Smack 0.1.0 Released
On Fri, May 13, 2005 at 05:46:40AM +, Lachlan Davison wrote: > The first public release of smack is now here. Smack is a drum synth, > 100% sample free. In this release there are > TR808 bass, snare, hihats, cowbell and clave, > TR909 bass and snare, > a frequency shifter based snare and some FM hihats. > It's built with LADSPA plugins and the Om modular synth. For source and rpms > go to http://smack.berlios.de/ Some audio demos are also on the site. Nice demos! One complaint on the website... the dark blue link text on black background are nearly invisible. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Common synthesizer interface -or- microtonal alternative to MIDI?
On Tue, May 03, 2005 at 02:14:46PM +0200, Jens M Andreasen wrote: > On Tue, 2005-05-03 at 14:55 +0300, michael tewner wrote: > > > > > > > To my awareness, the hardware synths that do microtuning can be set up > > > any twisted imaginable way. You might have to look one page further down > > > though, to get past the 12 note/octave convenience setup. > > > > THere was a piece written for the DX-7 (symphonia?) that had ~60 > > steps/octave. It wasn't diffucult to set up, just time consuming. All you > > would have to do is program the multitune on each device - The MIDI note > > number is layer of abstraction; it doesn't *need* to map to it's > > traditional key. > > If "it" (symphonia?) was tuned even tempered 60 note/octave, the DX7* > will do the tuning in almost no time from the "convenience page". Select > "even tempered", select "60", done! (Well, approximately like that ...) So you assign 60 pitches per octave - doesn't that leave you with only just over a 2 octave range? confused... -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Tracktion, JUCE and Linux
On Tue, Apr 26, 2005 at 06:03:15PM +0200, Alfons Adriaensen wrote: > I'm trying to fit the pieces together. > > 1. JUCE is GPLed > 2. A Linux version of Traktion would use JUCE > 3. This version would not be GPLed > > Seems like a contradiction. > > What am I missing ? Dual licensing. JUCE is available in a commercial version for a fee. Mackie undoubtedly has paid for such a license. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] latencytest on 2.6 kernels?
On Thu, Apr 14, 2005 at 10:59:32PM +0200, Florian Schmidt wrote: > On Thu, 14 Apr 2005 15:38:50 -0400 > Paul Winkler <[EMAIL PROTECTED]> wrote: > > > Hiya, > > > > Now that I've finallly gone to a 2.6 kernel (latest gentoo-sources, > > 2.6.11.something) I thought I'd fire up latencytest and see > > what it tells me. Unfortunately, latencytest0.42 still seems > > to be the latest and it no longer compiles. Anybody got a fix? > > you can try my rtc_wakeup program.. we used it in the early realtime > preemption days to measure jitter on rtc irq wakeups).. > > find it here: > > http://www.affenbande.org/~tapas/wiki/index.php?rtc_wakeup > > Flo thanks, i'll try that too if i have time. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] latencytest on 2.6 kernels?
On Thu, Apr 14, 2005 at 10:03:00PM +0200, Andreas Kuckartz wrote: > Try version 0.5.5: > http://www.alsa-project.org/~iwai/alsa.html#LatencyTest > > There is a syntax error in showtrace.c but it is pretty obvious how to correct > it. Thanks for that. It seems to (mostly) work and report stats once that typo is fixed, but the PNGs look wrong. I'll email a report to Takashi. -PW -- Paul Winkler http://www.slinkp.com
[linux-audio-dev] latencytest on 2.6 kernels?
Hiya,
Now that I've finallly gone to a 2.6 kernel (latest gentoo-sources,
2.6.11.something) I thought I'd fire up latencytest and see
what it tells me. Unfortunately, latencytest0.42 still seems
to be the latest and it no longer compiles. Anybody got a fix?
[EMAIL PROTECTED] latencytest0.42 $ make
gcc -Wall -O2 -DUSE_PENTIUM_TIMER -c rtc_latencytest.c
rtc_latencytest.c:24:41: macro "rdtsc" requires 2 arguments, but only 1
given
rtc_latencytest.c:25: error: syntax error before '{' token
rtc_latencytest.c: In function `main':
rtc_latencytest.c:142: warning: passing arg 2 of `signal' from
incompatible pointer type
rtc_latencytest.c:143: warning: passing arg 2 of `signal' from
incompatible pointer type
rtc_latencytest.c:261:24: macro "rdtsc" requires 2 arguments, but only 1
given
rtc_latencytest.c:261: error: `rdtsc' undeclared (first use in this
function)
rtc_latencytest.c:261: error: (Each undeclared identifier is reported
only once
rtc_latencytest.c:261: error: for each function it appears in.)
rtc_latencytest.c:295:22: macro "rdtsc" requires 2 arguments, but only 1
given
rtc_latencytest.c: In function `my_exithandler':
rtc_latencytest.c:295: error: `rdtsc' undeclared (first use in this
function)
rtc_latencytest.c:365:19: macro "rdtsc" requires 2 arguments, but only 1
given
rtc_latencytest.c: In function `calibrate_loop':
rtc_latencytest.c:365: error: `rdtsc' undeclared (first use in this
function)
rtc_latencytest.c:367:19: macro "rdtsc" requires 2 arguments, but only 1
given
rtc_latencytest.c:406:21: macro "rdtsc" requires 2 arguments, but only 1
given
rtc_latencytest.c: In function `sigio_handler':
rtc_latencytest.c:406: error: `rdtsc' undeclared (first use in this
function)
rtc_latencytest.c:408:21: macro "rdtsc" requires 2 arguments, but only 1
given
make: *** [rtc_latencytest.o] Error 1
--
Paul Winkler
http://www.slinkp.com
Re: [linux-audio-dev] GPL concerns
On Wed, Apr 06, 2005 at 02:56:19PM -0500, Shane wrote: (snip) I think you need a lawyer. This is way over my head, and probably the same goes for most here. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] live pa questions
On Mon, Apr 04, 2005 at 05:55:12PM +0100, Dave Griffiths wrote: > On Mon, 04 Apr 2005 18:01:02 +0200, Pieter Palmers wrote > > the following links provide quite some info regarding distortion, > > clipping and DC offsets: > > http://sound.westhost.com/clipping.htm > > http://sound.westhost.com/tweeters.htm > > interesting articles > > > My recommendations: > > - Be sure to do a decent sound-check: have a full-scale piece of > > music ready for the PA engineer to set the PA desk incoming level, > > and be sure not to change your volume when soundcheck is done. - > > Adapt the dynamic range of your music to the live enviroment, e.g. > > by using a compressor plugin just before the soundcard output. > > so it isn't so much of a software problem, but rather the responsibility of > the artist to keep the dynamic range down, and the sound engineer to set the > levels sensibly? > > it's interesting though, as a lot of performers who use computers eschew the > soundcheck these days, thinking just a line test, or just plugging in and > setting the volume, is enough. > > so, would it be a good idea to purchase a small compressor, if using homemade > analogue synths, or even software capable of producing nasty signals? A compressor might not be fast or hard enough to buy you much safety. For that, better would be a good fast limiter and a subsonic filter. The filter is pretty easy and cheap (see e.g. the Harrison Labs Fmod), but I don't happen to know of a really good inexpensive brick-wall limiter first-hand. I've heard that the Aphex Dominator isn't bad, but it's hardly cheap. Maybe one of the DBX models? *shrug* If I owned a venue or rented a sound system I'd probably provide my own anyway, but I don't know how many do that. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] jack and alsa design issue
On Fri, Mar 18, 2005 at 08:24:01AM -0700, Hans Fugal wrote: > I'm writing an application that will use alsa in the common case, but be > jack-capable. I'm faced with the following design question: Do I wrap > the jack part to emulate the read/write of alsa, or do I wrap the alsa > part to emulate the callback style of jack? In other words, do I push or > pull from the audio segment of the program? maybe write the whole thing callback-based and use portaudio? -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] the bandwidth of the each harmonic
On Fri, Feb 04, 2005 at 02:45:24PM -0800, Paul wrote: (snip) Interesting read, a novel perspective to me. Just wanted to note that AFAICT a chorus effect (basically a modulating small delay line) will produce some of this effect because the modulation causes slight pitch shifts which apply proportially to all the harmonics. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Developing a music editor/sequencer
On Mon, Jan 31, 2005 at 06:53:05AM -0500, Paul Davis wrote: > but anyway, i just wanted to note that tracks don't have to be > considered as this kind of burden at all. when you get down to the > core of it, tracks are a grouping mechanism, that's all. agreed... > and they > don't group by using time relationships, but signal processing > relationships. Hmm, what then is a "channel"? -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Tuning
On Sun, Jan 30, 2005 at 03:05:53PM -0500, Lee Revell wrote: > On Sun, 2005-01-30 at 10:39 -0600, Jan Depner wrote: > > Don't worry about speed with an instrument - it's way overrated. > > Less is definitely more in that department. > > Anyone who tells you this has obviously never heard Yngwie Malmsteen's > "Rising Force". Didn't care for it. I'll take Neil Young instead, thanks. To me this seems like an "obvious" choice, once again making the point: to each his/her own! -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Tuning
On Fri, Jan 28, 2005 at 05:09:09PM -0600, Jan Depner wrote: > Next up... a plugin that plays your instrument for you. Why deal > with the tedious hassle of having to tune your instrument or actually > learn how to play it? Can't sing... not a problem! I can see Micro$oft > coming out with something like that ;-) > > > Sorry, but this goes against the grain for me. If I'm going to suck > live I'd damn well better suck digitally so I'll know better than to > play live ;-) I'm with ya. But isn't this just Autotune all over again? -PW -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] [semi-OT] EEL 0.1.0
On Tue, Jan 11, 2005 at 03:29:24PM +0100, David Olofson wrote: > My main focus has been on easy typing and reading, and making it hard > to accidentally write code that doesn't do what you think it does. A worthy goal! One little thing I've come to like about Python - you can't use an assignment in an expression like: while x = 1: The rationale, and discussion of some common idioms, is described here: http://python.org/doc/faq/general.html#why-can-t-i-use-an-assignment-in-an-expression That whole section also has a lot of rationale for various python features (and some historical warts), so it might be a good read for a budding young language designer even if you hate the choices made ;-) -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] [semi-OT] EEL 0.1.0
On Tue, Jan 11, 2005 at 03:20:40PM +0100, Mario Lang wrote: > Steve Harris <[EMAIL PROTECTED]> writes: > > > On Tue, Jan 11, 2005 at 12:02:31 +0100, Mario Lang wrote: > >> > I'm very interested in the idea of being able to code modules in a > >> > modular synth live (in realtime) as well. > >> > > >> > I was considering using ChucK, given that it's specifically designed for > >> > RT performance use and can insert/remove/replace pieces of code into the > >> > vm while running, but it looks like it would be a significant amount of > >> > work to adapt the ChucK engine to be controlled by another app. > >> > >> Have you looked at SuperCollider3? It is designed for RT, allows for live > >> coding in all sorts of ways (JITLib) and can easily be controlled from > >> other apps (the client and server side both can send and receive OSC) and > >> it has 8 JACK in and out ports by default. > > > > Yep, for performance coding I would say SC is the best bet, I've seen a > > live coding performance, and it was very impressive. Almost enough to make > > me want to use emacs. Almost ;) > > > > I was thinking of a live C compiler for prototyping and testing > > purposes. > > CLM (Common Lisp Music) already does that since many years, but its not sure what you mean by "live", but there is also sfront, which compiles SAOL to C. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Re: [Fwd: Graphical dataflow programs violate patents]
On Wed, Dec 15, 2004 at 02:30:09PM +0200, Juhana Sadeharju wrote: > When Csound type software was first written? 1960? 70? I assume you mean the "Music N" family of languages. Music IV dates to at least 1961 according to this page: http://music.dartmouth.edu/~wowem/electronmedia/music/eamhistory.html -- Paul Winkler http://www.slinkp.com
Re: SCOundrels (Re: [linux-audio-dev] Patents on some Linux OS code)
On Thu, Dec 09, 2004 at 04:55:51PM +, Pall Thayer wrote: > well, yes. there's that too... > But it's more fun to watch than Icelandic national television. OK, but on the other hand you've got the most amazing aurora borealis and all those hot springs to make us city-bound yanks jealous... And incredible landscapes like this: http://www.slinkp.com/photo_album/iceland/dsc00525.jpg/view?display=large I hope to visit Iceland again some day soon :-) -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Re: Behringer
On Sat, Dec 04, 2004 at 02:23:46PM +0100, martin rumori wrote: > i'll happily participate (in a polite and professional manner) cause > i'm disappointed as well (and would have bought a fireface already if > there was any chance...). +1 > and i'd rather appreciate if this thread could come to an end since it > feels like the arguments of both sides are broadly expressed now (and > maybe the personal stuff going on currentyl doesn't bother just me). +1 -- Paul Winkler http://www.slinkp.com
Re: Behringer [was Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more]
On Mon, Nov 29, 2004 at 09:27:46AM +1300, Eliot Blennerhassett wrote: > So, what is the difference between our current offerings and what you'd like > to see in a "pro audio card"? I don't see any gross difference except the input/output connectors. Bundle the 5042 or 5044 with adapters or breakout boxes, and price them roughly in the ballpark (allowing for feature and/or spec differences) with M-audio's Delta 1010LT and 1010, and you might have another market to tap into. Worth investigating anyway. That's a pretty low price target, though. The Delta 1010 can be had for $500 new; the 1010 LT for considerably less. Another point of comparison would be Echo Layla for ~ $700 US. -- Paul Winkler http://www.slinkp.com
[linux-audio-dev] This better not be patented...
Not sure how many algorithms this makes sense for but if it works as advertised for convolution, it would make a hell of a reverb. http://www.tomshardware.com/hardnews/20040902_135943.html -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Firewire Breakout-Boxes
On Thu, Aug 26, 2004 at 12:30:08AM +0200, Daniel Wagner wrote: > Hi, > > I'm pleased to announce a project which eventually should support > several Firewire-based breakout-boxes. Following boxes would be > supported: > > - ESI QuataFire 610 > - M-Audio Firewire Audiophile > - M-Audio Firewire 410 > - M-Audio Firewire 1814 > - Terratec Aureon 7.1 FireWire > - Edirol FA-101 (snip) This is very good news!!! Two questions: 1) Is the intent to produce an ALSA driver, or what? 2) What is the license of the code going to be? -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Re: [linux-audio-user] Setting up linux computer
On Wed, Aug 25, 2004 at 09:13:05AM +0200, Clemens Ladisch wrote: > Paul Winkler wrote: > > On Tue, Aug 24, 2004 at 04:23:10PM +0200, Clemens Ladisch wrote: > > > The snd-usb-audio driver currently supports multiport USB > > > interfaces from ESI/Edirol/Roland/M-Audio/Yamaha. > > > > Note that others have reported issues with the M-audio usb devices. > > The MidiSport MIDI interfaces work just fine (once you have managed to > get the firmware and to install the firmware loader). It's the audio > interfaces that have (rather major) "issues". Yes, sorry I forgot to make that distinction. I had the same experience with my Oxygen - works fine once you've dug around the net and figured out how to load the #@()% firmware. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Hello - FYI - intro
On Tue, Aug 24, 2004 at 06:35:12PM -0400, John Check wrote: > > > It's completely dwarfed by compile time. > > > > Are you sure you wanted to say that ;) Yes. First rule of optimization: don't optimize something that's statistically irrelevant. The speed or lack thereof of portage is irrelevant given that its intended purpose is fetch source code across a network and then compile and install it. It's only an issue if the user interface (emerge) "feels" slow and I've never noticed it. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Hello - FYI - intro
On Tue, Aug 24, 2004 at 04:52:05PM -0400, Paul Winkler wrote: > On Tue, Aug 24, 2004 at 03:41:17PM -0400, John Check wrote: > > And how long does that take vs apt-get update && apt-get dist upgrade? > > Take all the milliseconds you shave with flags and deduct 'em from the build > > time and pig-dog slowness of a package management system that runs on an > > interpreter, > > Them's fightin' words :-P > I've never found the "pig-dog slowness" of portage to be significant > whatsoever. It's completely dwarfed by ... i meant to finish that line :-) It's completely dwarfed by compile time. The main inconvenience of gentoo that I've noticed is that I've had to train myself not to do upgrades right before I want to do some work :-) -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Hello - FYI - intro
On Tue, Aug 24, 2004 at 03:41:17PM -0400, John Check wrote: > And how long does that take vs apt-get update && apt-get dist upgrade? > Take all the milliseconds you shave with flags and deduct 'em from the build > time and pig-dog slowness of a package management system that runs on an > interpreter, Them's fightin' words :-P I've never found the "pig-dog slowness" of portage to be significant whatsoever. It's completely dwarfed by I don't care about the supposed optimizations, I've never noticed whether gentoo is any faster or what. The things I like are: 1) It Just Works. Dunno if it's my increased experience or gentoo or what, but in the past year I've had fewer complaints with my two gentoo boxes than anything else I've tried. I ran RH 4-7, followed by 2 years of Debian (i tried stable, which was really stable but really ancient; unstable, which was pretty current but became unbootable after updates twice; then testing, which went unbootable after updates once, after which I was done.) 2) For those times I want something bleeding edge from a tarball that's not in the distro yet, it's trivial to tell portage "don't worry, I've got it covered" and still be able to emerge other stuff that depends on it. I did this routinely with alsa and jack for a few months when gentoo was lagging a bit behind some of the bleeding-edge LAD stuff. Worked flawlessly everty time I did it. E.g. if gentoo is still on jack 0.94 and I want to install a hypothetical 0.99 from source, all I do is build and install the tarball, then do emerge inject media-sound/jack-audio-connection-kit-0.99 -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Re: [linux-audio-user] Setting up linux computer
On Tue, Aug 24, 2004 at 04:23:10PM +0200, Clemens Ladisch wrote: > ChristianH wrote: > > - and I assume MIDI interface as well (6 to 8 ports in+out) > > > > For Windows I was considering an Emagic AMT8 or Unitor8 interface, > > There is no Linux driver for these. The snd-usb-audio driver > currently supports multiport USB interfaces from ESI/Edirol/ > Roland/M-Audio/Yamaha. Note that others have reported issues with the M-audio usb devices. I can't speak to that but I recall the subject popping up from time to time. Their PCI devices, on the other hand, are generally excellent and well supported. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Re: [linux-audio-user] Setting up linux computer
On Tue, Aug 24, 2004 at 03:14:40PM +0200, ChristianH wrote: > Hi all, > > I'm in a similar situation. Within a couple of weeks I'll be buying a > new PC which (besides still running Windows) should be, say, at least > Linux friendly. > > Since in this case I'm not tied to given legacy hardware, I'd rather put > in some components that are particularly suitable for Linux. > > >From what I heard, culprits can be > - audio card > - graphics card (hi resolution, 1280+, no 3D game capability needed) > - and I assume MIDI interface as well (6 to 8 ports in+out) dunno about mult-port midi devices, my own midi needs are very modest. > Are there cards with rather good Linux driver support? > Are there cards better to avoid in Linux world, due to their poor driver > status? > > Is there a Linux hardware FAQ site somewhere, with some recommendations? There was the Linux Audio Quality HOWTO, but since I stopped maintaining it, it's very old info now. http://www.linuxdj.com/audio/quality/ This Wiki can be helpful: http://alsa.opensrc.org/ ... especially this page about all the drivers: http://alsa.opensrc.org/index.php?page=AlsaDrivers > Until now I've been using an Emagic AW8 audio card, which perfectly fits > my needs (don't really need 24/96k or oodles of audio ports). > For Windows I was considering an Emagic AMT8 or Unitor8 interface, but I > don't remember seeing any Linux drivers on their site (well, they may > call'em OS X drivers... ;-) An OS X driver wouldn't do you any good. Somebody did write an AW8 driver here: http://www.sipkema-digital.com/~msipkema/audiowerk.shtml ... but it's rather non-standard (why the driver talks to its own user-space JACK code and isn't an alsa driver is beyond me, presumably it was a quicker way for the author to get what he wanted.) If you're buying a new card and want just a few good-quality I/O, you might consider one of the ice1712-based cards as listed on http://alsa.opensrc.org/index.php?page=AlsaDrivers... a lot of us have them and like them. I've got a Delta 66. Archives of this mailing list will also be helpful. In general, if there's a card you're interested in, google for name of card + linux + alsa and see what pops up. > Another component may be somewhat outside this list's topics, I'm > thinking of adding a video MPEG input/encoder card as well - maybe somebody > can give me any pointers on that...? sorry, no idea. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] a new patent to worry about
On Tue, Aug 24, 2004 at 05:39:20PM +1000, Erik de Castro Lopo wrote: > On Mon, 23 Aug 2004 23:23:03 -0400 > Paul Davis <[EMAIL PROTECTED]> wrote: > > > > > http://news.harmony-central.com/Newp/2004/L3.html > > I really think that worrying about patents is a waste of time. > > In addition, considering that knowingly infringing on a patent > usually carries a larger penalty than unknowingly infringing, > I'd really prefer not to know :-). No patents on that page anyway :-) -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Sat, Aug 21, 2004 at 04:22:36PM -0400, Lee Revell wrote: > I suspect that a GUI programmer or interface designer would expect > things to increase from top to bottom. In GUI programming, the origin > is at the top left of the screen, and X,Y coorinates increase going > right and down respectively. I am not sure why they didn't just follow > the Cartesian conventions here, but I believe it has been this way > forever. I believe it's a historical artifact of early GUI software being pretty close to the hardware. CRT screens put the origin at top left and scan from left to right, top down. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Read this after your first cup of coffee
On Fri, Aug 20, 2004 at 03:48:34PM -0400, Paul Davis wrote: > with much respect to julien, and much affection towards ardour/ksi, i > would point out that its essentially impossible to become a > professional audio engineer if you are sight-impaired precisely > because you cannot use protools. catch-22 situation, really. I don't believe that to be true. It is certainly a large obstacle, but there is a minority of working professional engineers who hate protools. Some of these folks hate DAWs in general, some of them hate protools in particular. Many of them make a living working on analog tape. You'll run into them on rec.audio.pro occasionally. I have no idea how many there are. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Read this after your first cup of coffee
On Tue, Aug 17, 2004 at 05:11:35PM -0400, John Check wrote: > Heheh, I didn't think of i18n until you said it. sure you did! >From your post: > The only text input will be for URLs. This should minimize > grammatical and language issues as well as make internationalization easy. > Absolutely. Like I said I bounced the idea off of DP first, and I can host > linux-sound or he can pull pages from me. 6 of one .5 dozen of the other. > He's got the traffic already, so let the mountain go to Mohammed. it's just a domain name. thanks to DNS both mohammed and the mountain are very movable :-) > It'll be slashdotted on the first day. I'll but in a second machine and round > robin the first week. > > > (Out of my own curiosity as a potential collaborator: > > What's your preferred web app platform? And how much time during > > that 7-10 days do you think will actually be spent working on this project? > > And do you have a host in mind?) > > > > Linux/Apache/PHP4/MySQL ok, i'll hit you off-list about implementation issues. or maybe we could chat about it. what's your nick on #lad? and what timezone are you in? I'm slinkp and I'm in EST (brooklyn, NY). > > btw, are you aware of http://linuxaudio.org ? > > I am now. Okay that's very cool. I've been wanting to say "synergize" since I > got here, but I didn't want anybody to laugh ;) just curious... how long have you been "in the scene"? -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Read this after your first cup of coffee
On Tue, Aug 17, 2004 at 07:17:54AM -0400, John Check wrote: (snip) > I'm going to whomp up a database driven reporting system that extends the > concept to include protocol and library support and has some > Wiki like features. One will be able to search for specific types of programs > with specific criteria like: > Sequencers with LADSPA, JACK, DSSI, MESS, OSC, PHAT (Yes PHAT is that cool) > Hits will come back in table form with checkmarks in the appropriate columns, > ranked by how much of a match and a "freshness" date. > The app name will link to the project site and there will be additional links > to the primary documentation and the Wiki, if one exists. (snip) > The only text input will be for URLs. This should minimize grammatical and > language issues as well as make internationalization easy. (snip) > I would appreciate any ideas on what should be included, but I'm not going to > get into extended debates about what should be in. > I'm the ultimate arbiter, at least until it debuts. The basic manual reporting > and search should be live in 7-10 days. Interesting idea. It has significant intersection with my long-promised, long-postponed replacement for DLP's soundapps site, which has been discussed many times before (most recently this past january / february) - see here for summary and links: http://www.slinkp.com/slinkp/linux/soundapp_site_roughs On the one hand, I would like to point out that my proposal linked above has had considerable community input already, so you might want to at least think about my requirements list. On the other hand, I don't want to hold you back, and though the topic has been much on my mind recently, obviously I don't really have a burning need to be the one to get it done - if I did, I'd have done it by now. I have to face the fact that my track record adds up to 3 years of mailing list discussions and pure vaporware. So, I would much rather offer a bit of help on a project with some momentum than keep waiting forever for a free weekend or two to hack up my own without help. AFAICT you're proposing a particular subset of the information I wanted to gather, plus a really nice search result matrix idea. I see significant value to the restricted scope of the information you want to gather: - simpler UI for users - less administrative intervention - less site code to implement and maintain - easier i18n (I hadn't really thought about that till you mentioned it.) But then, all the additional information in my proposal could be really useful. I didn't entirely make up that requirements list, a lot of it was stuff that people on LAD and LAU suggested and argued over. Much of it would be optional of course. And if some of that information didn't go on your site, where would it go? If there were two sites, wouldn't that just add to the existing "too much information" problem you described? I don't see it so much as a problem of too much information - more a lack of coherence and organization to that information. A good domain-specific search engine and a consistent presentation of individual apps would be an enormous help IMO. I would really hope to build some community consensus about this. As a user, what I really want is one and only one kick-ass site for looking up linux audio apps. (Out of my own curiosity as a potential collaborator: What's your preferred web app platform? And how much time during that 7-10 days do you think will actually be spent working on this project? And do you have a host in mind?) > What About The Business Angle Then, Donald Chump? (snip) Good luck with it. I'd like to see some successful businesses putting more money in the hands of the LAD heavy lifters. btw, are you aware of http://linuxaudio.org ? -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Audio synchronization, MIDI API
On Sun, Aug 15, 2004 at 12:53:56PM -0500, Jack O'Quin wrote: > Paul Winkler <[EMAIL PROTECTED]> writes: > > > Another interesting comparison is modular digital multitracks > > such as ADAT and DA-88. Anybody know how sync works on those > > beasties? > > I think ADAT sends a wordclock-like pulse over the optical link. One > machine is master. All the others slave their converters to that. > Given sample synchronicity, doing the tape I/O is just a buffering > task that each device can manage independently. Sounds about right, but there must also be motor control so the buffers don't get too far out of whack. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Audio synchronization, MIDI API
On Sun, Aug 15, 2004 at 03:27:11PM +0200, Fons Adriaensen wrote: > For example instead of resampling 1 samples to 10001, you could > copy 9000 samples and then resample 1000 to 1001. This allows the > resampling code to handle at least 10x more channels for the same, > CPU load. > > It will introduce a bit of 'vibrato' on your signal, in this case > with an amplitude of 1/59 of a semitone, which is probably harmless. I think it should be. Remember that people successfully run multiple analog multitrack machines in sync by controlling the motor of one with some kind of timecode printed on the other. We're dealing with physical motors so I suspect the "vibrato" in that case is a lot more and nobody complained about it. Another interesting comparison is modular digital multitracks such as ADAT and DA-88. Anybody know how sync works on those beasties? -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] MIDI groove theory
On Tue, Aug 10, 2004 at 07:48:22PM +0200, Frank Barknecht wrote:
> Hallo,
> Dave Robillard hat gesagt: // Dave Robillard wrote:
>
> > Does anyone know of a page somewhere that explains just what (on a
> > developer level) MIDI "groove" is? I want to implement it in a
> > sequencer, but all I can find is user documentation pages with useless
> > information.
> >
> > Is it as simple as each note having a time offset (ie snare is early .5
> > ms, hi-hate late 1ms, etc.) or something more?
>
> This classic Masters-At-Work house music shuffle swing thang is just
> delaying every second (8th rsp. 16th) note a bit. I do this in my Pd
> sequencers using percentage values (like delay notes by 66 percent of
> the straight note lenght) and it's quite groovy afterwards. I also
> apply some gaussian randomness to the notes' onset times to simulate
> human error (which I think should be distributed gaussian, shouldn't
> it?) I'm not sure I can actually feel/hear that, though.
Hydrogen has a slider for each ("swing factor" and "human time"),
and I love the grooves I can get out of that app.
"human time" is just a small amount of randomness.
Might be worth a look at the code in libhydrogen
(it's mostly in src/Hydrogen.cpp afaict).
The "human time" feature can really help the feel, I think it's
because it makes "simultaneous" attacks slightly off from each other.
--
Paul Winkler
http://www.slinkp.com
Re: [linux-audio-dev] Re: pci gfx card / jack xruns / pci latencies
On Wed, Jul 21, 2004 at 02:49:46PM +0200, Florian Schmidt wrote: > On Wed, 21 Jul 2004 14:22:12 +0200 > Maarten de Boer <[EMAIL PROTECTED]> wrote: > > > Hello Florian, > > > > Is this with kernel 2.6.x or 2.4.x? > > > > I remember there were some problems with Matrox cards, that were > > initially not included in the 2.4.x low-latency patch, but I thought > > that at some point Andrew included them. > > > > http://www.eca.cx/lad/2002/06/0076.html > > Hi, > > thanks for your mail. It seems though that this is independent of the kernel > version. I booted into 2.4.22 with LL+preempt and it shows the exact same behaviour > as did 2.6.7 vanilla, 2.6.7-bk10-ck5-H3 and 2.6.8-rc1-mm1... I think the card is > just not good.. I'm also wondering about the weird lspci -v output which reports no > latency for the matrox card [and it's not bus master like all other pci devices i > have].. one other thing to try: be sure in you XF86Config you have PciRetry set to off. From man mga: Option "PciRetry" "boolean" Enable or disable PCI retries. Default: off. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch
On Mon, Jul 12, 2004 at 08:31:18PM -0700, Florin Andrei wrote: > On Mon, 2004-07-12 at 17:17, Lee Revell wrote: > > > There is an overwhelming consensus amongst Linux audio > > folks that you should use reiserfs for low latency work. > > I doubt the "overwhelming consensus" part. me too, but at some point in the 2.4 kernel cycle, reiserfs came out much better than ext3 in some latency tests* that were reported on linux-audio-dev and linux-audio-user lists. This seems to have left many of us musicianly types with a vague "reiser good, ext3 bad" mindset. * i think it was this: http://myweb.cableone.net/eviltwin69/Arcana.html#Mark%20Knecht's%20filesystem%20tests -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] [OT] bedroom vs. any other room, was re: [OT] marketing hype
On Fri, Jun 11, 2004 at 01:21:51PM -0400, Paul Davis wrote: > >On Fri, Jun 11, 2004 at 12:06:44PM -0400, Paul Davis wrote: > >> i have a very hard rule against hacking in the bedroom. i have broken > >> it once and will never do it again. "garage hackers", "living room > >> hackers" and right now "on the bar in the kitchen hackers" .. sure, > >> but never, ever a bedroom hacker. > > > >As someone whose desk and bed are currently in the same room, > >I'm curious about this. Why did you instate this rule? > > all work and no play already makes me a bit of a dull boy. > mixing work and play would make things even worse :) Point taken. Some days I'm beyond dull, I'm a bit nuts. > more seriously, its necessary to be able to escape from > programming. if not the bedroom, then where? I use the living room for that. Very relaxing when nobody's home :-) -- Paul Winkler http://www.slinkp.com
[linux-audio-dev] [OT] bedroom vs. any other room, was re: [OT] marketing hype
On Fri, Jun 11, 2004 at 12:06:44PM -0400, Paul Davis wrote: > i have a very hard rule against hacking in the bedroom. i have broken > it once and will never do it again. "garage hackers", "living room > hackers" and right now "on the bar in the kitchen hackers" .. sure, > but never, ever a bedroom hacker. As someone whose desk and bed are currently in the same room, I'm curious about this. Why did you instate this rule? -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Knobs, the reply
On Fri, Jun 11, 2004 at 02:59:11AM -0400, Dave Robillard wrote: > You can define multiple pointing devices in XF86Config; people do things > like have a mouse and a tablet, etc. > > If you don't want a device to control the core pointer, you just define > it but don't set it as the pointer for any screen. Oh, right, I didn't think of that. But if it's not set as a pointer for anything, how do you get events from it? -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Knobs, the reply
On Fri, Jun 11, 2004 at 01:07:46AM -0400, Dave Robillard wrote: > > Currently I use a Fellowes (nee Cirque) touchpad as my primary mouse. > > It's a bit bigger than a laptop touchpad, but not by much. > > Like this one: > > http://www.jr.com/JRProductPage.process?RestartFlow=t&Section_Id=1795&Product_Id=813772&Product_Name=FELLOWES+99841+Internet+Glidepoint+Touchpad > > Yeah, that is small. On the other hand, it's also incredibly cheap. I > don't think something that size would even be precise enough for > controlling filter cutoff though.. > > Could always buy 10 and build a nice little finger drum kit! :) yeah but how? i think you'd have to treat them as something other than normal mice for X, afaik it only allows one pointer at a time - i.e. multiple mice works fine but they all just control the same pointer. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Knobs, the reply
On Thu, Jun 10, 2004 at 08:42:42PM -0400, Dave Robillard wrote: > Speaking of touchpads, does anyone know of a (usb) touchpad that works > with your finger, not just a pen? (The only ones I've seen just work > with the stylus, which is no good) I'm guessing you mean a big one, like 15 or 20 cm on a side? I've never seen one that big that wasn't a pen-controlled art thingie. ... on the other hand, google finds everything... check this out, not cheap but looks very interesting and they seem to be linux-friendly! http://www.fingerworks.com/igesture.html Currently I use a Fellowes (nee Cirque) touchpad as my primary mouse. It's a bit bigger than a laptop touchpad, but not by much. Like this one: http://www.jr.com/JRProductPage.process?RestartFlow=t&Section_Id=1795&Product_Id=813772&Product_Name=FELLOWES+99841+Internet+Glidepoint+Touchpad -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Knobs, the reply
On Thu, Jun 10, 2004 at 11:55:32PM +0100, Steve Harris wrote: > On Thu, Jun 10, 2004 at 11:28:01 -0700, Tim Hockin wrote: > > I think that your frontal lobe is saying "knobs are round, move the mouse > > around them" but I still believe that your hand will find it more > > intuitive and correct to move the mouse in one direction - up and down. > > Hmm... I've just realised that I dont actually use mice, I prefer > touchpads, which make different movements easier. +1. Aside from the growing number of "laptop DJs" out there, I actually use a touchpad on my desktop because it doesn't fsck up my hand as badly as prolonged mouse useage does. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Knobs, the reply
On Thu, Jun 10, 2004 at 11:28:01AM -0700, Tim Hockin wrote: > On Thu, Jun 10, 2004 at 08:02:48PM +0200, Thorsten Wilms wrote: > > No, I did not mean 2 axes for one widget. Only that a linear widget has > > to indicate it's direction even before interaction happens, and that it > > makes sense to use vertical for volume and horizonal for pan in the > > same interface. > > OH! Hrrm, yes, well. I see the point, but I don't think it will work. > Differing semantics for similar-looking widget is the worst of all possible > choices. Not if the pan sliders are laid out horizontally :-) -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Re: UI stuff
On Wed, Jun 09, 2004 at 03:18:29PM -0400, Pete Bessman wrote: > At Tue, 08 Jun 2004 16:50:40 -0500 CDT, > Ben wrote: > > > > The app "Soundplay" for BeOS takes a novel approach ... the level is > > shown as a knob but when you grab it, a rectangular box appears > > behind the knob and you adust it like a fader. This is great > > because it gives you visual feedback of which direction(s) to move > > the knob. > > votes++ That sounds pretty cool. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Is ladspa actually la-dsp-a? Is JACK the ultimate solution?
On Tue, Jun 08, 2004 at 08:55:16PM +0200, Marek Peteraj wrote: > Virtual 3d guis copy the real world. Try to do it the other way around, > with widget sliders and one color for both sliders and background(most > cases). Imagine a hw which would look like that. I agree with your point here. I used to have a Yamaha four-track that had nothing but black sliders (no knobs) on a black background. It was horrible to use - there was no visual or tactile distinction > > Other > > people will probably want just that: photo-GUIs. > > Because they're easier to learn and get used to. Initially, sure; they look familiar. But I don't believe you can simply imitate hardware and get a good UI without thinking critically about each widget. A lot is lost in the translation. Remember that hardware still offers vastly better visual resolution, tactile feedback (e.g. potentiometer detents, switch clicks), more physical space (even a lowly Mackie 1604 mixer doesn't fit on a single display at actual size), and a much lower impedance to physical control (compare moving a physical slider to clicking and dragging an onscreen slider via a mouse; also, you have two hands and can use them easily at once, but you only get one mouse.) Even when a photo-GUI approach is chosen, there's no need to take it to extremes. Think of Reason. You flip the "rack" around to look at the connecting "cables" and they show you fans, screws, fuse holders... goofy. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev]Using python for small multimedia app ?
On Thu, Jun 03, 2004 at 11:54:56PM +0900, Cournapeau David wrote: > Hi there, > > I am discovering python, having looked for a matlab-like > environement. I am wondering now if it is possible to do some small > multimedia applications with it; more precisely, I would like to develop a > scientific application for audio/video analysis. Basically, I need to > show an avi > video with a synchronised waveform view of the sound, and some other > features views, like the pitch of the film voices (the actual pitch > detection doesn't need to be computed on the fly). > > Python seems really great for rapid developement, but I wonder if it > is possible to play different media synchronously (the media decoding > itself will be of course coded in C/C++) with it? Does anyone here have > any experience with multimedia and python ? I'm a full-time python/zope hacker but never done any multimedia apps with python. but here's some libs you might look at: Numeric (c extensions that give you high-speed matrix math stuff, might be handy for DSP) http://www.pfdubois.com/numpy/ SciPi - extensions that give you lots of pretty fast stuff including data visualization and DSP. http://www.scipy.org pygame - libraries for doing games and apps with openGL graphics, includes a lot of handy multimedia stuff (e.g. an audio mixer). http://www.pygame.org pyUI - built on pygame, for general-purpose UIs. http://pyui.sourceforge.net/ -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] re: [linux-audio-user] A bit of goodnews--paper now available for your viewing pleasure and/or comments
On Fri, May 28, 2004 at 02:06:22PM -0400, Ivica Ico Bukvic wrote: > I see. Thank you all for your insight! > > One last question though, is it possible then to have two different cards to > work as a single device (via asoundrc + JACK) if they would be linked with > some kind of a word-clock that would ensure their hw sync (obviously > assuming that they offer such feature)? yes, should work. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] re: [linux-audio-user] A bit of good news--paper now available for your viewing pleasure and/or comments
On Fri, May 28, 2004 at 01:37:46PM -0400, Ivica Ico Bukvic wrote: > Forgot to add that my assumption is (in addition to my previous statement) > if JACK was then running using reasonably small buffers the drift would be > then minimized if not alleviated since JACK is one that is dispatching the > buffers at appropriate time, right? But each card has its own internal hardware clock that determines the rate at which the DACs consume (and the ADCs produce) data. Software cannot change this. Unless the clocks are locked at the hardware level, one card will produce & consume data to/from jack's alsa IO layer faster than the other. Pretty soon you are screwed. If the cards *are* synced at the hardware level, it should work. This can be done either via word-clock connections if the cards support that, or by a quick hack: connect S/PDIF output on one card to S/PDIF input on the other. Set the second card to use its S/PDIF input as clock source. This hack assumes you have S/PDIF I/O and are willing to sacrifice it for synchronization. -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Re: audio application design problem
On Fri, May 07, 2004 at 11:35:05AM +, [EMAIL PROTECTED] wrote: > On Wed, 05 May, 2004 at 07:10PM +0100, Steve Harris spake thus: > > On Wed, May 05, 2004 at 08:52:57 +0300, Juhana Sadeharju wrote: > > > >From: Christian Henz <[EMAIL PROTECTED]> > > > > > > > >So far I've been using an Observer pattern > > > > > > Are all these patterns described somewhere in the web? > > > People refers mostly to some book(s) but that is not > > > available for me. > > > > You should be able to get it from any decent library. > > > > Gamma, Helm, Johnson and Vlissides "Design Patterns, Elements of Resuable > > Object-Oriented Software" > > Is this the "gang of four" I hear about? In this context, yes :-) There are at least four "gangs of four": the software architects, the rock band, the deposed maoists, and the british social democrats. http://encyclopedia.thefreedictionary.com/Gang%20of%20Four -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] [ANN] Linux Audio Conference #2 live streams, cams and chat available tomorrow
On Wed, Apr 28, 2004 at 02:44:46PM +0200, Joern Nettingsmeier wrote: > hi everyone! > > > for those who have not heard it yet, the second international Linux Audio > Conference is taking place at the ZKM Karlsruhe/Germany from 29.4. to > 2.5.2004. see http://www.zkm.de/lad/ for details. Oh man, I really want to be there so bad :-( Have fun everybody! -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] Linux soundapps pages updated
On Mon, Apr 12, 2004 at 06:00:48PM +0200, Peter Eschler wrote: > On Monday 12 April 2004 15:58, Dave Phillips wrote: > > Jan Nieuwenhuizen wrote: > > > > > Well, it would certainly help if the Linux soundapps pages didn't suck > > so bad. It's all hand-edited HTML, no dynamic content, no user feedback > > or other portals, no real assessments of the software, too little > > information for the entries, et cetera ad nauseam. > > > > I have lost count of the number of proposals I've received to upgrade > > the sites to some more modern format. As Robin Whittle described it, the > > pages are currently merely a monstrous "link farm", useful to some > > extent, but hardly state-of-the-useful-art. I have less than zero time > > to put into upgrading the site, and it is my hope that someday I'll be > > able to turn the whole thing over to the community to turn it into > > something more like what the community (myself included) would like to see. > > Since i did some LAMP sites last year, i have some experience in creating a > dynamic site. Like with everybody else my time is limited, but trying to > bring "Sound & MIDI Software For Linux" into a dynamic form using PHP sounds > like a challenge ;-) FYI, I'm still planning to implement my own proposal which has been discussed quite a lot in the L-A-U archives. I do somewhat similar sites for a living. It just needs me to block out a chunk of time (1 or 2 weekends) to bang it out. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's THE KILLER MACHINE! (random hero from isometric.spaceninja.com)
Re: [linux-audio-dev] Anyone planned a GTK2-based Multitracker?
On Fri, Apr 09, 2004 at 10:04:16PM +0200, Samuel Abels wrote: > On Fri, 2004-04-09 at 21:37, Dave Robillard wrote: > > On 04/09/04 15:30:32, Samuel Abels wrote: > > > I was planning on starting a C++/GTKmm2-based multitracker project using > > > LADSPA and Jackit. Before rolling on I would like to ask if there is > > > already a project planning on something similar. > > > > Gah, use Ardour. > > As nice as Ardour may be, I personaly still prefer the interfaces of > modern UI toolkits, Ardour is going to move to GTK 2 sometime after 1.0. Maybe you could help with that? > in combination with a nice Object Oriented language > (aka C++ :) ). Ardour is written in C++. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's MEGA-MEGATRON BAKER! (random hero from isometric.spaceninja.com)
Re: [linux-audio-dev] Re: PdDSP?
On Thu, Apr 08, 2004 at 05:54:26PM +0200, Mr.Freeze wrote: > Heya, > > Frank Barknecht wrote: > > > Sukandar Kartadinata ist working on something like this for some time > > now. See http://glui.de/proj/gluiph.html for a general project > > description (careful, psycedelic website!) and this PDF: > > Interesting! > > > You could start with the PD for PDA project, which did this, but for > > Pd 0.32. We're now at Pd 0.37 on general purpose computers. > > I'll definitely not go for an ARM-powered expander! > > Let me explain the facts, what I should have done from the beginning: > > I'm planning to build a special controller based on the Theremin, with MIDI > and/or CV outs. All material released for free: schematics, software... IIRC, there was a midi theremin-style controller kit available from PAiA. Check google, what you want might already exist. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's DOOD-CHUCKER! (random hero from isometric.spaceninja.com)
Re: [linux-audio-dev] Visual 3D mixing interface
On Tue, Apr 06, 2004 at 11:11:22AM +0300, Jorma R wrote: > Hi, > > I don't know whether this is old news but interesting anyway: a mixing > interface in which you handle the pan and gain settings by placing > "balls" that represent the instruments (or tracks from a recorder) in a > 3D space. > > Here is the site with samples: > > http://www.globerecording.com/book/mixes/index.html Big fat patent notice on the flash demo :-( -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's POST-EYE UNDERGARMENT! (random hero from isometric.spaceninja.com)
Re: [linux-audio-dev] Some music made with Linux
On Fri, Feb 20, 2004 at 11:11:40PM +0100, David Olofson wrote: > On Friday 20 February 2004 21.27, Paul Winkler wrote: > > Think of the variables introduced by common picking techniques: > > at the least you have to consider stiffness of plectrum (or > > finger), force of pluck, and distance from bridge. > > How about *recording* it instead of trying to emulate it? That is, > separate the excitation impulses from the string resonance, ... Interesting. How the heck do you record that? -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's MAYOR HYDRO-LAMP SNAIL-DOG! (random hero from isometric.spaceninja.com)
Re: [linux-audio-dev] Some music made with Linux
On Fri, Feb 20, 2004 at 02:34:54PM -0500, Pete Bessman wrote: > At Fri, 20 Feb 2004 18:23:52 +0100, > David Olofson wrote: > > > > > Tricky. To get crunchy hard-rock guitar sounds like Pete's > > > (nice track pete!), you'll have to realistically emulate > > > palm-muting, which I've never heard in a synth. And how would you > > > control the amount of muting? Map it to a CC and play a slider? > > Don't think realistic. Think like a synth. If I was a synth, how > would I play guitar? if I were a synth, I would not be able to play guitar, lacking fingers; but since I am myself, I can play guitar or synth depending on what I want ;-) I guess I misjudged the direction of the conversation. I do think it's interesting to think about realistic synth emulation of guitar, but not very practical - it's just so thorny. Palm-muting is just one of the many tricky issues. Think of the variables introduced by common picking techniques: at the least you have to consider stiffness of plectrum (or finger), force of pluck, and distance from bridge. Much more practical, I think, is to do as you suggest: invent synth sounds that capture something of the character and attitude of a given guitar sound without trying to duplicate it sonically. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's ANTI BUNNY-MAKER! (random hero from isometric.spaceninja.com)
Re: [linux-audio-dev] Some music made with Linux
On Fri, Feb 20, 2004 at 05:23:05AM +0100, David Olofson wrote: > On Friday 20 February 2004 00.06, Pete Bessman wrote: > [...] > > Writing a guitar sound synthesizer that sounds good is a very > > difficult thing. The best one out there (the proprietary Slayer > > generator) sounds pretty crummy. Since this song is industrial, > > and the main gist of it is just a few guitar chords, using just a > > few samples of the guitar sounds and some creative song > > restructuring could produce excellent results. > > Yeah, that was my first thought. > > Another approach would be to record the unprocessed guitar sound, > compress/resynthesize that one way or another (plain audio, mp3, > custom tuned compression algos, resynthesis using using physical > modelling etc in increasing order of difficulty), and then apply > guitar FX and speaker emulator plugins on the result. I think the > most important part is to preserve the subtle details from the real > guitar sound, as the lack of realism in the playing technique is what > kills most synthesized guitars I've heard so far. Tricky. To get crunchy hard-rock guitar sounds like Pete's (nice track pete!), you'll have to realistically emulate palm-muting, which I've never heard in a synth. And how would you control the amount of muting? Map it to a CC and play a slider? -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's WIFEBEATER! (random hero from isometric.spaceninja.com)
Re: [linux-audio-dev] TAP Scaling Limiter - how's it work?
On Wed, Feb 18, 2004 at 08:48:02AM +0100, Tom Szilagyi wrote: > Paul Winkler wrote: > >ok - what happens if the input is a 30 hz sine wave? > >assume it's coming from a particularly evil keyboard player ;-) > > > > That's a particularly evil situation. :) i know :-) > The fact is, if you have a > normal musical signal, it will have much higher frequency components so > zero-crosses occur much more frequently than this limit. I investigated > this problem a bit before i settled on that 40 Hz... a mixed signal > (a few instruments together), or higher pitched instruments usually > give average zero-cross frequencies of 8-12 kHz. that high? no kidding? > I tried it with bass > guitar as well (real, no synth) and i didn't run into this limitation. Unless you tried a 5-string, there's no way you'd even get a fundamental below about 40 Hz - low E is just above 40. Low B on a 5-string is somewhere around 30 IIRC. Not too many instruments get below 40 Hz that I know of ... synths and pipe organs, mostly. And they *usually* have a lot of higher freqs mixed in. > So if you take a 30 Hz sinusoidal from an oscillator and feed it into > this plugin, then there will be unprocessed segments just one, right? > of audio because of > not fitting in the ringbuffer. OK. I wondered if it would try to process the last partial segment which might get quite different scaling than the following part of the segment when the next batch of data comes in. > But if you really need that (do you?), No, just satisfying my curiosity :-) > you can increase the ringbuf size and thus decrease this freq lower > limit in the code... at the expense of increasing latency. That's about what I figured. Thanks!! -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's GUILDMASTER SEGWAY! (random hero from isometric.spaceninja.com)
Re: [linux-audio-dev] TAP Scaling Limiter - how's it work?
On Wed, Feb 18, 2004 at 12:29:41AM +0100, Tom Szilagyi wrote: > Yes you can. No, you can't actually, but you can eliminate the problem > so you don't have to solve it. There is a ringbuffer, with a length > chosen so it is capable of containing a whole half-cycle even at low > frequencies (40 Hz is the limit in my implementation, which means > varying number of samples at varying samplerates). ok - what happens if the input is a 30 hz sine wave? assume it's coming from a particularly evil keyboard player ;-) (explanation snipped) OK, I think I have just never really grokked ringbuffers before. Thanks! -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's FLYING FJUKER KO! (random hero from isometric.spaceninja.com)
[linux-audio-dev] TAP Scaling Limiter - how's it work?
Hi folks, and Tom if you're listening, The description of the TAP Scaling Limiter is very interesting - http://tap-plugins.sourceforge.net/#limiter I'm just curious, having done no real DSP coding - it must do some internal buffering, right? So how does it deal with half-cycles that fall on the edge of a buffer? It seems to me that you can't process the final half-cycle without refilling the buffer, but you can't refill the buffer until you've processed all its data - or can you? -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's FIGHTER CARBOHYDRATE! (random hero from isometric.spaceninja.com)
Re: [linux-audio-dev] Software with source code?
(I'm moving this to linux-audio-user where the rest of this discussion has been held. Please direct replies there) On Tue, Feb 03, 2004 at 07:17:45PM +0100, Dave Griffiths wrote: > At the risk of being pedantic, what is wrong with the sound/audio section of > freshmeat? A good question. At first glance not much. But I do have the following gripes, and maybe some more I haven't thought of yet ;-) * Somewhat lacking in categories for audio/music apps. As far as I can tell, submitters cannot influence what categories their app should go in. * You have to be logged in to submit anything. In a smaller community, I think we can relax this requirement, especially since admins will be able to undo any malicious changes. * No source code available to the freshmeat software. (see the FAQ.) I plan to make all my stuff open source. * Freshmeat will probably never do cool stuff like automatically track releases in the audio-specific distros. * Freshmeat rejects "trivial" submissions. I can understand the reasoning, but I don't agree with this. http://freshmeat.net/articles/view/198/ * Freshmeat is too large and too general. It doesn't give me warm fuzzy LAD/LAU community feelings. * Banner ads. Fooey. And finally... * They don't have a logo with a cute penguin wearing headphones. This is unforgivable. All that said, since they export their backend RDF files, we should be able to re-use a whole lot of stuff from freshmeat, and/or use their xml-rpc api to forward our own submissions to freshmeat. Not sure about the best way to do all this, but I'm sure Steve will help ;-) > Dave's site is great because it is so low tech imho. Low tech is great unless you're the guy that does all the work :-) > I think for advocacy purposes and general coolness, it would be nice > to have a > site devoted to linux _musicians_ where we can upload and compare tracks and > production methods. More of an extension of LAU... Sure, the more the merrier. But I don't want to lose focus. You can build that site if you want :-) There has been talk on the consortium_p list of having linuxaudio.org be a sort of portal for various subdomains which can be maintained independently. So my proposal could live at something like apps.linuxaudio.org or similar. A musician portal could either be based on linuxmusician.com (yes, it exists, check it out!) or something similar at e.g. musician.linuxaudio.org. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's STRATA-MINIATURE THE END OF THE WORLD! (random hero from isometric.spaceninja.com)
