Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7534 discussions

by Bob Ham

I thought I'd provide a little dramatisation of what this whole debacle looks like to me: <Daniel> LAD_Dude_1: Hey dude, I've got this idea for a group to help linux audio developers and corporate interests get along better, what do you think? <LAD_Dude_1> Daniel: Sounds like a good idea. <Daniel> LAD_Dude_2: What do you think? <LAD_Dude_2> Daniel: Aye, sounds good. Going to need a web site and mailing list and whatnot tho. <Daniel> Aye, I'll register linuxaudio.org <Daniel> Mandrake (TM): You interested? <Mandrake (TM)> Daniel: Definately <Marek (overhearing)> Daniel: Hey! I was going to do that! You bastard! <Marek> LAD_People: HEY! DANIEL'S STARTED A WHOLE LINUX AUDIO DEVELOPER'S CONSORTIUM WITHOUT CONSULTING ANY OF US! <LAD_Dude_3> WTF?! <LAD_Dude_4> What a bastard! <LAD_Dude_5> How dare you! <Daniel> Hold on a sec, dudes, it doesn't exist yet. I haven't even written a web page! <LAD_Dude_4> What a bastard! <LAD_Dude_5> How dare you! To those shouting "bastard!", I say: chill, for the moment at least. I also provide below a mail I sent to Joern Nettingsmeier before christmas. While Daniel's and my ideas differ somewhat in the necessary approach; co-operation vs defense, our aim is the same: to help bring linux audio software out of bedrooms and into studios while maintaining the freedom of that software. It's worth noting that whether or not a party is a corporation or a tree hugging hippy (to epitomise the two sides of that coin) is irrelevant; the issue is whether or not they support free software, or the kind of proprietary software that stifles the communities that have developed around places like the linux-audio-dev list. I know plenty of tree hugging hippies that are more than willing to embrace propietary software, and plenty of corporations prepared to stand firm on the principles of software freedom. The mailing list I wanted to create is one that I expect will come to exist at linuxaudio.org. The linuxaudio.org site is only the second linux audio site I have noted that consistently uses the term "libre" or "free" instead of "open source" or "linux" software (the other site being AGNULA's; and guess which new consortium they're members of) and that goes some way toward allaying any fears I personally have about the consortium sucking up to the proprietary software industry. Anyway, another too-long email to add to the fire, but I hope it might dampen rather enflame it. Bob -----Forwarded Message----- > From: Bob Ham <rah(a)bash.sh> > To: Joern Nettingsmeier <nettings(a)folkwang-hochschule.de> > Subject: Re: hosting a free-audio-dev list > Date: Fri, 19 Dec 2003 19:08:22 +0000 > > On Fri, 2003-12-19 at 08:34, Joern Nettingsmeier wrote: > > Bob Ham wrote: > > > Hi there, > > > > > > I was wondering if it would be possible to start a mailing list to > > > discuss issues of freedom specifically relating to audio software. I > > > know I feel restricted by something like a taboo about free vs > > > proprietary discussions on linux-audio-dev. I think a place where that > > > kind of discussion was encouraged would be beneficial. > > > > hmmm. i must confess i'm not sure this is a good idea... > > i don't know why you perceive a taboo on lad to discuss such issues - > > you are right, this topic is rare, but then, IMNSHO it rarely leads to > > productive results :) > > This is the "taboo" that I speak of :) Ie, the view that wooly issues > of freedom do little to progress the technical state of the software > while introducing extra noise. > > > my fear with a list like you propose is that it might become an > > "advocacy" forum with all kinds of people with not much else to do > > sounding off about <your favourite licence here> and getting into all > > kinds of flamewars. > > And this extends the taboo :) No, "talking about freedom" does not mean > discerning the finer points of freedom from the perspectives of GPL and > BSD licenses (at least, not to me.) There are plenty of other forums > for that already, eg slashdot.org. What I want to talk about is > Steinberg. And Apple. And Microsoft. And other threats to the free > audio software community. For that matter, I want a place where the > free audio software community can flourish. For *that* matter, I *want* > a free audio software community; support for freedom is somewhat soft on > LAD. This is the time when it needs to be cemented. Linux (and free > software) is moving places and the companies that hang on to the > proprietary idea will be throwing their own little microsoft-like > wobblies when the time comes. A forum that encourages support against > this can be nothing but a good thing in my eyes. The fact that LAD is > linux-specific is another issue; freedom is an issue enclosing > proprietary OSes and free OSes alike. > > To take a crystal example, the GMPI group reflects the need for such a > community. As far as I know, there is nobody whose express purpose in > being involved in GMPI is to represent the interests of software > freedom. A place where such advocacy could come from would be a good > thing IMHO. > > > > possible for you host a free-audio-dev list? > > > > if more people on the lists share your view and would like to have such > > a list, certainly. > > > > although i would prefer something like "linux-audio-freedom" or > > whatever, to keep things consistent. otoh, if it's not linux and lad > > community centered, then i think it should be hosted somewhere else > > The reason for me asking was purely a technical one; you were the first > person I thought of when I asked "who can host a free audio developers > list?" :) Of course, being in close proximity to linux-audio-dev would > be a plus. And free-audio-dev is consistent as well :) Though, if not > being linux-specific puts you off, I shall ask elsewhere. > > Bob -- Bob Ham <rah(a)bash.sh>

22 years

[linux-audio-dev] [OT] Fw: 4 Open positions at the Music Technology Group

by Maarten de Boer

Begin forwarded message: The Music Technology Group of the Universitat Pompeu Fabra in Barcelona (www.iua.upf.es/mtg), a research group known for its work on audio processing technologies and their musical and multimedia applications, has 4 open positions in different areas and projects: - Graphical interface designer and programmer (MTG-2004-01-UI) - Young researcher: Java, C++ and Artificial Intelligence (MTG-2004-01-PAI) - Young researcher: Audio signal processing (MTG-2004-01-PSP) - Technician for digital music library classification (MTG-2004-01-DML) Find the details on our web page (Join us section). Interested people should send an updated resume (CV) to Salvador Gurrera (sgurrera(a)iua.upf.es).

22 years

Re: [linux-audio-dev] Re: linuxaudio.org

by Taybin Rutkin

Has anyone actually been denied membership to the mailing list yet? I'm sure the creator of the list had some reasons for that choice. Taybin -----Original Message----- From: Dave Robillard <drobilla(a)connect.carleton.ca> Sent: Jan 21, 2004 12:06 PM To: The Linux Audio Developers' Mailing List <linux-audio-dev(a)music.columbia.edu> Subject: Re: [linux-audio-dev] Re: linuxaudio.org On Wed, 2004-01-21 at 13:32, Marek Peteraj wrote: > > You sound paranoid. > > http://lists.linuxaudio.org/cgi-bin/mailman/listinfo/consortium-p > > Marek I would really rather not fuel this thread (personally I think both sides are being incredibly stupid) but this is the one thing that bothers me. Why is this list closed? Memership "will be held for approval", and the archive isn't available for browsing.. what gives? Certainly not the way things are done in the 'open source community'.. -Dave

22 years

[linux-audio-dev] Re: [Jackit-devel] Announce - jack.clock

by Steve Harris

On Wed, Jan 21, 2004 at 01:06:03 +1100, Rohan Drape wrote: > > Also, what OSC library are you using? libOSC and OSC Kit seem to be > > non-rentrant and a bit painful to use. > > jack.clock implements only a subset of the OSC protocol, more or less > the same subset as SuperCollider [SC3], and for more or less the same > reasons. In particular it does not implement the patten matching > rules and does not implement a scheduler for incoming messages [ie. it > does not accept incoming bundles]. I will add a note to this effect > in the manual. Restricting address names to seven printing characters > makes method dispatch an eight byte equality operation. Given this > the implementation is straightforward and does not require a library > beyond a simple network/host byte order convenience set. The current > implementation is unneccesarily restritive about the type of numerical > arguments, this should be relaxed, which will require a slightly more > sophistcated infrastructure. I looked briefly at the libraries you > mention a few years ago and decided much the same thing. Thanks, thats helpful. I have a number of things I'd like to use OSC for (and I've heard plenty of other linux audio people talking about starting to use it), but theres a few things that bug me about it: * Libraries not great. this seems solved by using the subset you're talking about, I think it will be fine for my applications. I dont like reinventing the wheel, but I need threadsafeness, and implementing a library for the subset youre talking about seems easy. * No service discovery. This is a big deal, but can be solved /if/ we define a service discovery service before too many more people implement OSC support :) The current situation where people just try to pick a port number noone else is using (AFAICT) and hope it gets telepathically transmitted to its peers is a bit fragile. Unless theres a database of port ranges I haven't found? * No method query. It would be nice if there was a well-known method that caused some metadata about the other methods to be dumped. Maybe there is and I just haven't seen it. This could also be done in the service discovery stage though, through advertisment. FWIW (I have some experience of optimising URL matchers), I would produce a 64bit (or maybe only 32bit) hash of the paths, hash up incoming paths and do a match on that. Its pretty quick (the only extra operation is the hash and it will be < 1000 P3 cycles to execute), and allows arbitrary length paths. I'm very happy to discussus a GPL'd library implementation or service discovery, but we should probably continue on l-a-d. I should really have posted my questions there too. I've CC'd this reply. - Steve

22 years

[linux-audio-dev] Ron Parker and Mirror Image in Sound on Sound

by Daniel James

Hello all, The feature I wrote on Ron Parker's studio starts on page 208 of the February 2004 issue of Sound on Sound magazine, out today. It also has a section featuring Mark Knecht, and contributions from Steve Harris. The article is mostly about using Ardour, JACK and JAMin together. The article is also on the SoS website, but it is only available to subscribers for the first six months. http://www.soundonsound.com/sos/feb04/articles/mirrorimage.htm Cheers Daniel

22 years

[linux-audio-dev] New name for ladcca?

by Bob Ham

Hi all, The name "LADCCA" was always intended to be a working name but even though there's a long way to go, it's out there and people seem to be using it. I wouldn't worry about it that much, but the first thing anyone seems to say about LADCCA is "what a horrible name" :) I'm crap at thinking up stuff like this (JACK Rack was originally called "JACK LADSPA Host" :) so if anyone has any decent ideas, please let me know. Cheers, Bob -- Bob Ham <rah(a)bash.sh> "At some point, keystroke recorders got installed on several machines at Valve. Our speculation is that these were done via a buffer overflow in Outlook's preview pane." -- Gabe Newell on the Half-Life 2 source leak

22 years

Re: [linux-audio-dev] Re: linuxaudio.org

by iriXx

Marek Peteraj wrote: > Suddenly you're now speaking as the representative of the whole Linux > >audio community. But you're not. Neither am I. The only true >representatives of the Linux Audio community are the Linux Audio >Developers. > ehh?? where's the logic in that?? as a composer, i say: what good is my writing music without an audience to hear it? what good is it writing applications, if there is noone to use them? what good is a body, if every part of it wanted to be a hand, or a foot? it would not function without eyes, nose, ears... you speak as if the Linux Audio Developers are some kind of gods... but none of us would exist in this community without each other. thats what c-o-m-m-u-n-i-t-y means. m~ -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. --Benjamin Franklin |\ _,,,---,,_ ZZZzz /,`.-'`' -. ;-;;,_ HTTP 503: Too Busy |,4- ) )-,_. ,\ ( `'-' '---''(_/--' `-'\_) fL .::. www.iriXx.org .::. www.copyleftmedia.org.uk .::.

22 years

[linux-audio-dev] [ANN] TimeMachine 0.2.1

by Steve Harris

http://plugin.org.uk/timemachine/ * Now uses GTK, instead of SDL to draw the window, hopefully a bit more friendly on maintainers. * Meters. * Now records up to 8 channels (use the -c flag). * Can set the output directory/file prefix (-p flag). * Hiting the window close icon now makes sure you have all the data written to disk. I've a feeling that someone mailed me a patch and I've lost it and not included it, so if its you please mail me again. Enjoy, Steve

22 years

[linux-audio-dev] Two or more monitors) Re: Project: modular synth editor

by gml＠xs4all.nl

A) Xinerama _does_ support open GL, at least with my matrox card, I can have openGL on one monitor of the two. That is a limitation of the card hardware, AFAIK, not of X. Still there are a lot of these cards around so openGL would not be very useful. B)ergonomics Mutli head setups are extremely useful. I can easily see both monitors without turning my head, and in a glance I can see the state of several applications. Or I have the documentation in a browser on one monitor and the app on another. Much easier on the brain than constantly switching workspaces back and forth. In a studio there is also a lot of other gear that needs to be watched; mixing-desk, outboard equipment, talent etc. Using a multihead setup you can put the transport and the metering on a monitor near the console, and the editor window on a monitor optimally placed for "desk-work" ergonomics (eye height, keyboard at the right place etc) It is also adviced to move your eyefocus around during work to prevent RSI. (look out a window etc.) Focusing to much on a relatively tiny area all the time is very bad ergonomics. So head movement by itself is not bad, the opposite in fact. Gerard > From: Kjetil Svalastog Matheussen <k.s.matheussen(a)notam02.no> > Benjamin Flaming: >> >> "People without working hardware acceleration" includes anyone >> using more >> than one monitor. X refuses to allow hardware acceleration with >> Xinerama. >> Since multiple monitors are central to my working style (and that of >> many >> recording studios), using OpenGL could have serious drawbacks. >> > > Programs where it makes sense using two or more monitors are in my opinion > seriously crippled. Its about 2.3 million times faster (rough guess) to > press a key (to switch to another view) than to turn your head. In > addition, you can get wiplash (or something similar) by turning your head > too much. Please explan why I'm wrong, if I am. > > > --

22 years

[linux-audio-dev] (Two or more monitors) Re: Project: modular synth editor

by Kjetil Svalastog Matheussen

Benjamin Flaming: > > "People without working hardware acceleration" includes anyone using more > than one monitor. X refuses to allow hardware acceleration with Xinerama. > Since multiple monitors are central to my working style (and that of many > recording studios), using OpenGL could have serious drawbacks. > Programs where it makes sense using two or more monitors are in my opinion seriously crippled. Its about 2.3 million times faster (rough guess) to press a key (to switch to another view) than to turn your head. In addition, you can get wiplash (or something similar) by turning your head too much. Please explan why I'm wrong, if I am. --

22 years

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev