From torbenh at gmx.de Sun Jan 1 07:18:09 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Sun Jan 1 07:25:56 2006 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <1136034186.4661.75.camel@localhost.localdomain> References: <200512301701.jBUH197n032711@roar.music.columbia.edu> <200512302227.56472.pedro.lopez.cabanillas@gmail.com> <1135980644.4661.62.camel@localhost.localdomain> <20051230230426.GC4958@linux-1> <1136034186.4661.75.camel@localhost.localdomain> Message-ID: <20060101121809.GA4344@mobilat> On Sat, Dec 31, 2005 at 08:03:06AM -0500, Paul Davis wrote: > On Sat, 2005-12-31 at 00:04 +0100, fons adriaensen wrote: > > On Fri, Dec 30, 2005 at 05:10:44PM -0500, Paul Davis wrote: > > > On Fri, 2005-12-30 at 22:27 +0100, Pedro Lopez-Cabanillas wrote: > > > > On Friday 30 December 2005 17:37, Werner Schweer wrote: > > > > > > > > > The ALSA seq api is from ancient time were no realtime threads were > > > > > available in linux. Only a kernel driver could provide usable > > > > > midi timing. But with the introduction of RT threads the > > > > > ALSA seq api is obsolete IMHO. > > > > > > > > I don't agree with this statement. IMHO, a design based on raw MIDI ports used > > > > like simple Unix file descriptors, and every user application implementing > > > > its own event schedule mechanism is the ancient and traditional way, and it > > > > should be considered obsolete now in Linux since we have the advanced > > > > queueing capabilities provided by the ALSA sequencer. > > > > > > low latency apps don't want queuing they just want routing. this is why > > > the ALSA sequencer is obsolete for such apps. frank (v.d.p) had the > > > right idea back when he started this, but i agree with werner's > > > perspective that the queuing facilities are no longer relevant, at least > > > not for "music" or "pro-audio" applications. > > > > I'd agree with Pedro on this. > > > > 1. If things have to be timed accurately, it seem logical to concentrate > > this activity at one point. At least then the timing will be consistent, > > you can impose priority rules in case of conflict, etc. > > in a low latency *live* system, "timing" doesn't really exist outside of > the current period. there is no concept of "when" that exists beyond the > end of the current period. to remove jitter i would delay all events i recive during one period calculation by one period. so exact timestamping is very vital. there are only 2 things a live setup can do with an event received during calculating the current audio buffer. 1. play as fast as possible... results in midievents jittering to period boundaries. 2. add some fixed delay so that if the events were received in 10 sample clocks distance they are injected into the system with a 10 sample time distance. -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From mista.tapas at gmx.net Sun Jan 1 08:45:42 2006 From: mista.tapas at gmx.net (Florian Schmidt) Date: Sun Jan 1 08:45:48 2006 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <20060101121809.GA4344@mobilat> References: <200512301701.jBUH197n032711@roar.music.columbia.edu> <200512302227.56472.pedro.lopez.cabanillas@gmail.com> <1135980644.4661.62.camel@localhost.localdomain> <20051230230426.GC4958@linux-1> <1136034186.4661.75.camel@localhost.localdomain> <20060101121809.GA4344@mobilat> Message-ID: <20060101144542.53ca89b7@mango.fruits.de> On Sun, 1 Jan 2006 13:18:09 +0100 torbenh@gmx.de wrote: > > in a low latency *live* system, "timing" doesn't really exist outside of > > the current period. there is no concept of "when" that exists beyond the > > end of the current period. > to remove jitter i would delay all events i recive during one period > calculation by one period. so exact timestamping is very vital. > > there are only 2 things a live setup can do with an event received > during calculating the current audio buffer. > 1. play as fast as possible... results in midievents jittering to period > boundaries. > 2. add some fixed delay so that if the events were received in 10 sample > clocks distance they are injected into the system with a 10 sample time > distance. Of course in my original post i assumed that softsynths use this second scheme (with exactly one period extra delay) otherwise all the hassle with midi thread priorities would be void anyways: "Anyways, one more thing to note is for this to work nicely, the softsynth needs to have an extra midi handling thread that is also running with a priority in the 90s range, so it can timestamp the event properly when it arrives." "The interesting number is the "diff" output as it tells us the difference of the previous midi event timestamp to the current one.The "next" field is the offset into the currently to-be-processed period." Only implicitly so, but let's assume the scheme you mentioned as given from now on. Paul's post was a bit ambiguous though i must admit. Flo -- Palimm Palimm! http://tapas.affenbande.org From bwanab+lad at juraview.com Sun Jan 1 11:13:45 2006 From: bwanab+lad at juraview.com (Bill Allen) Date: Sun Jan 1 11:13:54 2006 Subject: [linux-audio-dev] Interaction bug between zynaddsubfx and muse. Message-ID: <43B7FFB9.6090406@juraview.com> Hi. I'm writing to the list as opposed to the individual app owners since I can't really tell where the bug is. I have a sequence in which I want to use zynaddsubfx as the bass and another instance of zynaddsubfx for synth strings. The problem that I see is when I add the base instance to the bass track, muse then gray's out both instances (which have the same name, so I assume that muse is going through the list graying out any instance with the given name). I do notice in qjackctl's connection screen that the two instances of zynaddsubfx midi out have the same name although obviously they are on different ports. The zynaddsubfx audio instances have different names. This could be a bug - I'm not familiar enough with the jack naming conventions to definitively state this though. However, when I do the same in rosegarden4, it works fine. Rosegarden4 seems to key its list of softsynths with the name and port number. Thus, in conclusion it seems that zynaddsubfx might be at fault in that multiple instances advertise themselves with the same midi out name. I tested several other softsynths. It seems that ams, spiral modular synth and hydrogen also share this characteristic. AmSynth appends a "serial number" to new instances in the midi client list and I tested that muse does indeed work fine with muliple instances of AmSynth. Muse might be at fault because it uses only the midi out name instead of looking also at the port number. Given the number of softsynths that follow the convention of identifying themselves by non-unique names, I think muse should probably add the port number to the identifier to tell instances of the same softsynth apart. From rj at spamatica.se Sun Jan 1 12:42:02 2006 From: rj at spamatica.se (Robert Jonsson) Date: Sun Jan 1 12:42:17 2006 Subject: [linux-audio-dev] Interaction bug between zynaddsubfx and muse. In-Reply-To: <43B7FFB9.6090406@juraview.com> References: <43B7FFB9.6090406@juraview.com> Message-ID: <200601011842.04405.rj@spamatica.se> Hi Bill, On Sunday 01 January 2006 17.13, Bill Allen wrote: > Hi. I'm writing to the list as opposed to the individual app owners > since I can't really tell where the bug is. I have a sequence in which I > want to use zynaddsubfx as the bass and another instance of zynaddsubfx > for synth strings. The problem that I see is when I add the base > instance to the bass track, muse then gray's out both instances (which > have the same name, so I assume that muse is going through the list > graying out any instance with the given name). I do notice in qjackctl's > connection screen that the two instances of zynaddsubfx midi out have > the same name although obviously they are on different ports. The > zynaddsubfx audio instances have different names. This could be a bug - > I'm not familiar enough with the jack naming conventions to definitively > state this though. However, when I do the same in rosegarden4, it works > fine. Rosegarden4 seems to key its list of softsynths with the name and > port number. > > Thus, in conclusion it seems that zynaddsubfx might be at fault in that > multiple instances advertise themselves with the same midi out name. I > tested several other softsynths. It seems that ams, spiral modular synth > and hydrogen also share this characteristic. AmSynth appends a "serial > number" to new instances in the midi client list and I tested that muse > does indeed work fine with muliple instances of AmSynth. > > Muse might be at fault because it uses only the midi out name instead of > looking also at the port number. Given the number of softsynths that > follow the convention of identifying themselves by non-unique names, I > think muse should probably add the port number to the identifier to tell > instances of the same softsynth apart. Indeed, there are several issues at work here... In anycase, MusE has from 0.7.2pre2 a fix that enables synths with identical names to be used. Also, in the case with ZynAdd, another option is to use only one instance. ZynAdd can have one patch for each midi-channel running. The only drawback is that you cannot apply external effects to individual patches, but ZynAdd has a whole bunch of nice internal effects. Regards, Robert -- http://spamatica.se/musicsite/ From fons.adriaensen at skynet.be Sun Jan 1 13:20:23 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sun Jan 1 13:14:36 2006 Subject: [linux-audio-dev] Interaction bug between zynaddsubfx and muse. In-Reply-To: <200601011842.04405.rj@spamatica.se> References: <43B7FFB9.6090406@juraview.com> <200601011842.04405.rj@spamatica.se> Message-ID: <20060101182023.GA4831@linux-1> On Sun, Jan 01, 2006 at 06:42:02PM +0100, Robert Jonsson wrote: > Indeed, there are several issues at work here... > In anycase, MusE has from 0.7.2pre2 a fix that enables synths with identical > names to be used. > Also, in the case with ZynAdd, another option is to use only one instance. > ZynAdd can have one patch for each midi-channel running. The only drawback is > that you cannot apply external effects to individual patches, but ZynAdd has > a whole bunch of nice internal effects. What's probably happening is that recent versions of JACK will if necessary modify a client's name to make it unique, while ALSA doens't because IIRC it doesn't care about the name but identifies clients by a number that it assigns itself. So if you want unique names (and the same) for audio and midi, you still have to provide them on the client's command line. OTOH, sequencers should identify midi connections by their client number, not their name. AMS should handle multiple patches without requiring a separate instance for each. -- FA From rj at spamatica.se Sun Jan 1 13:34:14 2006 From: rj at spamatica.se (Robert Jonsson) Date: Sun Jan 1 13:34:21 2006 Subject: [linux-audio-dev] Interaction bug between zynaddsubfx and muse. In-Reply-To: <20060101182023.GA4831@linux-1> References: <43B7FFB9.6090406@juraview.com> <200601011842.04405.rj@spamatica.se> <20060101182023.GA4831@linux-1> Message-ID: <200601011934.15817.rj@spamatica.se> On Sunday 01 January 2006 19.20, fons adriaensen wrote: > On Sun, Jan 01, 2006 at 06:42:02PM +0100, Robert Jonsson wrote: > > Indeed, there are several issues at work here... > > In anycase, MusE has from 0.7.2pre2 a fix that enables synths with > > identical names to be used. > > Also, in the case with ZynAdd, another option is to use only one > > instance. ZynAdd can have one patch for each midi-channel running. The > > only drawback is that you cannot apply external effects to individual > > patches, but ZynAdd has a whole bunch of nice internal effects. > > What's probably happening is that recent versions of JACK will if necessary > modify a client's name to make it unique, while ALSA doens't because IIRC > it doesn't care about the name but identifies clients by a number that it > assigns itself. > > So if you want unique names (and the same) for audio and midi, you still > have to provide them on the client's command line. OTOH, sequencers should > identify midi connections by their client number, not their name. To my understanding the client number is resolved/assigned at runtime making it practically useless when mapping sources with destinations. The only reliable solution is to assign unique names. Regards, Robert > > AMS should handle multiple patches without requiring a separate instance > for each. -- http://spamatica.se/musicsite/ From nettings at folkwang-hochschule.de Mon Jan 2 19:04:44 2006 From: nettings at folkwang-hochschule.de (Joern Nettingsmeier) Date: Mon Jan 2 19:05:14 2006 Subject: [linux-audio-dev] [admin] music.columbia.edu server downtime Message-ID: <43B9BF9C.7040506@folkwang-hochschule.de> hi everyone! a happy new year to all folks on the gregorian calendar, and a generic happy next 365 days to everyone else! the music department at columbia university are taking the list server down for an upgrade on the coming weekend, so expect interruptions for linux-audio-dev, linux-audio-user and linux-audio-announce. you will probably want to keep a copy of all the mails you send over the weekend, so that you can re-send them in case they end up in the bit bucket. let me take this opportunity to thank douglas irving repetto for many years of painless hosting and friendly help, and the entire music dept. for their generous donation of iron and bandwidth. kudos, guys! rumor has it that the new list server will be an os x machine. hopefully this will make the lists even more user-friendly and aesthetically pleasing than before ;) all the best, j?rn -------- Original Message -------- Subject: music.columbia.edu server downtime Date: Mon, 2 Jan 2006 16:21:13 -0500 From: douglas irving repetto To: douglas@music.columbia.edu Hello, We will be upgrading the music.columbia.edu server this weekend. Hopefully all of the work will be done on Saturday, but it may extend into Sunday. music.columbia.edu will not be available during the downtime. That means no websites will be served, no email will be sent/delivered, no mailing lists will function, etc. I'll send an update later this week with info about some changes that you'll see on the new server. Happy new year, douglas -- ............................................... http://artbots.org .....douglas.....irving........................ http://dorkbot.org ................................ http://ceait.calarts.edu/musicdsp .......... repetto....... http://works.music.columbia.edu/organism ............................... http://music.columbia.edu/~douglas -- j?rn nettingsmeier home://germany/45128 essen/lortzingstr. 11/ http://spunk.dnsalias.org phone://+49/201/491621 if you are a free (as in "free speech") software developer and you happen to be travelling near my home, drop me a line and come round for a free (as in "free beer") beer. :-D From marauder at tiscali.it Mon Jan 2 19:14:21 2006 From: marauder at tiscali.it (David Santinoli) Date: Mon Jan 2 19:14:25 2006 Subject: [linux-audio-dev] Olypus voice recorder - codec? In-Reply-To: <1135968994.9164.103.camel@seki.nac.uci.edu> References: <1135968994.9164.103.camel@seki.nac.uci.edu> Message-ID: <20060103001421.GA480@aidi.santinoli.com> On Fri, Dec 30, 2005 at 10:56:34AM -0800, Dan Stromberg wrote: > > Does anyone have any suggestions - especially toward how to convert > that "likely voice data" in the USB Sniff to some sort of known and > supported-on-linux codec? AFAICT the encoding should be (Adaptive Differential Pulse Code Modulation). Don't know about the file container though... Cheers, David -- Palantir home page: http://www.fastpath.it/products/palantir Palantir support: From mle+la at mega-nerd.com Tue Jan 3 01:50:43 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Tue Jan 3 01:50:51 2006 Subject: [linux-audio-dev] Olypus voice recorder - codec? In-Reply-To: <20060103001421.GA480@aidi.santinoli.com> References: <1135968994.9164.103.camel@seki.nac.uci.edu> <20060103001421.GA480@aidi.santinoli.com> Message-ID: <20060103175043.3bea450c.mle+la@mega-nerd.com> David Santinoli wrote: > AFAICT the encoding should be (Adaptive Differential Pulse Code > Modulation). Don't know about the file container though... There are at least 50 different, mutually incompatible types of ADPCM. For instance, libsndfile supports: SF_FORMAT_IMA_ADPCM /* IMA ADPCM. */ SF_FORMAT_MS_ADPCM /* Microsoft ADPCM. */ SF_FORMAT_VOX_ADPCM /* OKI / Dialogix ADPCM */ SF_FORMAT_G721_32 /* 32kbs G721 ADPCM encoding. */ SF_FORMAT_G723_24 /* 24kbs G723 ADPCM encoding. */ SF_FORMAT_G723_40 /* 40kbs G723 ADPCM encoding. */ which is a mere drop in the bucket. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ Question #2459: Ruling on shaking hands with the opposite sex http://islamqa.com/index.php?ln=eng&ds=qa&lv=browse&QR=2459&dgn=4 From Cedric.Roux at eurecom.fr Tue Jan 3 09:44:12 2006 From: Cedric.Roux at eurecom.fr (Cedric Roux) Date: Tue Jan 3 09:44:16 2006 Subject: [linux-audio-dev] [ANN] sverb 0.9 Message-ID: Hello Linux Audio People, sverb is a CFDN order 15 reverb. It is available at: http://sed.free.fr/sverb 0.9 is the first public release. Any help/hacking/whatever is very welcome. Take care, C?dric. From mista.tapas at gmx.net Tue Jan 3 11:40:30 2006 From: mista.tapas at gmx.net (Florian Schmidt) Date: Tue Jan 3 11:40:37 2006 Subject: [linux-audio-dev] [ANN] sverb 0.9 In-Reply-To: References: Message-ID: <20060103174030.52708133@mango.fruits.de> On Tue, 3 Jan 2006 15:44:12 +0100 (CET) Cedric Roux wrote: > Hello Linux Audio People, > > sverb is a CFDN order 15 reverb. > It is available at: > http://sed.free.fr/sverb > > 0.9 is the first public release. > > Any help/hacking/whatever is very welcome. build failure reports, too? Here's one in any case: gcc -Wall -O3 -ffast-math -fomit-frame-pointer `pkg-config gtk+-2.0 --cflags` -o sverb_gui.o -c sverb_gui.c sverb_gui.c: In function 'audio_ready': sverb_gui.c:124: error: invalid storage class for function 'impulse_play_callback' sverb_gui.c:125: error: invalid storage class for function 'alert' sverb_gui.c:126: warning: implicit declaration of function 'impulse_play_callback' sverb_gui.c:127: warning: implicit declaration of function 'alert' sverb_gui.c: At top level: sverb_gui.c:331: warning: conflicting types for 'alert' sverb_gui.c:331: error: static declaration of 'alert' follows non-static declaration sverb_gui.c:127: error: previous implicit declaration of 'alert' was here sverb_gui.c: In function 'file_event': sverb_gui.c:365: warning: implicit declaration of function 'strlen' sverb_gui.c:365: warning: incompatible implicit declaration of built-in function 'strlen' sverb_gui.c:370: warning: implicit declaration of function 'strcpy' sverb_gui.c:370: warning: incompatible implicit declaration of built-in function 'strcpy' sverb_gui.c: In function 'do_load': sverb_gui.c:520: warning: incompatible implicit declaration of built-in function 'strcpy' sverb_gui.c: In function 'do_save': sverb_gui.c:611: warning: incompatible implicit declaration of built-in function 'strcpy' sverb_gui.c: In function 'update_menu_callback': sverb_gui.c:637: error: invalid storage class for function 'update_impulse_callback' sverb_gui.c:638: warning: implicit declaration of function 'update_impulse_callback' sverb_gui.c: In function 'play_menu_callback': sverb_gui.c:643: error: invalid storage class for function 'impulse_play_callback' sverb_gui.c: In function 'preset_callback': sverb_gui.c:694: warning: implicit declaration of function 'strcmp' sverb_gui.c: At top level: sverb_gui.c:878: warning: conflicting types for 'update_impulse_callback' sverb_gui.c:878: error: static declaration of 'update_impulse_callback' follows non-static declaration sverb_gui.c:638: error: previous implicit declaration of 'update_impulse_callback' was here sverb_gui.c: In function 'update_impulse_callback': sverb_gui.c:886: error: invalid storage class for function 'impulse_play_callback' sverb_gui.c: At top level: sverb_gui.c:904: warning: conflicting types for 'impulse_play_callback' sverb_gui.c:904: error: static declaration of 'impulse_play_callback' follows non-static declaration sverb_gui.c:126: error: previous implicit declaration of 'impulse_play_callback' was here In file included from sverb_gui.c:1371: help_gui.h: In function 'sverb_gui_init': help_gui.h:3: warning: missing sentinel in function call help_gui.h:6: warning: missing sentinel in function call help_gui.h:9: warning: missing sentinel in function call help_gui.h:12: warning: missing sentinel in function call help_gui.h:15: warning: missing sentinel in function call help_gui.h:18: warning: missing sentinel in function call help_gui.h:21: warning: missing sentinel in function call help_gui.h:24: warning: missing sentinel in function call help_gui.h:27: warning: missing sentinel in function call ...plus more of these. Flo -- Palimm Palimm! http://tapas.affenbande.org From b0ef at esben-stien.name Tue Jan 3 14:46:12 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Tue Jan 3 12:53:25 2006 Subject: [linux-audio-dev] [admin] music.columbia.edu server downtime In-Reply-To: <43B9BF9C.7040506@folkwang-hochschule.de> (Joern Nettingsmeier's message of "Tue, 03 Jan 2006 01:04:44 +0100") References: <43B9BF9C.7040506@folkwang-hochschule.de> Message-ID: <87u0clnlh7.fsf@esben-stien.name> Joern Nettingsmeier writes: > new list server will be an os x machine Damn, such irony, in my opinion. I'd vote to bring it to savannah and change the name to GNU/Linux Audio Developers;), same with the user list. -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From rlrevell at joe-job.com Tue Jan 3 13:08:51 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Tue Jan 3 13:08:58 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] [admin] music.columbia.edu server downtime In-Reply-To: <87u0clnlh7.fsf@esben-stien.name> References: <43B9BF9C.7040506@folkwang-hochschule.de> <87u0clnlh7.fsf@esben-stien.name> Message-ID: <1136311732.24703.51.camel@mindpipe> On Tue, 2006-01-03 at 20:46 +0100, Esben Stien wrote: > Joern Nettingsmeier writes: > > > new list server will be an os x machine > > Damn, such irony, in my opinion. I'd vote to bring it to savannah and > change the name to GNU/Linux Audio Developers;), same with the user > list. > Yeah WTF?!? Why OSX? Linux isn't a good enough server platform? Sorry I think that running LAD on an OSX machine is bullshit. Lee From mista.tapas at gmx.net Tue Jan 3 21:55:09 2006 From: mista.tapas at gmx.net (Florian Schmidt) Date: Tue Jan 3 21:55:14 2006 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <20051230170424.7179897f@mango.fruits.de> References: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> <20051230170424.7179897f@mango.fruits.de> Message-ID: <20060104035509.00732a3d@mango.fruits.de> On Fri, 30 Dec 2005 17:04:24 +0100 Florian Schmidt wrote: > I also stumbled across some problems with sleep() and especially waking > up when the sleep time has expired in the course of writing my > rt_watchdog program. Sometimes the high prio SCHED_FIFO thread wasn't > woken up as long as a lower SCHED_FIFO prio thread hugged the cpu even > when the sleep time of the high prio thread was long expired.. Ingo told > me back then that there's extra kernel threads for the timing subsystem > which need to be setup to high prios too for this to work correctly. > Haven't really investigated further into this. > > I need to write another small test app that uses sleep based timing and > a high prio, too, to drive ughsynth. Will report what results i get. Ok, as Ingo has told me before (and which i just remembered again today): To make sure threads actually do get woken up after their sleep() time elapses one needs to make the softirq-timer/0 thread (only in -rt) systems high priority, too (higher than jack). I actually implemented a small sleep() based midi note generator (similar to the rtc based one) and the results i get are a little worse than with the rtc based timer, but not by thaaat much: diff: 6047 diff: 5999 diff: 5999 adjusted midi event [frame offset >nframes] - handed to next period diff: 5999 diff: 6048 diff: 5998 diff: 6000 diff: 6047 diff: 5999 diff: 5999 diff: 5999 diff: 6047 diff: 5999 diff: 6000 diff: 5999 diff: 6047 That's in the 1-2% jitter range which is still fine for me. Rosegarden in 2.6.14 vanilla and with the adjusted softirq-timer/0 kernel thread works a lot better than w/o the adjustment (naturally) when using the system timer as timing source. So all -rt users beware, make your softirq-timer/0 thread high prio, too :) Benefits seq24, too. Regards, Flo P.S.: if you want to make your own experiments, here's the updated tarball with the sleep() and rtc based test note generators (they only produce note-on events though): http://affenbande.org/~tapas/midi_timer-0.tgz -- Palimm Palimm! http://tapas.affenbande.org From Cedric.Roux at eurecom.fr Wed Jan 4 03:54:00 2006 From: Cedric.Roux at eurecom.fr (Cedric Roux) Date: Wed Jan 4 03:54:06 2006 Subject: [linux-audio-dev] [ANN] sverb 0.9 In-Reply-To: <20060103174030.52708133@mango.fruits.de> Message-ID: On Tue, 3 Jan 2006, Florian Schmidt wrote: > build failure reports, too? It should be fixed now. New release: 0.9.1 Thanks for the report. From artemio at kdemail.net Wed Jan 4 04:26:08 2006 From: artemio at kdemail.net (Artemiy Pavlov) Date: Wed Jan 4 04:26:24 2006 Subject: [linux-audio-dev] [ANN] sverb 0.9 In-Reply-To: References: Message-ID: <200601041126.08730.artemio@kdemail.net> Hello Cedric, a LADSPA version, possibly with simplified control options, would be killer! Hint, hint ;-) Artemiy. From Cedric.Roux at eurecom.fr Wed Jan 4 04:40:18 2006 From: Cedric.Roux at eurecom.fr (Cedric Roux) Date: Wed Jan 4 04:40:23 2006 Subject: [linux-audio-dev] [ANN] sverb 0.9 In-Reply-To: <200601041126.08730.artemio@kdemail.net> Message-ID: Hello Artemiy, I agree, but I won't do it. Contributions are very welcome! I have no much time, holidays are gone. :-) C?dric. (For the moment, what is really needed is some good presets, the GUI is here to help in that respect. A 1.0 release should contain at least 4 good presets: short, small, medium, long. Something like that. If some people want to contribute...) On Wed, 4 Jan 2006, Artemiy Pavlov wrote: > Hello Cedric, > > a LADSPA version, possibly with simplified control options, would be killer! > > Hint, hint ;-) > > Artemiy. From b0ef at esben-stien.name Wed Jan 4 10:14:27 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Wed Jan 4 08:21:40 2006 Subject: [linux-audio-dev] OT: Wikipedia, FM and John Chowning In-Reply-To: <20051214190646.GB14568@unununium.org> (Phil Frost's message of "Wed, 14 Dec 2005 14:06:47 -0500") References: <1134444278.9097.6.camel@c80-216-124-251.cm-upc.chello.se> <871x0gicp6.fsf@quasar.esben-stien.name> <1134583456.12086.22.camel@mindpipe> <20051214190646.GB14568@unununium.org> Message-ID: <87d5j8vxd8.fsf@esben-stien.name> Phil Frost writes: > issue of general wiki spam, posting crap, advertisements, etc. If you give into this, you have already lost. A wiki is self maintainable, in my opinion. You can always look up a revision or a signed revision and you can always make one the current one. Those who believe they have to maintain a wiki, have misunderstood what a wiki is;), in my opinion. It will sort itself out and people usually fix the page if something is screwed up. Spam, crap, advertisement; bring it on, I'll revision it off my righteous path. -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From melanie at t-data.com Wed Jan 4 10:54:17 2006 From: melanie at t-data.com (Melanie) Date: Wed Jan 4 10:54:35 2006 Subject: [linux-audio-dev] Alsa device to Jack ports? Message-ID: <43BBEFA9.5030007@t-data.com> Hi, I am using an application which enumerates the ALSA supported hardware devices and offers them as input / output devices. Now, I would much rather have that app output to Jack. The app does support OSS, but only native OSS, it does not offer OSS support when ALSA is available, else I could have used oss2jack. Now I wonder, is there something like alsa2jack? Something that appears as a physical soundcard in ALSA, yet feeds into Jack? Melanie From b0ef at esben-stien.name Wed Jan 4 14:00:36 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Wed Jan 4 12:07:50 2006 Subject: [linux-audio-dev] Alsa device to Jack ports? In-Reply-To: <43BBEFA9.5030007@t-data.com> (melanie@t-data.com's message of "Wed, 04 Jan 2006 15:54:17 +0000") References: <43BBEFA9.5030007@t-data.com> Message-ID: <87r77nu8bv.fsf@esben-stien.name> Melanie writes: > something like alsa2jack? There is no such thing as alsa2jack, as far as I know, though it would be nice. There is the Plug:JACK interface in ALSA. I've used it before, but since I've acquired a RME Multiface II and cannot use it. You'll find info on the alsa wiki and in the official alsa documentation. There are some docs on it. What I did was: (/etc/asound.rc) pcm.jackplug { type plug slave { pcm "jack" } } pcm.jack { type jack playback_ports { 0 alsa_pcm:playback_1 1 alsa_pcm:playback_2 } capture_ports { 0 alsa_pcm:capture_1 1 alsa_pcm:capture_2 } } ..then f.ex mplayer -ao alsa:device=jackplug foo.mkv -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From melanie at t-data.com Wed Jan 4 12:42:44 2006 From: melanie at t-data.com (Melanie) Date: Wed Jan 4 12:43:02 2006 Subject: [linux-audio-dev] Alsa device to Jack ports? In-Reply-To: <87r77nu8bv.fsf@esben-stien.name> References: <43BBEFA9.5030007@t-data.com> <87r77nu8bv.fsf@esben-stien.name> Message-ID: <43BC0914.9090601@t-data.com> Been there, done that. IT actually enumerates _hardware_ sound cards - nothing in .asoundrc is recognized by this app. Melanie Esben Stien wrote: > Melanie writes: > >> something like alsa2jack? > > There is no such thing as alsa2jack, as far as I know, though it would > be nice. > > There is the Plug:JACK interface in ALSA. I've used it before, but > since I've acquired a RME Multiface II and cannot use it. > > You'll find info on the alsa wiki and in the official alsa > documentation. > > There are some docs on it. What I did was: (/etc/asound.rc) > > pcm.jackplug > { > type plug > slave { pcm "jack" } > } > > pcm.jack > { > type jack > playback_ports > { > 0 alsa_pcm:playback_1 > 1 alsa_pcm:playback_2 > } > capture_ports > { > 0 alsa_pcm:capture_1 > 1 alsa_pcm:capture_2 > } > } > > ..then f.ex mplayer -ao alsa:device=jackplug foo.mkv > From paul at linuxaudiosystems.com Wed Jan 4 13:00:49 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Jan 4 12:58:00 2006 Subject: [linux-audio-dev] Alsa device to Jack ports? In-Reply-To: <43BC0914.9090601@t-data.com> References: <43BBEFA9.5030007@t-data.com> <87r77nu8bv.fsf@esben-stien.name> <43BC0914.9090601@t-data.com> Message-ID: <1136397650.24070.45.camel@localhost.localdomain> On Wed, 2006-01-04 at 17:42 +0000, Melanie wrote: > Been there, done that. > > IT actually enumerates _hardware_ sound cards - nothing in .asoundrc > is recognized by this app. this app violates the most basic guideline of ALSA programming from at least 3 or 4 years ago. --p From mista.tapas at gmx.net Wed Jan 4 13:09:30 2006 From: mista.tapas at gmx.net (Florian Schmidt) Date: Wed Jan 4 13:09:35 2006 Subject: [linux-audio-dev] Alsa device to Jack ports? In-Reply-To: <43BC0914.9090601@t-data.com> References: <43BBEFA9.5030007@t-data.com> <87r77nu8bv.fsf@esben-stien.name> <43BC0914.9090601@t-data.com> Message-ID: <20060104190930.41795517@mango.fruits.de> On Wed, 04 Jan 2006 17:42:44 +0000 Melanie wrote: > Been there, done that. > > IT actually enumerates _hardware_ sound cards - nothing in .asoundrc > is recognized by this app. Broken app. Every sane ALSA app should use the pcm device "default" by default and should allow the user to enter any pcm device string. It might additionally provide a list of devices from which the user might choose (for convenience). Write a bug report ;) Flo -- Palimm Palimm! http://tapas.affenbande.org From bwanab+lad at juraview.com Thu Jan 5 06:19:05 2006 From: bwanab+lad at juraview.com (Bill Allen) Date: Thu Jan 5 06:19:17 2006 Subject: [linux-audio-dev] Interaction bug between zynaddsubfx and muse. In-Reply-To: <20060101182023.GA4831@linux-1> References: <43B7FFB9.6090406@juraview.com> <200601011842.04405.rj@spamatica.se> <20060101182023.GA4831@linux-1> Message-ID: <43BD00A9.7090901@juraview.com> fons adriaensen wrote: >On Sun, Jan 01, 2006 at 06:42:02PM +0100, Robert Jonsson wrote: > > > >>Indeed, there are several issues at work here... >>In anycase, MusE has from 0.7.2pre2 a fix that enables synths with identical >>names to be used. >>Also, in the case with ZynAdd, another option is to use only one instance. >>ZynAdd can have one patch for each midi-channel running. The only drawback is >>that you cannot apply external effects to individual patches, but ZynAdd has >>a whole bunch of nice internal effects. >> >> > >What's probably happening is that recent versions of JACK will if necessary >modify a client's name to make it unique, while ALSA doens't because IIRC it >doesn't care about the name but identifies clients by a number that it >assigns itself. > >So if you want unique names (and the same) for audio and midi, you still have >to provide them on the client's command line. OTOH, sequencers should identify >midi connections by their client number, not their name. > >AMS should handle multiple patches without requiring a separate instance >for each. > > > That would be great, as ams is my favorite synth, but I haven't found a way to do it. When you say "should" are you saying that I should be able to find a way, or that somebody should be able to add the capability to it? From fons.adriaensen at alcatelaleniaspace.com Thu Jan 5 07:55:35 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Thu Jan 5 07:55:42 2006 Subject: [linux-audio-dev] Interaction bug between zynaddsubfx and muse. In-Reply-To: <43BD00A9.7090901@juraview.com> References: <43B7FFB9.6090406@juraview.com> <200601011842.04405.rj@spamatica.se> <20060101182023.GA4831@linux-1> <43BD00A9.7090901@juraview.com> Message-ID: <20060105125534.GA7241@bth05w.ABSp.alcatel.be> On Thu, Jan 05, 2006 at 06:19:05AM -0500, Bill Allen wrote: > fons adriaensen wrote: > > > AMS should handle multiple patches without requiring a separate instance > > for each. > > That would be great, as ams is my favorite synth, but I haven't found a > way to do it. When you say "should" are you saying that I should be able > to find a way, or that somebody should be able to add the capability to it? I think it is possible to have two ore more independent patches in monophonic mode, but not if poly > 1. It's some time since I worked on AMS so I could be wrong. There are (again) several issues involved. - AMS has no means to load a second patch while preserving the current one. So you can't combine two existing patches without having to manually recreate at least one of them. - IIRC there are some global variables involved in the hidden communication from ENV generators back to the voice assignment logic in the MIDI controllers. Having two or more really independent patches would require these to be eliminated, and replaced by an explicit path. - The 'poly' setting is also global, but it should be independent in each patch. I made some plans more than a year ago to fix all of this, but it would be a major and very invasive operation. Another factor blocking this was that these changes would probably render some existing patches incompatible, and Matthias didn't like that very much. I still hope to return to AMS some day, and when I do it will be a major reworking of almost everything. So if AMS is your favorite synth I'd like to know - which features are absolutely essential and should not change, - which ones are important but maybe could be done slightly differently, - what can be sacrified in order to make other things possible ? -- FA From rlrevell at joe-job.com Thu Jan 5 15:07:30 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Jan 5 15:07:34 2006 Subject: [linux-audio-dev] Alsa device to Jack ports? In-Reply-To: <43BBEFA9.5030007@t-data.com> References: <43BBEFA9.5030007@t-data.com> Message-ID: <1136491650.847.2.camel@mindpipe> On Wed, 2006-01-04 at 15:54 +0000, Melanie wrote: > The app does > support OSS, but only native OSS, it does not offer OSS support when > ALSA is available I don't understand this statement. Are you saying the app works with native OSS drivers but not with ALSA's OSS emulation? This isn't a closed source app is it? Lee From melanie at t-data.com Thu Jan 5 21:35:57 2006 From: melanie at t-data.com (Melanie) Date: Thu Jan 5 21:36:04 2006 Subject: [linux-audio-dev] Alsa device to Jack ports? In-Reply-To: <1136491650.847.2.camel@mindpipe> References: <43BBEFA9.5030007@t-data.com> <1136491650.847.2.camel@mindpipe> Message-ID: <43BDD78D.1000900@t-data.com> Hi, Lee Revell wrote: > I don't understand this statement. Are you saying the app works with > native OSS drivers but not with ALSA's OSS emulation? The app recognizes the superior sound architecture. When ALSA is detected, OSS is not offered. It is open source, but I have little time to debug it. It uses h323's pwlib. Melanie From strombrg at dcs.nac.uci.edu Thu Jan 5 22:25:00 2006 From: strombrg at dcs.nac.uci.edu (Dan Stromberg) Date: Thu Jan 5 22:25:24 2006 Subject: [linux-audio-dev] Olypus voice recorder - codec? In-Reply-To: <20060103175043.3bea450c.mle+la@mega-nerd.com> References: <1135968994.9164.103.camel@seki.nac.uci.edu> <20060103001421.GA480@aidi.santinoli.com> <20060103175043.3bea450c.mle+la@mega-nerd.com> Message-ID: <1136517900.16210.170.camel@seki.nac.uci.edu> On Tue, 2006-01-03 at 17:50 +1100, Erik de Castro Lopo wrote: > David Santinoli wrote: > > > AFAICT the encoding should be (Adaptive Differential Pulse Code > > Modulation). Don't know about the file container though... > > There are at least 50 different, mutually incompatible types > of ADPCM. For instance, libsndfile supports: > > SF_FORMAT_IMA_ADPCM /* IMA ADPCM. */ The data is coming out of the windows app in this format: IMA ADPCM, that is. But unfortunately, I don't seem to be having much luck discovering what codec they actually spit out of the voice recorder, prior to the application apparently converting it to IMA ADPCM. > SF_FORMAT_MS_ADPCM /* Microsoft ADPCM. */ > SF_FORMAT_VOX_ADPCM /* OKI / Dialogix ADPCM */ > SF_FORMAT_G721_32 /* 32kbs G721 ADPCM encoding. */ > SF_FORMAT_G723_24 /* 24kbs G723 ADPCM encoding. */ > SF_FORMAT_G723_40 /* 40kbs G723 ADPCM encoding. */ > > which is a mere drop in the bucket. > > Erik From smithbone at gmail.com Fri Jan 6 11:09:47 2006 From: smithbone at gmail.com (Richard Smith) Date: Fri Jan 6 11:09:51 2006 Subject: [linux-audio-dev] Olypus voice recorder - codec? In-Reply-To: <1136517900.16210.170.camel@seki.nac.uci.edu> References: <1135968994.9164.103.camel@seki.nac.uci.edu> <20060103001421.GA480@aidi.santinoli.com> <20060103175043.3bea450c.mle+la@mega-nerd.com> <1136517900.16210.170.camel@seki.nac.uci.edu> Message-ID: <8a0c36780601060809v634227b6we0ce882d01a00da3@mail.gmail.com> On 1/5/06, Dan Stromberg wrote: >> The data is coming out of the windows app in this format: IMA ADPCM,> that is.>> But unfortunately, I don't seem to be having much luck discovering what> codec they actually spit out of the voice recorder, prior to the> application apparently converting it to IMA ADPCM. Have you tried feeding in a known constant sources using a signalgenerator? Looking at the output for a 100,500,1k,2k,4k sine wavesmight give you some clues since you should be able to see when thedata repeats. --Richard A. Smith From lazzaro at eecs.berkeley.edu Fri Jan 6 13:36:33 2006 From: lazzaro at eecs.berkeley.edu (lazzaro) Date: Fri Jan 6 13:33:58 2006 Subject: [linux-audio-dev] RTP MIDI I-Ds now in IETF Last Call ... Message-ID: Hi everyone, The Internet-Drafts for the RTP MIDI protocols for sending MIDI over IP are now in "IETF Last Call" -- this is a process where the Internet Engineering Steering Group (IESG) solicits comments from the community at large, before making a decision on whether the protocol should be blessed with standards-track RFC status. See below for information on how to send comments to the IESG (don't send them to me directly -- I can't pass them on). Thanks! ----- From: The IESG Date: January 6, 2006 8:46:17 AM PST To: IETF-Announce Cc: avt@ietf.org Subject: Last Call: 'RTP Payload Format for MIDI' to Proposed Standard Reply-To: iesg@ietf.org The IESG has received a request from the Audio/Video Transport WG to consider the following documents: - 'RTP Payload Format for MIDI ' as a Proposed Standard - 'An Implementation Guide for RTP MIDI ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org mailing lists by 2006-01-20. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-midi- format-14.txt http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-midi- guidelines-14.txt --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- From support at xt-hq.com Sat Jan 7 05:58:49 2006 From: support at xt-hq.com (jorgen) Date: Sat Jan 7 05:58:59 2006 Subject: [linux-audio-dev] VST compiled for linux / gui message loop Message-ID: <43BF9EE9.4020706@xt-hq.com> Hi, Im coding a VST host for windows and linux. The linux version will support VSTs compiled on linux and not using wine or aything. Of course, there is not alot of native linux VST plugins around but that will change (I already made one :P ) There is one challange though, event dispatching in X11. Unlike windows, X11 windows doesnt have an assotiated window proc for dispatching events. I can overcome this in my own gui toolkit by passing a Display* pointer to the plugin etc, but it wouldnt work with other gui toolkits. So how do I make a soution that work with any toolkits on linux? 1) the plugin calls its own event loop in effEditIdle 2) make a new atom "wndproc" for storing wndproc function per window, the host will send XEvents to the wndproc if found. I prefer 1) but I dont know if toolkits supports manually calling the event loop? cheers jorgen From torbenh at gmx.de Sat Jan 7 07:23:40 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Sat Jan 7 07:31:13 2006 Subject: [linux-audio-dev] VST compiled for linux / gui message loop In-Reply-To: <43BF9EE9.4020706@xt-hq.com> References: <43BF9EE9.4020706@xt-hq.com> Message-ID: <20060107122340.GB4336@mobilat> On Sat, Jan 07, 2006 at 11:58:49AM +0100, jorgen wrote: > Hi, Im coding a VST host for windows and linux. The linux version will > support VSTs compiled on linux and not using wine or aything. Of course, > there is not alot of native linux VST plugins around but that will > change (I already made one :P ) :) cool welcome abord. so you ported vstGUI ? how will that work ? does a vst plugin coder only recompile his plug then ? > > There is one challange though, event dispatching in X11. Unlike windows, > X11 windows doesnt have an assotiated window proc for dispatching > events. I can overcome this in my own gui toolkit by passing a Display* > pointer to the plugin etc, but it wouldnt work with other gui toolkits. > > So how do I make a soution that work with any toolkits on linux? we are still searching for a solution with a window generated in the same process. with different toolkits etc. to my knowledge this has not really been solved. believe me, there would be a much nicer standard than dssi already. > 1) the plugin calls its own event loop in effEditIdle > 2) make a new atom "wndproc" for storing wndproc function per window, > the host will send XEvents to the wndproc if found. > > I prefer 1) but I dont know if toolkits supports manually calling the > event loop? i am not sure i understand what you want to do but..... for gtk see: http://www.gtk.org/api/2.6/gtk/gtk-General.html#gtk-main-iteration-do for qt start along here: http://doc.trolltech.com/4.1/qeventloop.html#processEvents > > cheers > jorgen > > -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From support at xt-hq.com Sat Jan 7 08:43:24 2006 From: support at xt-hq.com (jorgen) Date: Sat Jan 7 08:43:28 2006 Subject: [linux-audio-dev] VST compiled for linux / gui message loop In-Reply-To: <20060107122340.GB4336@mobilat> References: <43BF9EE9.4020706@xt-hq.com> <20060107122340.GB4336@mobilat> Message-ID: <43BFC57C.7010708@xt-hq.com> torbenh@gmx.de wrote: >On Sat, Jan 07, 2006 at 11:58:49AM +0100, jorgen wrote: > > >>Hi, Im coding a VST host for windows and linux. The linux version will >>support VSTs compiled on linux and not using wine or aything. Of course, >>there is not alot of native linux VST plugins around but that will >>change (I already made one :P ) >> >> > >:) cool welcome abord. so you ported vstGUI ? >how will that work ? >does a vst plugin coder only recompile his plug then ? > > > No, I have made my own toolkit based on xlib calls. The host (energyXT2) will pass a xlib Window handle that I use as a parent when calling XCreateWindow: case effEditOpen: if (!editor) editor = new CEditor(app, 0, wsChild | wsNoBorder, "", 100, 100, 200, 200); #ifdef WIN32 SetWindowLong (editor->handle, GWL_STYLE, (GetWindowLong (editor->handle, GWL_STYLE) &~ WS_POPUP) | WS_CHILD); SetParent(editor->handle, HWND(ptr)); #endif #ifdef linux XReparentWindow(dp, editor->handle, (Window)ptr, 0, 0); editor->parentWnd = (Window)ptr; #endif editor->show(); result = 1; break; In effEditIdle I then call my message loop: case effEditIdle: #ifdef linux XEvent event; while (XPending(dp)) { XNextEvent(dp, &event); handleEvent(event); // replace this with your own event handler for your toolkit } #endif break; >>There is one challange though, event dispatching in X11. Unlike windows, >>X11 windows doesnt have an assotiated window proc for dispatching >>events. I can overcome this in my own gui toolkit by passing a Display* >>pointer to the plugin etc, but it wouldnt work with other gui toolkits. >> >>So how do I make a soution that work with any toolkits on linux? >> >> > >we are still searching for a solution with a window generated in the >same process. with different toolkits etc. > >to my knowledge >this has not really been solved. believe me, there would be a much nicer >standard than dssi already. > > > >>1) the plugin calls its own event loop in effEditIdle >>2) make a new atom "wndproc" for storing wndproc function per window, >>the host will send XEvents to the wndproc if found. >> >>I prefer 1) but I dont know if toolkits supports manually calling the >>event loop? >> >> > >i am not sure i understand what you want to do but..... > >for gtk see: > >http://www.gtk.org/api/2.6/gtk/gtk-General.html#gtk-main-iteration-do > >for qt start along here: > >http://doc.trolltech.com/4.1/qeventloop.html#processEvents > > > > >>cheers >>jorgen >> >> >> >> > > > From torbenh at gmx.de Sat Jan 7 10:45:21 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Sat Jan 7 10:52:55 2006 Subject: [linux-audio-dev] VST compiled for linux / gui message loop In-Reply-To: <43BFC57C.7010708@xt-hq.com> References: <43BF9EE9.4020706@xt-hq.com> <20060107122340.GB4336@mobilat> <43BFC57C.7010708@xt-hq.com> Message-ID: <20060107154521.GA7770@mobilat> On Sat, Jan 07, 2006 at 02:43:24PM +0100, jorgen wrote: > torbenh@gmx.de wrote: > > >On Sat, Jan 07, 2006 at 11:58:49AM +0100, jorgen wrote: > > > > > >>Hi, Im coding a VST host for windows and linux. The linux version will > >>support VSTs compiled on linux and not using wine or aything. Of course, > >>there is not alot of native linux VST plugins around but that will > >>change (I already made one :P ) > >> > >> > > > >:) cool welcome abord. so you ported vstGUI ? > >how will that work ? > >does a vst plugin coder only recompile his plug then ? > > > > > > > No, I have made my own toolkit based on xlib calls. The host (energyXT2) > will pass a xlib Window handle that I use as a parent when calling > XCreateWindow: > > case effEditOpen: > if (!editor) > editor = new CEditor(app, 0, wsChild | wsNoBorder, "", > 100, 100, 200, 200); > #ifdef WIN32 > SetWindowLong (editor->handle, GWL_STYLE, > (GetWindowLong (editor->handle, GWL_STYLE) &~ WS_POPUP) > | WS_CHILD); > SetParent(editor->handle, HWND(ptr)); > #endif > #ifdef linux > XReparentWindow(dp, editor->handle, (Window)ptr, 0, 0); > editor->parentWnd = (Window)ptr; > #endif > editor->show(); > result = 1; > break; > why dont you open a separate display connection for the plugin ? then you can even move the gui updates to a different thread and there you go... look into gtkplug.c and gtksocket.c on how this works. -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From fons.adriaensen at skynet.be Sat Jan 7 11:55:28 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sat Jan 7 12:11:46 2006 Subject: [linux-audio-dev] VST compiled for linux / gui message loop In-Reply-To: <20060107154521.GA7770@mobilat> References: <43BF9EE9.4020706@xt-hq.com> <20060107122340.GB4336@mobilat> <43BFC57C.7010708@xt-hq.com> <20060107154521.GA7770@mobilat> Message-ID: <20060107165528.GA5054@linux-1> On Sat, Jan 07, 2006 at 04:45:21PM +0100, torbenh@gmx.de wrote: > why dont you open a separate display connection for the plugin ? > then you can even move the gui updates to a different thread and there > you go... > > look into gtkplug.c and gtksocket.c on how this works. Does X allow multiple clients within the same process space ? Last time I tried this it failed miserably, but that could of course just be the result of my own ignorance... -- FA From support at xt-hq.com Sat Jan 7 11:32:36 2006 From: support at xt-hq.com (jorgen) Date: Sat Jan 7 12:24:25 2006 Subject: [linux-audio-dev] VST compiled for linux / gui message loop In-Reply-To: <20060107154521.GA7770@mobilat> References: <43BF9EE9.4020706@xt-hq.com> <20060107122340.GB4336@mobilat> <43BFC57C.7010708@xt-hq.com> <20060107154521.GA7770@mobilat> Message-ID: <43BFED24.2090005@xt-hq.com> torbenh@gmx.de wrote: >On Sat, Jan 07, 2006 at 02:43:24PM +0100, jorgen wrote: > > >>torbenh@gmx.de wrote: >> >> >> >>>On Sat, Jan 07, 2006 at 11:58:49AM +0100, jorgen wrote: >>> >>> >>> >>> >>>>Hi, Im coding a VST host for windows and linux. The linux version will >>>>support VSTs compiled on linux and not using wine or aything. Of course, >>>>there is not alot of native linux VST plugins around but that will >>>>change (I already made one :P ) >>>> >>>> >>>> >>>> >>>:) cool welcome abord. so you ported vstGUI ? >>>how will that work ? >>>does a vst plugin coder only recompile his plug then ? >>> >>> >>> >>> >>> >>No, I have made my own toolkit based on xlib calls. The host (energyXT2) >>will pass a xlib Window handle that I use as a parent when calling >>XCreateWindow: >> >> case effEditOpen: >> if (!editor) >> editor = new CEditor(app, 0, wsChild | wsNoBorder, "", >>100, 100, 200, 200); >>#ifdef WIN32 >> SetWindowLong (editor->handle, GWL_STYLE, >> (GetWindowLong (editor->handle, GWL_STYLE) &~ WS_POPUP) >>| WS_CHILD); >> SetParent(editor->handle, HWND(ptr)); >>#endif >>#ifdef linux >> XReparentWindow(dp, editor->handle, (Window)ptr, 0, 0); >> editor->parentWnd = (Window)ptr; >>#endif >> editor->show(); >> result = 1; >> break; >> >> >> > >why dont you open a separate display connection for the plugin ? >then you can even move the gui updates to a different thread and there >you go... > >look into gtkplug.c and gtksocket.c on how this works. > > > > I do open a separet connection for display in my toolkit and gui updates are already working by the dispatcher code in effEditIdle. If gtk can create a thread for gui updates than it sounds like it will work, but a gui update thread for each plugin? Whats the performance loss, I mean a typical song projects has 10-30 plugins. From support at xt-hq.com Sat Jan 7 12:45:46 2006 From: support at xt-hq.com (jorgen) Date: Sat Jan 7 12:45:49 2006 Subject: [linux-audio-dev] VST compiled for linux / gui message loop In-Reply-To: <20060107165528.GA5054@linux-1> References: <43BF9EE9.4020706@xt-hq.com> <20060107122340.GB4336@mobilat> <43BFC57C.7010708@xt-hq.com> <20060107154521.GA7770@mobilat> <20060107165528.GA5054@linux-1> Message-ID: <43BFFE4A.7090505@xt-hq.com> fons adriaensen wrote: >On Sat, Jan 07, 2006 at 04:45:21PM +0100, torbenh@gmx.de wrote: > > > >>why dont you open a separate display connection for the plugin ? >>then you can even move the gui updates to a different thread and there >>you go... >> >>look into gtkplug.c and gtksocket.c on how this works. >> >> > >Does X allow multiple clients within the same process space ? > >Last time I tried this it failed miserably, but that could >of course just be the result of my own ignorance... > > > It didnt crash for me, but it may depend on the toolkit. I guess the host could pass a Display pointer as an option. From thockin at hockin.org Sat Jan 7 13:05:18 2006 From: thockin at hockin.org (thockin@hockin.org) Date: Sat Jan 7 12:59:47 2006 Subject: [linux-audio-dev] VST compiled for linux / gui message loop In-Reply-To: <43BF9EE9.4020706@xt-hq.com> References: <43BF9EE9.4020706@xt-hq.com> Message-ID: <20060107180518.GA31300@hockin.org> On Sat, Jan 07, 2006 at 11:58:49AM +0100, jorgen wrote: > Hi, Im coding a VST host for windows and linux. The linux version will > support VSTs compiled on linux and not using wine or aything. Of course, > there is not alot of native linux VST plugins around but that will > change (I already made one :P ) Jorgen, I don't have an answer to this, but good to see you here and I am looking forward to eXT on Linux. THANK YOU! Tim From david at olofson.net Sat Jan 7 17:01:15 2006 From: david at olofson.net (David Olofson) Date: Sat Jan 7 17:02:47 2006 Subject: [linux-audio-dev] ANN: DT-42 DrumToy 0.1.0 Message-ID: <200601072301.15752.david@olofson.net> DT-42 DrumToy 0.1.0 - First Release ----------------------------------- "DT-42 DrumToy was intended as an example of interactive audio and graphics programming using SDL, but the project went rouge and turned into a "usable" drum machine. Not exactly a minimal technique example, but for someone working on some sort of music editor, the source might be of some interest, as DT-42 is probably as simple as it gets with all the basic vital stuff still in place. The package contains the source code, graphics, sounds, some example songs and precompiled executables for Windows, Mac OS X/PPC, Linux/x86 and Linux/AMD64." Have fun! Home: http://olofson.net/mixed.html Direct download: http://olofson.net/download/DT-42-0.1.0.tar.gz //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --' From rlrevell at joe-job.com Mon Jan 9 23:11:32 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Jan 9 23:11:38 2006 Subject: [linux-audio-dev] top 10 Message-ID: <1136866292.2007.47.camel@mindpipe> The Independent picked their top 10 free software projects: http://news.independent.co.uk/media/article337369.ece and dyne:bolic made the list. I think all Linux audio developers deserve some credit for this. Lee From bwanab+lad at juraview.com Tue Jan 10 06:10:22 2006 From: bwanab+lad at juraview.com (Bill Allen) Date: Tue Jan 10 06:10:28 2006 Subject: [linux-audio-dev] Interaction bug between zynaddsubfx and muse. In-Reply-To: <20060105125534.GA7241@bth05w.ABSp.alcatel.be> References: <43B7FFB9.6090406@juraview.com> <200601011842.04405.rj@spamatica.se> <20060101182023.GA4831@linux-1> <43BD00A9.7090901@juraview.com> <20060105125534.GA7241@bth05w.ABSp.alcatel.be> Message-ID: <43C3961E.1060007@juraview.com> Alfons Adriaensen wrote: >On Thu, Jan 05, 2006 at 06:19:05AM -0500, Bill Allen wrote: > > > >>fons adriaensen wrote: >> >> >> >>>AMS should handle multiple patches without requiring a separate instance >>>for each. >>> >>> >>That would be great, as ams is my favorite synth, but I haven't found a >>way to do it. When you say "should" are you saying that I should be able >>to find a way, or that somebody should be able to add the capability to it? >> >> > >I think it is possible to have two ore more independent patches in monophonic >mode, but not if poly > 1. It's some time since I worked on AMS so I could be >wrong. > >There are (again) several issues involved. > >- AMS has no means to load a second patch while preserving the current one. > So you can't combine two existing patches without having to manually recreate > at least one of them. > >- IIRC there are some global variables involved in the hidden communication > from ENV generators back to the voice assignment logic in the MIDI > controllers. Having two or more really independent patches would require > these to be eliminated, and replaced by an explicit path. > >- The 'poly' setting is also global, but it should be independent in each > patch. > > >I made some plans more than a year ago to fix all of this, but it would be >a major and very invasive operation. Another factor blocking this was that >these changes would probably render some existing patches incompatible, and >Matthias didn't like that very much. > >I still hope to return to AMS some day, and when I do it will be a major >reworking of almost everything. So if AMS is your favorite synth I'd like >to know > > - which features are absolutely essential and should not change, > - which ones are important but maybe could be done slightly > differently, > - what can be sacrified in order to make other things possible ? > >-- >FA > > > > Not getting into your three questions yet - couldn't the problem at hand (multiple patches) be solved by adding a midi channel selector to the MCV module? In other words, if I create a patch with two MCV modules, they both take my midi notes from the same channel. If you could assign a channel to each MCV, then the network that you set up from one would be controlled separately from the other. Thus you essentially have a single multiple voice patch instead of having separate patches each with its own voice. That would be fine with me. Regards, Bill From torbenh at gmx.de Tue Jan 10 06:27:25 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Tue Jan 10 06:34:54 2006 Subject: [linux-audio-dev] [ANN] ninjam with jack support... Message-ID: <20060110112725.GA4974@mobilat.informatik.uni-bremen.de> hello... i just wanted to announce, that i have written a jack binding for ninjam. ninjam is a network jam session software. www.ninjam.com the ported consoleclient for ninjam is available here: http://galan.sf.net/ninjam-with-jack.tar.bz2 and yes... there is a Makefile.. find -name Makefile it... i just added the jack support... more io ports will follow... also dont use with too low period sizes, it does not behave so well.. -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From strombrg at dcs.nac.uci.edu Tue Jan 10 12:50:21 2006 From: strombrg at dcs.nac.uci.edu (Dan Stromberg) Date: Tue Jan 10 12:50:46 2006 Subject: [linux-audio-dev] Splitting audio files? Message-ID: <1136915421.19259.60.camel@seki.nac.uci.edu> What are people's favorite applications for splitting up large sound files? I have a bunch a bunch of IMA ADPCM .wav's that I want to burn to CD, but often they're too large for a single CD. BTW, I've been converting the files to .cdr on a linux system, and then transferring that result to a windows machine for burning via a windows version of cdrecord. I'm interested in both CLI and GUI ways of doing this. Thanks! From fbar at footils.org Tue Jan 10 17:28:07 2006 From: fbar at footils.org (Frank Barknecht) Date: Tue Jan 10 17:28:02 2006 Subject: [linux-audio-dev] Problem compiling with liblo: error: 'lo_address' does not name a type Message-ID: <20060110222807.GD9333@fliwatut.scifi> Hallo, while trying to build Dave Griffith's fluxus, which uses liblo, on Debian, I've hit a very strange error. It boils down to g++ not finding the symbols exported in lo/lo.h. I stripped down the code, where it fails to this supershort C++-file: // -------------- // OSCServer.cpp // #include lo_address m_Destination; // ---------- end Trying to compile this with $ g++ -c OSCServer.cpp will give these errors: $ g++-3.2 -c OSCServer.cpp OSCServer.cpp:2: 'lo_address' is used as a type, but is not defined as a type. $ g++-3.3 -c OSCServer.cpp OSCServer.cpp:2: error: 'lo_address' is used as a type, but is not defined as a type. $ g++-4.0 -c OSCServer.cpp OSCServer.cpp:2: error: 'lo_address' does not name a type liblo is installed from the Debian package: ii liblo0-dev 0.22-1 Lightweight OSC library --development files I think, g++ finds , otherwise it should complain about a missing header, but then it doesn't want to use it. Does anyone have an idea, what is going wrong here? Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From chris.cannam at ferventsoftware.com Tue Jan 10 17:59:07 2006 From: chris.cannam at ferventsoftware.com (Chris Cannam) Date: Tue Jan 10 18:01:31 2006 Subject: [linux-audio-dev] Problem compiling with liblo: error: 'lo_address'does not name a type Message-ID: <1184795993-1136934085-cardhu_blackberry.rim.net-10864-@engine03.bwc.produk.on.blackberry> Frank Barknecht: > OSCServer.cpp:2: 'lo_address' is used as a type, > but is not defined as a type. Wasn't lo_address called something else in very old versions of liblo? Maybe you have spare headers lying around. Or maybe I'm inventing things. Chris From fbar at footils.org Tue Jan 10 18:22:32 2006 From: fbar at footils.org (Frank Barknecht) Date: Tue Jan 10 18:22:26 2006 Subject: [linux-audio-dev] Problem compiling with liblo: error: 'lo_address'does not name a type In-Reply-To: <1184795993-1136934085-cardhu_blackberry.rim.net-10864-@engine03.bwc.produk.on.blackberry> References: <1184795993-1136934085-cardhu_blackberry.rim.net-10864-@engine03.bwc.produk.on.blackberry> Message-ID: <20060110232232.GE9333@fliwatut.scifi> Hallo, Chris Cannam hat gesagt: // Chris Cannam wrote: > Frank Barknecht: > > OSCServer.cpp:2: 'lo_address' is used as a type, > > but is not defined as a type. > > Wasn't lo_address called something else in very old > versions of liblo? Maybe you have spare headers > lying around. Or maybe I'm inventing things. Oh, yes, that was it!! I had an older version install in /usr/local. Removing it lets me compile, thanks a lot! Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From jwoithe at physics.adelaide.edu.au Wed Jan 11 00:16:31 2006 From: jwoithe at physics.adelaide.edu.au (Jonathan Woithe) Date: Wed Jan 11 00:13:13 2006 Subject: [linux-audio-dev] ANNOUNCE: set_rlimits 1.2.0 Message-ID: <200601110516.k0B5GVjU029585@auster.physics.adelaide.edu.au> Hi everyone This is a short note to point out that I have released set_rlimits 1.2.0. It can be found at http://www.physics.adelaide.edu.au/~jwoithe/set_rlimits-1.2.0.tgz This is the software formerly known as set_rtlimits. I've changed the name to reflect the fact that any rlimit can be controlled by this program if the need arises. Changes/additions in this version: * improved configuration file syntax (with support for the old syntax if it is found) * ability to set the memlock resource limit * easier command line use (an absolute path is no longer required for example - it is taken from the configuration file) As always, bug reports, suggestions and patches are welcome. Regards jonathan From mle+la at mega-nerd.com Wed Jan 11 02:20:43 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Wed Jan 11 02:20:51 2006 Subject: [linux-audio-dev] Problem compiling with liblo: error: 'lo_address' does not name a type In-Reply-To: <20060110222807.GD9333@fliwatut.scifi> References: <20060110222807.GD9333@fliwatut.scifi> Message-ID: <20060111182043.1da26602.mle+la@mega-nerd.com> Frank Barknecht wrote: > Hallo, > > while trying to build Dave Griffith's fluxus, which uses liblo, on > Debian, I've hit a very strange error. It boils down to g++ not > finding the symbols exported in lo/lo.h. I stripped down the code, > where it fails to this supershort C++-file: Check your version of liblo. The version in Debian (even testing) and Ubuntu is a bit behibd what Dave has on his web site. Cheers, Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "They should make peace with those who make peace, and wage war against those who wage war, and wage jihad against those who stand in the way of spreading the message of Islam and causing it to prevail of earth." http://islamqa.com/index.php?ln=eng&ds=qa&lv=browse&QR=26721&dgn=4 From fbar at footils.org Wed Jan 11 04:35:02 2006 From: fbar at footils.org (Frank Barknecht) Date: Wed Jan 11 04:34:57 2006 Subject: [linux-audio-dev] Problem compiling with liblo: error: 'lo_address' does not name a type In-Reply-To: <20060111182043.1da26602.mle+la@mega-nerd.com> References: <20060110222807.GD9333@fliwatut.scifi> <20060111182043.1da26602.mle+la@mega-nerd.com> Message-ID: <20060111093502.GA10147@fliwatut.scifi> Hallo, Erik de Castro Lopo hat gesagt: // Erik de Castro Lopo wrote: > Frank Barknecht wrote: > > while trying to build Dave Griffith's fluxus, which uses liblo, on > > Debian, I've hit a very strange error. It boils down to g++ not > > finding the symbols exported in lo/lo.h. I stripped down the code, > > where it fails to this supershort C++-file: > > Check your version of liblo. The version in Debian (even testing) > and Ubuntu is a bit behibd what Dave has on his web site. You mean Steve, right? Actually the version in testing is 0.22, which also is the latest on plugin.org.uk/liblo/releases/ Ubuntu seriously lags behind (0.18), as unfortunatly seems to be the norm with many packages I would be interested in. (Btw: Does anyone know the smoothest way to upgrade Ubuntu Breezy to Debian testing? I'd like to get rid of U. on my laptop soon and run a Real Programmer's Debian there as on my other machines.) My problem with liblo was, that the version I had in /usr/local was way old and shouldn't have been there at all. It works now, after I deleted it. Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From mle+la at mega-nerd.com Wed Jan 11 05:30:15 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Wed Jan 11 05:30:22 2006 Subject: [linux-audio-dev] Problem compiling with liblo: error: 'lo_address' does not name a type In-Reply-To: <20060111093502.GA10147@fliwatut.scifi> References: <20060110222807.GD9333@fliwatut.scifi> <20060111182043.1da26602.mle+la@mega-nerd.com> <20060111093502.GA10147@fliwatut.scifi> Message-ID: <20060111213015.06afe9e2.mle+la@mega-nerd.com> Frank Barknecht wrote: > You mean Steve, right? Yeah I do. Sorry Steve :-). > Ubuntu seriously lags behind (0.18), as unfortunatly seems to be the > norm with many packages I would be interested in. > > (Btw: Does anyone know the smoothest way to upgrade Ubuntu Breezy to > Debian testing? I'd like to get rid of U. on my laptop soon and run a > Real Programmer's Debian there as on my other machines.) I'm running Breezy too, and I just compiled the liblo package from Dapper and installed that. What you do is: - Go to your local Ubuntu mirror site. - Find /ubuntu/pool/universe/libl/liblo/ - Grab the three files: liblo_0.22-1.dsc liblo_0.22-1.diff.gz liblo_0.22.orig.tar.gz - Then do: dpkg-source -x liblo_0.22-1.dsc cd liblo-0.22/ dpkg-buildpackage -rfakeroot -b -uc cd .. sudo dpkg -i liblo*.deb And you're done. Probably a bit easier than converting your machine to Debian testing :-). Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Do I do everything in C++ and teach a course in advanced swearing?" -- David Beazley at IPC8, on choosing a language for teaching From S.W.Harris at ecs.soton.ac.uk Wed Jan 11 05:40:28 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Jan 11 05:40:38 2006 Subject: [linux-audio-dev] Problem compiling with liblo: error: 'lo_address' does not name a type In-Reply-To: <20060111093502.GA10147@fliwatut.scifi> References: <20060110222807.GD9333@fliwatut.scifi> <20060111182043.1da26602.mle+la@mega-nerd.com> <20060111093502.GA10147@fliwatut.scifi> Message-ID: <20060111104028.GC26293@login.ecs.soton.ac.uk> On Wed, Jan 11, 2006 at 10:35:02AM +0100, Frank Barknecht wrote: > My problem with liblo was, that the version I had in /usr/local was > way old and shouldn't have been there at all. It works now, after I > deleted it. Yeah, lo_address used to be called something else, but it was in the dim and distant, pre-stable past. - Steve From jayv at synth.net Wed Jan 11 05:47:53 2006 From: jayv at synth.net (Jay Vaughan) Date: Wed Jan 11 05:48:03 2006 Subject: [linux-audio-dev] things to port to the gp2x .. Message-ID: hi all, well i've recently waded into the GP2X territory, fairly deeply, and i'm enjoying it immensely: http://gbax.com/ its a dual-processor (ARM) portable games machine, battery powered, US$180, and .. it runs linux, has a very interesting EXT connector which supports USB and MIDI, video and audio, and extremely active games coding is going on, with well over 10,000 games currently runnable on it (emulation, baby): http://wiki.gp2x.org/wiki/EXT it can support usb-gadget audio (already has usb-gadget serial) so it wouldn't be terribly hard to 'integrate' it, either, with USB-based audio outputs .. and there is SDL onboard too, for graphics, with cairo/libsvg of course .. so its not such a stretch to consider this to be -the- synthesis platform of choice for linux audio hacking, and so i was wondering .. what linux-based softsynths do you think would be worthy to port to such a beast? i've already got sampling, a sequencer (thanks to MidiShare), and some basic audio idea's down, but what do you guys think about having a bit of a port-fest and turning the GP2X into a veritable treasure trove of a softsynth platform? -- ; Jay Vaughan From S.W.Harris at ecs.soton.ac.uk Wed Jan 11 05:59:47 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Jan 11 05:59:57 2006 Subject: [linux-audio-dev] things to port to the gp2x .. In-Reply-To: References: Message-ID: <20060111105947.GD26293@login.ecs.soton.ac.uk> On Wed, Jan 11, 2006 at 11:47:53AM +0100, Jay Vaughan wrote: > http://gbax.com/ > > its a dual-processor (ARM) portable games machine, battery powered, > US$180, and .. it runs linux, has a very interesting EXT connector > which supports USB and MIDI, video and audio, and extremely active > games coding is going on, with well over 10,000 games currently > runnable on it (emulation, baby): How's its float performance? Older ARMs have very bad/non-existant floating point support. If its not up to scract it's not the end of the world, it just narrows the choices a bit. Does it have enough umph to run JACK? That would make it an interesting platform for audio hacking. - Steve From jayv at synth.net Wed Jan 11 06:12:30 2006 From: jayv at synth.net (Jay Vaughan) Date: Wed Jan 11 06:12:39 2006 Subject: [linux-audio-dev] things to port to the gp2x .. In-Reply-To: <20060111105947.GD26293@login.ecs.soton.ac.uk> References: <20060111105947.GD26293@login.ecs.soton.ac.uk> Message-ID: >How's its float performance? Older ARMs have very bad/non-existant floating >point support. > i would wager that floating-point is not its fort?, but rather than give you an opinion, what would be got a good float-performance benchmark that i can run on it to give you some real figures? is there a preferred stdout-style C app i can run that'll give us some real figures? also keep in mind its dual-processor; the second processor is 100% free to run code as fast as it can, while processor-1 is doing the linux thing .. so while floating-point performance may be abysmal, fixed-point math on the second CPU may just be fine .. more details about the specs here: http://wiki.gp2x.org/wiki/Docs_and_Papers >If its not up to scract it's not the end of the world, it just narrows the >choices a bit. i wouldn't put this in the class of 'high-performance hardware', but more 'hardware worth squeezing every last bit of performance out of it'. >Does it have enough umph to run JACK? That would make it an interesting >platform for audio hacking. i don't think JACK would be wise on this thing, though i could be wrong .. its really designed to be a 'single-app running at a time' platform, and so far supports SDL/SDL_mixer, though you can do raw hardware i/o to the codec of course, and .. well .. there is the matter of USB-Audio Gadget drivers, which would provide a path to higher-power DAW upstream .. -- ; Jay Vaughan From bengan at sunet.se Wed Jan 11 06:22:37 2006 From: bengan at sunet.se (Bengt =?iso-8859-1?B?R/ZyZOlu?=) Date: Wed Jan 11 06:21:41 2006 Subject: [linux-audio-dev] things to port to the gp2x .. In-Reply-To: <20060111105947.GD26293@login.ecs.soton.ac.uk> References: <20060111105947.GD26293@login.ecs.soton.ac.uk> Message-ID: <20060111112237.GA9827@sunet.se> On Wed, Jan 11, 2006 at 10:59:47AM +0000, Steve Harris wrote: > On Wed, Jan 11, 2006 at 11:47:53AM +0100, Jay Vaughan wrote: > > http://gbax.com/ > > > > its a dual-processor (ARM) portable games machine, battery powered, > > US$180, and .. it runs linux, has a very interesting EXT connector > > which supports USB and MIDI, video and audio, and extremely active > > games coding is going on, with well over 10,000 games currently > > runnable on it (emulation, baby): > > How's its float performance? Older ARMs have very bad/non-existant floating > point support. Non existant in ARM 9. regards, - Bengan ------------------------------------------------------------- - KTHNOC/SUNET/NORDUnet | http://www.noc.kth.se/~bengan | 08-7906586 - From tito at rumford.de Wed Jan 11 06:19:06 2006 From: tito at rumford.de (Wolfgang Woehl) Date: Wed Jan 11 06:31:00 2006 Subject: [linux-audio-dev] ANN: DT-42 DrumToy 0.1.0 In-Reply-To: <200601072301.15752.david@olofson.net> References: <200601072301.15752.david@olofson.net> Message-ID: <200601111219.06649.tito@rumford.de> David Olofson : > DT-42 DrumToy 0.1.0 - First Release Jackify this and you will be worshipped. A fun tracker machine, thank you. Oh, it could be a bit more verbose when it fails to access an audio device which is the case when jack is in control, had to kill -9 it. Wolfgang From S.W.Harris at ecs.soton.ac.uk Wed Jan 11 07:04:03 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Jan 11 07:04:14 2006 Subject: [linux-audio-dev] ANN: DT-42 DrumToy 0.1.0 In-Reply-To: <200601111219.06649.tito@rumford.de> References: <200601072301.15752.david@olofson.net> <200601111219.06649.tito@rumford.de> Message-ID: <20060111120402.GE26293@login.ecs.soton.ac.uk> On Wed, Jan 11, 2006 at 12:19:06PM +0100, Wolfgang Woehl wrote: > David Olofson : > > DT-42 DrumToy 0.1.0 - First Release > > Jackify this and you will be worshipped. Or DSSI-ify it? It would be more versatile that way. - Steve From srinivas_reddy at faith.co.jp Wed Jan 11 07:09:46 2006 From: srinivas_reddy at faith.co.jp (Srinivas Reddy) Date: Wed Jan 11 07:09:58 2006 Subject: [linux-audio-dev] Plz help ...Can ALSA support the "real-time mode" ? References: <43BBEFA9.5030007@t-data.com> <1136491650.847.2.camel@mindpipe> <43BDD78D.1000900@t-data.com> Message-ID: <003201c616a7$e9caf660$5b11a80a@reddyIBME970A0D0B67> hi all , I am new to Linux Audio world.Can any one help me in the following questions. I am having an audio engine with MIDI PLAYER and MIDI SYNTHESIZER which is running in real time mode . It means that the player layer send the MIDI events directly to the synthesizer that are contained in the current frame. There is no time information in the events and there is no bufferization. Q1)Does ALSA can support the "real-time mode" ? OR Does it support a sequenced mode ? i.e.,does the player/parser have to send time information to the ALSA library? Can any one help me out. thank you From S.W.Harris at ecs.soton.ac.uk Wed Jan 11 07:14:07 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Jan 11 07:14:21 2006 Subject: [linux-audio-dev] things to port to the gp2x .. In-Reply-To: References: <20060111105947.GD26293@login.ecs.soton.ac.uk> Message-ID: <20060111121407.GF26293@login.ecs.soton.ac.uk> On Wed, Jan 11, 2006 at 12:12:30PM +0100, Jay Vaughan wrote: > >How's its float performance? Older ARMs have very bad/non-existant floating > >point support. > > > > i would wager that floating-point is not its fort?, but rather than > give you an opinion, what would be got a good float-performance > benchmark that i can run on it to give you some real figures? is > there a preferred stdout-style C app i can run that'll give us some > real figures? Just write some code that does a bunch of float mutiplies on an array and time them. The maximum peak performance of a modern CPU is 1 or 2 cycles per multiply, but in practice memory bandwidth throttles that. 10 might be more typical at a rough guess. Writing DSP code for integer platforms is extremly tedious, and I dont think you will want to port any float code to an integer only platform. Best to look for code that allready works in ints. - Steve From paul at linuxaudiosystems.com Wed Jan 11 07:36:44 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Jan 11 07:33:48 2006 Subject: [linux-audio-dev] things to port to the gp2x .. In-Reply-To: <20060111121407.GF26293@login.ecs.soton.ac.uk> References: <20060111105947.GD26293@login.ecs.soton.ac.uk> <20060111121407.GF26293@login.ecs.soton.ac.uk> Message-ID: <1136983005.11947.3.camel@localhost.localdomain> > Writing DSP code for integer platforms is extremly tedious, and I dont > think you will want to port any float code to an integer only platform. > Best to look for code that allready works in ints. which thanks to JACK is now extremely hard to find :) From fons.adriaensen at alcatelaleniaspace.com Wed Jan 11 07:38:45 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Wed Jan 11 07:38:57 2006 Subject: [linux-audio-dev] things to port to the gp2x .. In-Reply-To: <20060111121407.GF26293@login.ecs.soton.ac.uk> References: <20060111105947.GD26293@login.ecs.soton.ac.uk> <20060111121407.GF26293@login.ecs.soton.ac.uk> Message-ID: <20060111123845.GA9307@bth05w.ABSp.alcatel.be> On Wed, Jan 11, 2006 at 12:14:07PM +0000, Steve Harris wrote: > The maximum peak performance of a modern CPU is 1 or 2 cycles per > multiply, but in practice memory bandwidth throttles that. 10 might be > more typical at a rough guess. For most intensive DSP applications, PCs are limited by memory bandwidth. > Writing DSP code for integer platforms is extremly tedious, Having done a lot of it (fixed point, on ARM), I'd disagree. But It is certainly different. If you want good fixed point performance, you have to write some of the inner loops in assembly. Not that this is a problem - ARM assembly is a pure pleasure compared to Intel. And there a lots of little computation that can be expressed more easily in assembler than in C/C++. > and I dont > think you will want to port any float code to an integer only platform. That's absolutely correct. You have to design your algorithms from the start for integer / fixed point. -- FA From fons.adriaensen at alcatelaleniaspace.com Wed Jan 11 07:42:10 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Wed Jan 11 07:42:15 2006 Subject: [linux-audio-dev] Plz help ...Can ALSA support the "real-time mode" ? In-Reply-To: <003201c616a7$e9caf660$5b11a80a@reddyIBME970A0D0B67> References: <43BBEFA9.5030007@t-data.com> <1136491650.847.2.camel@mindpipe> <43BDD78D.1000900@t-data.com> <003201c616a7$e9caf660$5b11a80a@reddyIBME970A0D0B67> Message-ID: <20060111124210.GB9307@bth05w.ABSp.alcatel.be> On Wed, Jan 11, 2006 at 09:09:46PM +0900, Srinivas Reddy wrote: > I am having an audio engine with MIDI PLAYER and MIDI SYNTHESIZER which is > running in real time mode . It means that > the player layer send the MIDI events directly to the synthesizer that are > contained in the current frame. There is no time information in the events > and there is no bufferization. > > Q1)Does ALSA can support the "real-time mode" ? > > OR > Does it support a sequenced mode ? i.e.,does the player/parser have to send > time > information to the ALSA library? It supports both modes. You can send midi to another app for immediate delivery, or you can schedule it for later. -- FA From jayv at synth.net Wed Jan 11 08:30:41 2006 From: jayv at synth.net (Jay Vaughan) Date: Wed Jan 11 08:31:07 2006 Subject: [linux-audio-dev] things to port to the gp2x .. In-Reply-To: <20060111123845.GA9307@bth05w.ABSp.alcatel.be> References: <20060111105947.GD26293@login.ecs.soton.ac.uk> <20060111121407.GF26293@login.ecs.soton.ac.uk> <20060111123845.GA9307@bth05w.ABSp.alcatel.be> Message-ID: > > think you will want to port any float code to an integer only platform. > >That's absolutely correct. You have to design your algorithms from the >start for integer / fixed point. > as ARM detail quite well here: http://www.arm.com/pdfs/DAI0033A_fixedpoint.pdf -- ; Jay Vaughan From S.W.Harris at ecs.soton.ac.uk Wed Jan 11 08:53:25 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Jan 11 08:53:40 2006 Subject: [linux-audio-dev] things to port to the gp2x .. In-Reply-To: <20060111123845.GA9307@bth05w.ABSp.alcatel.be> References: <20060111105947.GD26293@login.ecs.soton.ac.uk> <20060111121407.GF26293@login.ecs.soton.ac.uk> <20060111123845.GA9307@bth05w.ABSp.alcatel.be> Message-ID: <20060111135325.GI26293@login.ecs.soton.ac.uk> On Wed, Jan 11, 2006 at 01:38:45PM +0100, Alfons Adriaensen wrote: > > Writing DSP code for integer platforms is extremly tedious, > > Having done a lot of it (fixed point, on ARM), I'd disagree. But It is > certainly different. If you want good fixed point performance, you have > to write some of the inner loops in assembly. Not that this is a problem > - ARM assembly is a pure pleasure compared to Intel. And there a lots of > little computation that can be expressed more easily in assembler than > in C/C++. I agree about ARM assembly, I have written some (not DSP related) many years ago and it was quite straightforward. Does this ARM chip have real fixedpoint hardware, or do you have to do bit manipulations to get the numbers? - Steve From fons.adriaensen at alcatelaleniaspace.com Wed Jan 11 09:01:28 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Wed Jan 11 09:01:35 2006 Subject: [linux-audio-dev] things to port to the gp2x .. In-Reply-To: <20060111135325.GI26293@login.ecs.soton.ac.uk> References: <20060111105947.GD26293@login.ecs.soton.ac.uk> <20060111121407.GF26293@login.ecs.soton.ac.uk> <20060111123845.GA9307@bth05w.ABSp.alcatel.be> <20060111135325.GI26293@login.ecs.soton.ac.uk> Message-ID: <20060111140128.GD9307@bth05w.ABSp.alcatel.be> On Wed, Jan 11, 2006 at 01:53:25PM +0000, Steve Harris wrote: > I agree about ARM assembly, I have written some (not DSP related) many > years ago and it was quite straightforward. Another ex Acorn user ??? > Does this ARM chip have real fixedpoint hardware, or do you have to do bit > manipulations to get the numbers? It doesn't have anything specific fixed point. It's all integer, and you, as the programmer, have to imagine a binary point somewhere in your data and keep track of it. What helps enormously on the ARM is that all arithmetic instructions can include a (no overhead) shift on one of the operands. There are some other unique things, such as the 16 conditions on *all* instructions. -- FA From S.W.Harris at ecs.soton.ac.uk Wed Jan 11 09:08:05 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Jan 11 09:08:18 2006 Subject: [linux-audio-dev] things to port to the gp2x .. In-Reply-To: <20060111140128.GD9307@bth05w.ABSp.alcatel.be> References: <20060111105947.GD26293@login.ecs.soton.ac.uk> <20060111121407.GF26293@login.ecs.soton.ac.uk> <20060111123845.GA9307@bth05w.ABSp.alcatel.be> <20060111135325.GI26293@login.ecs.soton.ac.uk> <20060111140128.GD9307@bth05w.ABSp.alcatel.be> Message-ID: <20060111140805.GK26293@login.ecs.soton.ac.uk> On Wed, Jan 11, 2006 at 03:01:28PM +0100, Alfons Adriaensen wrote: > On Wed, Jan 11, 2006 at 01:53:25PM +0000, Steve Harris wrote: > > > I agree about ARM assembly, I have written some (not DSP related) many > > years ago and it was quite straightforward. > > Another ex Acorn user ??? Damn, does it show ;) > > Does this ARM chip have real fixedpoint hardware, or do you have to do bit > > manipulations to get the numbers? > > It doesn't have anything specific fixed point. It's all integer, and you, > as the programmer, have to imagine a binary point somewhere in your data > and keep track of it. Yeah, some of my LADPSA code uses pseudo-fixedpoint to track things like phases. I found it slightly simpler than floating point, and things like modulos and finding what quadrant its in is really cheap. > What helps enormously on the ARM is that all arithmetic instructions can > include a (no overhead) shift on one of the operands. There are some > other unique things, such as the 16 conditions on *all* instructions. I see, that is helpful. I imagine that coding things like IIR filters is still quite time consuming though. I would expect that you need to switch between different point positions a lot. - Steve From fons.adriaensen at alcatelaleniaspace.com Wed Jan 11 09:20:16 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Wed Jan 11 09:20:28 2006 Subject: [linux-audio-dev] things to port to the gp2x .. In-Reply-To: <20060111140805.GK26293@login.ecs.soton.ac.uk> References: <20060111105947.GD26293@login.ecs.soton.ac.uk> <20060111121407.GF26293@login.ecs.soton.ac.uk> <20060111123845.GA9307@bth05w.ABSp.alcatel.be> <20060111135325.GI26293@login.ecs.soton.ac.uk> <20060111140128.GD9307@bth05w.ABSp.alcatel.be> <20060111140805.GK26293@login.ecs.soton.ac.uk> Message-ID: <20060111142016.GE9307@bth05w.ABSp.alcatel.be> On Wed, Jan 11, 2006 at 02:08:05PM +0000, Steve Harris wrote: > Damn, does it show ;) You're not alone :-) > > What helps enormously on the ARM is that all arithmetic instructions can > > include a (no overhead) shift on one of the operands. There are some > > other unique things, such as the 16 conditions on *all* instructions. > > I see, that is helpful. I imagine that coding things like IIR filters is > still quite time consuming though. I would expect that you need to switch > between different point positions a lot. Sometimes, yes. But it doesn't really have to complicate your code. What I've done in most cases is to base the design of the algorithm from the start on what I knew was possible / cheap / to-be-avoided / etc. in ARM assembly. That's possible only if you are in the position of being the system engineer and the coder at the same time. -- FA From rlrevell at joe-job.com Wed Jan 11 10:15:20 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Jan 11 10:15:27 2006 Subject: [linux-audio-dev] Plz help ...Can ALSA support the "real-time mode" ? In-Reply-To: <003201c616a7$e9caf660$5b11a80a@reddyIBME970A0D0B67> References: <43BBEFA9.5030007@t-data.com> <1136491650.847.2.camel@mindpipe> <43BDD78D.1000900@t-data.com> <003201c616a7$e9caf660$5b11a80a@reddyIBME970A0D0B67> Message-ID: <1136992521.27255.27.camel@mindpipe> On Wed, 2006-01-11 at 21:09 +0900, Srinivas Reddy wrote: > hi all , > > I am new to Linux Audio world.Can any one help me in the following > questions. You asked the same question on several mailing lists, sometimes repeatedly. It's considered polite to wait several days for a response before doing this. Lee From m_nels at gmx.net Wed Jan 11 10:24:45 2006 From: m_nels at gmx.net (Michael T D Nelson) Date: Wed Jan 11 10:24:53 2006 Subject: [linux-audio-dev] things to port to the gp2x .. In-Reply-To: <20060111142016.GE9307@bth05w.ABSp.alcatel.be> References: <20060111105947.GD26293@login.ecs.soton.ac.uk> <20060111121407.GF26293@login.ecs.soton.ac.uk> <20060111123845.GA9307@bth05w.ABSp.alcatel.be> <20060111135325.GI26293@login.ecs.soton.ac.uk> <20060111140128.GD9307@bth05w.ABSp.alcatel.be> <20060111140805.GK26293@login.ecs.soton.ac.uk> <20060111142016.GE9307@bth05w.ABSp.alcatel.be> Message-ID: <43C5233D.70308@gmx.net> Alfons Adriaensen wrote: > On Wed, Jan 11, 2006 at 02:08:05PM +0000, Steve Harris wrote: > >>Damn, does it show ;) > > You're not alone :-) > In the near future I may be an Acorn user yet again! I'm planning to appropriate my Dad's old A5000, find our Sibelius discs, and put the MIDI interface to good use! Maybe use it to control my Linux audio boxes... (back on topic, just!) Maybe I should just bite the bullet and buy a RISC PC on eBay... Michael Nelson From S.W.Harris at ecs.soton.ac.uk Wed Jan 11 10:34:24 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Jan 11 10:34:33 2006 Subject: [linux-audio-dev] things to port to the gp2x .. In-Reply-To: <43C5233D.70308@gmx.net> References: <20060111105947.GD26293@login.ecs.soton.ac.uk> <20060111121407.GF26293@login.ecs.soton.ac.uk> <20060111123845.GA9307@bth05w.ABSp.alcatel.be> <20060111135325.GI26293@login.ecs.soton.ac.uk> <20060111140128.GD9307@bth05w.ABSp.alcatel.be> <20060111140805.GK26293@login.ecs.soton.ac.uk> <20060111142016.GE9307@bth05w.ABSp.alcatel.be> <43C5233D.70308@gmx.net> Message-ID: <20060111153424.GR26293@login.ecs.soton.ac.uk> On Wed, Jan 11, 2006 at 03:24:45PM +0000, Michael T D Nelson wrote: > Alfons Adriaensen wrote: > >On Wed, Jan 11, 2006 at 02:08:05PM +0000, Steve Harris wrote: > > > >>Damn, does it show ;) > > > >You're not alone :-) > > > > In the near future I may be an Acorn user yet again! I'm planning to > appropriate my Dad's old A5000, find our Sibelius discs, and put the > MIDI interface to good use! Maybe use it to control my Linux audio > boxes... (back on topic, just!) Hum. I can't say I'm that nostalgic. They were great machines at the time, and ARM is certainly more pleasant that x86, but I like not /having/ to code assembler, 500GB disks, portable machines, and many other things :) - Steve From fbar at footils.org Wed Jan 11 11:18:34 2006 From: fbar at footils.org (Frank Barknecht) Date: Wed Jan 11 11:18:35 2006 Subject: [linux-audio-dev] Problem compiling with liblo: error: 'lo_address' does not name a type In-Reply-To: <20060111213015.06afe9e2.mle+la@mega-nerd.com> References: <20060110222807.GD9333@fliwatut.scifi> <20060111182043.1da26602.mle+la@mega-nerd.com> <20060111093502.GA10147@fliwatut.scifi> <20060111213015.06afe9e2.mle+la@mega-nerd.com> Message-ID: <20060111161834.GB10147@fliwatut.scifi> Hallo, Erik de Castro Lopo hat gesagt: // Erik de Castro Lopo wrote: > And you're done. Probably a bit easier than converting your machine > to Debian testing :-). But I want to convert my machine to Debian testing! Ubuntu is not for me, I'm a shell-user. ;) Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From rlrevell at joe-job.com Wed Jan 11 11:53:09 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Jan 11 11:53:15 2006 Subject: [linux-audio-dev] Problem compiling with liblo: error: 'lo_address' does not name a type In-Reply-To: <20060111161834.GB10147@fliwatut.scifi> References: <20060110222807.GD9333@fliwatut.scifi> <20060111182043.1da26602.mle+la@mega-nerd.com> <20060111093502.GA10147@fliwatut.scifi> <20060111213015.06afe9e2.mle+la@mega-nerd.com> <20060111161834.GB10147@fliwatut.scifi> Message-ID: <1136998390.27255.38.camel@mindpipe> On Wed, 2006-01-11 at 17:18 +0100, Frank Barknecht wrote: > Hallo, > Erik de Castro Lopo hat gesagt: // Erik de Castro Lopo wrote: > > And you're done. Probably a bit easier than converting your machine > > to Debian testing :-). > > But I want to convert my machine to Debian testing! Ubuntu is not for > me, I'm a shell-user. ;) You'll be happy to know that Ubuntu has not phased out the command line, and does not plan to. Lee From fbar at footils.org Wed Jan 11 12:40:24 2006 From: fbar at footils.org (Frank Barknecht) Date: Wed Jan 11 12:40:20 2006 Subject: [linux-audio-dev] Problem compiling with liblo: error: 'lo_address' does not name a type In-Reply-To: <1136998390.27255.38.camel@mindpipe> References: <20060110222807.GD9333@fliwatut.scifi> <20060111182043.1da26602.mle+la@mega-nerd.com> <20060111093502.GA10147@fliwatut.scifi> <20060111213015.06afe9e2.mle+la@mega-nerd.com> <20060111161834.GB10147@fliwatut.scifi> <1136998390.27255.38.camel@mindpipe> Message-ID: <20060111174024.GC10147@fliwatut.scifi> Hallo, Lee Revell hat gesagt: // Lee Revell wrote: > On Wed, 2006-01-11 at 17:18 +0100, Frank Barknecht wrote: > > But I want to convert my machine to Debian testing! Ubuntu is not for > > me, I'm a shell-user. ;) > > You'll be happy to know that Ubuntu has not phased out the command line, > and does not plan to. Frequently Asked Questions * Where did the Terminal go? - Not on the desktop context menu anymore. Install nautilus-open-terminal if you want it. Menu entry has moved to 'Applications ? Accessories' http://www.ubuntu.com/support/releasenotes510 Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From tim at quitte.de Wed Jan 11 13:07:49 2006 From: tim at quitte.de (Tim Goetze) Date: Wed Jan 11 13:10:38 2006 Subject: [linux-audio-dev] [ann] caps-0.3.0 Message-ID: The ever popular CAPS Audio Plugin Suite reincarnates as v0.3.0, a major augmentation release. CAPS is a LADSPA library that enjoys worldwide favour for its high-quality instrument amplifier emulation facilities. In addition it provides a sizeable assortment of no less sophisticated classic DSP units for daily use as well as some more exotic sound generators and effects. Most noteworthy addition is the new AmpV plugin which builds on the previous Amp efforts. A fundamentally revised circuit design and the emulation of power supply shortcomings make for a very mellow and differentiating tone especially at clean to moderately rough settings. The new CabinetII unit further enhances the discerning electric guitarist's digital sound setup by modelling five classical speaker cabinets; far more faithful than the previous Cabinet plugin it builds on, but with the same zero-latency advantage at still extremely low CPU taxation. Furthermore, the new Scape plugin (if played well ;) generates epic grooving soundscapes, the new ChorusII and PhaserII units provide fractally modulated variants of these classics and the new SweepVFII enhances its predecessor by allowing for modulation of filter Q. -*- This CAPS release compiles cleanly on x86-64 as well as with gcc-4.0. Many plugins have been renamed and all have been relabelled, which will unfortunately upset some host programs trying to load existing setups. Consult the README files in the distribution package for further details. http://quitte.de/dsp/caps.html http://quitte.de/dsp/caps_0.3.0.tar.gz Please forward as you see fit. Enjoy, Tim From rlrevell at joe-job.com Wed Jan 11 13:22:31 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Jan 11 13:22:38 2006 Subject: [linux-audio-dev] Problem compiling with liblo: error: 'lo_address' does not name a type In-Reply-To: <20060111174024.GC10147@fliwatut.scifi> References: <20060110222807.GD9333@fliwatut.scifi> <20060111182043.1da26602.mle+la@mega-nerd.com> <20060111093502.GA10147@fliwatut.scifi> <20060111213015.06afe9e2.mle+la@mega-nerd.com> <20060111161834.GB10147@fliwatut.scifi> <1136998390.27255.38.camel@mindpipe> <20060111174024.GC10147@fliwatut.scifi> Message-ID: <1137003752.27255.69.camel@mindpipe> On Wed, 2006-01-11 at 18:40 +0100, Frank Barknecht wrote: > Hallo, > Lee Revell hat gesagt: // Lee Revell wrote: > > > On Wed, 2006-01-11 at 17:18 +0100, Frank Barknecht wrote: > > > But I want to convert my machine to Debian testing! Ubuntu is not for > > > me, I'm a shell-user. ;) > > > > You'll be happy to know that Ubuntu has not phased out the command line, > > and does not plan to. > > > Frequently Asked Questions > > * Where did the Terminal go? > > - Not on the desktop context menu anymore. Install > nautilus-open-terminal if you want it. > Menu entry has moved to 'Applications ? Accessories' > > http://www.ubuntu.com/support/releasenotes510 Meh, they're just cleaning up rarely used context menu items, they're not trying to deprecate the command line. Lee From fbar at footils.org Wed Jan 11 14:13:02 2006 From: fbar at footils.org (Frank Barknecht) Date: Wed Jan 11 14:13:02 2006 Subject: [linux-audio-dev] Ubuntu vs. Debian [was: Problem compiling with liblo] In-Reply-To: <1137003752.27255.69.camel@mindpipe> References: <20060110222807.GD9333@fliwatut.scifi> <20060111182043.1da26602.mle+la@mega-nerd.com> <20060111093502.GA10147@fliwatut.scifi> <20060111213015.06afe9e2.mle+la@mega-nerd.com> <20060111161834.GB10147@fliwatut.scifi> <1136998390.27255.38.camel@mindpipe> <20060111174024.GC10147@fliwatut.scifi> <1137003752.27255.69.camel@mindpipe> Message-ID: <20060111191302.GD10147@fliwatut.scifi> Hallo, Lee Revell hat gesagt: // Lee Revell wrote: > > * Where did the Terminal go? > > > > - Not on the desktop context menu anymore. Install > > nautilus-open-terminal if you want it. > > Menu entry has moved to 'Applications ? Accessories' > > > > http://www.ubuntu.com/support/releasenotes510 > > Meh, they're just cleaning up rarely used context menu items, they're > not trying to deprecate the command line. Yes, I know, I was just joking, I'm not even using Gnome. I just found, that using Ubuntu for my style of work provides no advantages at all. They put a lot of work into tight Desktop integration and stuff while I just use a command line and don't need all this. The software I use a lot is older in Ubuntu than in Debian testing (Pd, blackbox, now liblo). Basically I made my Ubuntu system behave like a Debian system in most ways, which was a lot of work and isn't guaranteed to survive upgrades. When upgrading from Hoary to Breezy a lot of stuff broke and to fix it, I actually had to run Gnome-tools I didn't start in months. E.g. when I changed the default language from German to English, Gnome-terminal didn't accepted and displayed umlauts anymore. I found no way to have english messages but still be able to type ?. Then gnome-terminal doesn't accept the "-ls" option anymore and tells me to use some Properties Menu and create a "Profile" for it. I mean, I had a "profile", which was a keyboard shortcut I configured for bbkeys to run "gnome-terminal -ls". Why do they disable a command line option, when it is working just fine? To force users to read manuals and open Properties menus? So I'm back to using rxvt again, just as on my main and plain Debian box. There were several similar things happening when upgrading. Nothing really bad, but I learned from this, that Ubuntu is not for everyone and definitely not for me. I'm not saying it's a bad distribution, it isn't. I'm just not in the target audience, I think. End of rant. ;) Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From fons.adriaensen at skynet.be Wed Jan 11 18:53:43 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Wed Jan 11 19:03:29 2006 Subject: [linux-audio-dev] [ANN] First (alpha) release of JACE Message-ID: <20060111235343.GA5156@linux-1> JACE is a Convolution Engine for JACK and ALSA, using FFT-based partitioned convolution with uniform partition sizes. I wrote it mainly as a 'proof of concept' for something more complicated, to be announced at the next LAC. But it could be useful as it is, hence this release. Main features: - Any matrix of convolutions between up to 16 input and 16 outputs. - Maximum length for each convolution is one megasample (nearly 22 seconds at 48 kHz). - Allows the use of a period size down to 1/16 of the partition size. This will not change the total delay (input + process + output) which will be twice the partition time in all cases, but at least allows you to use a smaller period size when other parts of your system require it. - It's fast (see performance examples below). When used with a period size smaller than the partition size, JACE will try to spread the CPU load evenly over all process cycles that make up a partition. This works quite well if there is enough work to be distributed, and less well otherwise. As an extreme example, if there is only one input and one output, and the convolution size is just one partition, it's clearly not possible to spread the three elementary operations over 16 cycles. But in those cases the load will be small anyway, and you can use a smaller partition size. Code to use SSE (tested) and 3DNOW (untested !) for the MAC steps is present, but disabled by default since it seems to make little difference. Performance on 2 GHz Pentium IV with 4 convolutions of 5.5 seconds each at Fs = 48 kHz. Load is as displayed by qjackctl. Delay is input + process + output. period partition load delay ----------------------------------- 1024 8k 12% 340ms 1024 4K 17% 170ms 512 4K 18% 170ms 256 4K 19% 170ms 128 2k 32% 85ms 64 1k 59% 43ms Grab it at . You will also need libfftw3f, libsndfile, and two shared libs available at the same place. Enjoy ! -- FA From srinivas_reddy at faith.co.jp Wed Jan 11 20:00:02 2006 From: srinivas_reddy at faith.co.jp (Srinivas Reddy) Date: Wed Jan 11 20:00:12 2006 Subject: [linux-audio-dev] Plz help ...Can ALSA support the "real-timemode" ? References: <43BBEFA9.5030007@t-data.com> <1136491650.847.2.camel@mindpipe><43BDD78D.1000900@t-data.com><003201c616a7$e9caf660$5b11a80a@reddyIBME970A0D0B67> <1136992521.27255.27.camel@mindpipe> Message-ID: <009801c61713$84dbe9a0$5b11a80a@reddyIBME970A0D0B67> hi Lee, Its true that the same question was posted on 2 different mailing lists and some times repeatedly,But coincidently myself and my friend had posted the same question unknowingly,will see that such things will not happen again. thank you reddy ----- Original Message ----- From: "Lee Revell" To: "The Linux Audio Developers' Mailing List" Sent: Thursday, January 12, 2006 12:15 AM Subject: Re: [linux-audio-dev] Plz help ...Can ALSA support the "real-timemode" ? > On Wed, 2006-01-11 at 21:09 +0900, Srinivas Reddy wrote: >> hi all , >> >> I am new to Linux Audio world.Can any one help me in the following >> questions. > > You asked the same question on several mailing lists, sometimes > repeatedly. It's considered polite to wait several days for a response > before doing this. > > Lee > > From a at gaydenko.com Wed Jan 11 20:07:35 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Wed Jan 11 20:01:42 2006 Subject: [linux-audio-dev] [ANN] First (alpha) release of JACE In-Reply-To: <20060111235343.GA5156@linux-1> References: <20060111235343.GA5156@linux-1> Message-ID: <200601120407.35380@goldspace.net> Hello, Fons! Congratulates! I have tried to try :-) the JACE app, but got the error show below. gcc 3.4.4 is in use. BTW, this gcc version says also: `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead. Andrew Gaydenko ____________________________________ # make g++ -O3 -Wall -DVERSION=\"0.0.1\" -DPREFIX=\"/usr\" -march=pentium4 -c -o main.o main.cc g++ -O3 -Wall -DVERSION=\"0.0.1\" -DPREFIX=\"/usr\" -march=pentium4 -c -o audio.o audio.cc g++ -O3 -Wall -DVERSION=\"0.0.1\" -DPREFIX=\"/usr\" -march=pentium4 -c -o config.o config.cc g++ -O3 -Wall -DVERSION=\"0.0.1\" -DPREFIX=\"/usr\" -march=pentium4 -c -o convolve.o convolve.cc convolve.cc: In constructor `Convdata::Convdata(size_t, size_t, int)': convolve.cc:50: error: array bound forbidden after parenthesized type-id convolve.cc:50: note: try removing the parentheses around the type-id convolve.cc: In constructor `Convolver::Convolver(size_t, size_t, int, unsigned int, unsigned int)': convolve.cc:152: error: array bound forbidden after parenthesized type-id convolve.cc:152: note: try removing the parentheses around the type-id make: *** [convolve.o] Error 1 ======= On Thursday 12 January 2006 02:53, fons adriaensen wrote: ======= JACE is a Convolution Engine for JACK and ALSA, using FFT-based partitioned convolution with uniform partition sizes. .... From srinivas_reddy at faith.co.jp Wed Jan 11 21:27:21 2006 From: srinivas_reddy at faith.co.jp (Srinivas Reddy) Date: Wed Jan 11 21:27:45 2006 Subject: [linux-audio-dev] Plz help ...Can ALSA support the "real-timemode" ? References: <43BBEFA9.5030007@t-data.com> <1136491650.847.2.camel@mindpipe><43BDD78D.1000900@t-data.com><003201c616a7$e9caf660$5b11a80a@reddyIBME970A0D0B67> <20060111124210.GB9307@bth05w.ABSp.alcatel.be> Message-ID: <011b01c6171f$b74dc4b0$5b11a80a@reddyIBME970A0D0B67> hi thanks for your reply , If we have to transfer some big data buffer from player to synthesizer is there a way to route those data appropriately through ALSA library? BR -reddy ----- Original Message ----- From: "Alfons Adriaensen" To: "The Linux Audio Developers' Mailing List" Sent: Wednesday, January 11, 2006 9:42 PM Subject: Re: [linux-audio-dev] Plz help ...Can ALSA support the "real-timemode" ? > On Wed, Jan 11, 2006 at 09:09:46PM +0900, Srinivas Reddy wrote: > >> I am having an audio engine with MIDI PLAYER and MIDI SYNTHESIZER which >> is >> running in real time mode . It means that >> the player layer send the MIDI events directly to the synthesizer that >> are >> contained in the current frame. There is no time information in the >> events >> and there is no bufferization. >> >> Q1)Does ALSA can support the "real-time mode" ? >> >> OR >> Does it support a sequenced mode ? i.e.,does the player/parser have to >> send >> time >> information to the ALSA library? > > It supports both modes. You can send midi to another app > for immediate delivery, or you can schedule it for later. > > -- > FA > From b0ef at esben-stien.name Thu Jan 12 02:40:22 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Thu Jan 12 00:47:56 2006 Subject: [linux-audio-dev] [ann] caps-0.3.0 In-Reply-To: (Tim Goetze's message of "Wed, 11 Jan 2006 19:07:49 +0100 (CET)") References: Message-ID: <87ek3d3ndl.fsf@esben-stien.name> Tim Goetze writes: > CAPS Audio Plugin Suite [..] 0.3.0 It would be great if you filled in the TYPE field;). -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From siliconjoe at gmail.com Thu Jan 12 02:48:38 2006 From: siliconjoe at gmail.com (Giuseppe Zompatori) Date: Thu Jan 12 02:48:44 2006 Subject: [linux-audio-dev] [ann] caps-0.3.0 In-Reply-To: References: Message-ID: <3a5df3c20601112348q286bff8eq@mail.gmail.com> Hello Tim, A couple of concerns with your guitar related plugs: Speaking about the compile flags you use for caps -O6 does nothing more than -O3 and from -O2 upwards there's no need to specify "-funroll-loops", also -O3 often bloats the generated code unecessairly making it slower than -O2 AFAIK. Why introduce PSU emulation (not that it's a bad thing in itself) when you're still not simulating what makes a guitar sound sweet, namely output valves? I've been looking at the source code and it seems you're just simulating a single 12AX7 preamp having weird tone stacks... In reality I've never seen something like that in other than valve based distorion/pedeal boosters... It would be cool to have amps based on real good sounding amps models where you have different preamp stages with the tone stack placed at different gain stages, or more simply preamp voicings, like say the difference you find between fender, marshall, vox,mesa boggie and soldano preamps sections, and then model the output stage with the same valves arrangements and data from the actual valves like say EL34 for marshalls and 6L6 for fender/mesa/vox/soldano/whatever... It is in the output section valves that the real "juice" comes out in a real amp, and it's the place where the different valve types and arrangements can make a huge difference, like class a vs cass ab, single ended vs parallel and push pull... I quickly gave a try to AmpV and AmpIV using a DI box, and had issues with the gain settings of those plugins, the more I rise the knob the more it gives me a farty distortion up to the point where the sounds disappears completely. I've tried this with gcc 3.2 and gcc 4.0.2. The new cab sims sound much better than the older models though, nice job you did there! Due to frustration with free as in freedom guitar amp sims, I recently bought one of those http://www.behringer.com/LX1-PRO/index.cfm?lang=ENG, it's a pity there's nothing even coming close to it in the free world up to now :( Cherrs, -Giuseppe 2006/1/11, Tim Goetze : > The ever popular CAPS Audio Plugin Suite reincarnates as v0.3.0, a > major augmentation release. > > CAPS is a LADSPA library that enjoys worldwide favour for its > high-quality instrument amplifier emulation facilities. In addition it > provides a sizeable assortment of no less sophisticated classic DSP > units for daily use as well as some more exotic sound generators and > effects. > > Most noteworthy addition is the new AmpV plugin which builds on the > previous Amp efforts. A fundamentally revised circuit design and the > emulation of power supply shortcomings make for a very mellow and > differentiating tone especially at clean to moderately rough settings. > > The new CabinetII unit further enhances the discerning electric > guitarist's digital sound setup by modelling five classical speaker > cabinets; far more faithful than the previous Cabinet plugin it builds > on, but with the same zero-latency advantage at still extremely low > CPU taxation. > > Furthermore, the new Scape plugin (if played well ;) generates epic > grooving soundscapes, the new ChorusII and PhaserII units provide > fractally modulated variants of these classics and the new SweepVFII > enhances its predecessor by allowing for modulation of filter Q. > > -*- > > This CAPS release compiles cleanly on x86-64 as well as with gcc-4.0. > Many plugins have been renamed and all have been relabelled, which > will unfortunately upset some host programs trying to load existing > setups. Consult the README files in the distribution package for > further details. > > http://quitte.de/dsp/caps.html > http://quitte.de/dsp/caps_0.3.0.tar.gz > > Please forward as you see fit. > > Enjoy, > > Tim > From S.W.Harris at ecs.soton.ac.uk Thu Jan 12 04:36:42 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu Jan 12 04:36:54 2006 Subject: [linux-audio-dev] [ann] caps-0.3.0 In-Reply-To: <3a5df3c20601112348q286bff8eq@mail.gmail.com> References: <3a5df3c20601112348q286bff8eq@mail.gmail.com> Message-ID: <20060112093641.GB9991@login.ecs.soton.ac.uk> On Thu, Jan 12, 2006 at 08:48:38 +0100, Giuseppe Zompatori wrote: > Hello Tim, > > A couple of concerns with your guitar related plugs: > > Speaking about the compile flags you use for caps -O6 does nothing > more than -O3 and from -O2 upwards there's no need to specify > "-funroll-loops", also -O3 often bloats the generated code > unecessairly making it slower than -O2 AFAIK. That's often true, but in some experiments I did with an older gcc and a Pentium III, -O3 came out better than -O2 on average for plugin code. Generally the inner loop is quite small, so even when bloated it still fits in the cache. Those experimetns should be repeated on up to date architectures and compilers though. I had the intention of writing a script to try different optimisation flags on each plugin to find better settings, but then I decided it was a waste of effort, and it would just make the Makefile huge. - Steve From fons.adriaensen at alcatelaleniaspace.com Thu Jan 12 04:38:24 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Thu Jan 12 04:38:35 2006 Subject: [linux-audio-dev] [ANN] First (alpha) release of JACE In-Reply-To: <200601120407.35380@goldspace.net> References: <20060111235343.GA5156@linux-1> <200601120407.35380@goldspace.net> Message-ID: <20060112093824.GA9846@bth05w.ABSp.alcatel.be> On Thu, Jan 12, 2006 at 04:07:35AM +0300, Andrew Gaydenko wrote: > convolve.cc: In constructor `Convdata::Convdata(size_t, size_t, int)': > convolve.cc:50: error: array bound forbidden after parenthesized type-id > convolve.cc:50: note: try removing the parentheses around the type-id > convolve.cc: In constructor `Convolver::Convolver(size_t, size_t, int, unsigned int, unsigned int)': > convolve.cc:152: error: array bound forbidden after parenthesized type-id > convolve.cc:152: note: try removing the parentheses around the type-id > make: *** [convolve.o] Error 1 And did you try removing the parentheses ? But I wonder what is wrong with _fftd = new (fftwf_complex *)[_npar]; -- FA From siliconjoe at gmail.com Thu Jan 12 04:47:20 2006 From: siliconjoe at gmail.com (Giuseppe Zompatori) Date: Thu Jan 12 04:47:25 2006 Subject: [linux-audio-dev] [ann] caps-0.3.0 In-Reply-To: References: Message-ID: <3a5df3c20601120147h668e00cx@mail.gmail.com> Sorry for the dupes, I canceled 2 of them via the web interface because they were being moderated, but they still made it to the list!?!? -Giuseppe 2006/1/11, Tim Goetze : > The ever popular CAPS Audio Plugin Suite reincarnates as v0.3.0, a > major augmentation release. > > CAPS is a LADSPA library that enjoys worldwide favour for its > high-quality instrument amplifier emulation facilities. In addition it > provides a sizeable assortment of no less sophisticated classic DSP > units for daily use as well as some more exotic sound generators and > effects. > > Most noteworthy addition is the new AmpV plugin which builds on the > previous Amp efforts. A fundamentally revised circuit design and the > emulation of power supply shortcomings make for a very mellow and > differentiating tone especially at clean to moderately rough settings. > > The new CabinetII unit further enhances the discerning electric > guitarist's digital sound setup by modelling five classical speaker > cabinets; far more faithful than the previous Cabinet plugin it builds > on, but with the same zero-latency advantage at still extremely low > CPU taxation. > > Furthermore, the new Scape plugin (if played well ;) generates epic > grooving soundscapes, the new ChorusII and PhaserII units provide > fractally modulated variants of these classics and the new SweepVFII > enhances its predecessor by allowing for modulation of filter Q. > > -*- > > This CAPS release compiles cleanly on x86-64 as well as with gcc-4.0. > Many plugins have been renamed and all have been relabelled, which > will unfortunately upset some host programs trying to load existing > setups. Consult the README files in the distribution package for > further details. > > http://quitte.de/dsp/caps.html > http://quitte.de/dsp/caps_0.3.0.tar.gz > > Please forward as you see fit. > > Enjoy, > > Tim > From arnold.krille at gmail.com Thu Jan 12 05:41:58 2006 From: arnold.krille at gmail.com (Arnold Krille) Date: Thu Jan 12 05:42:05 2006 Subject: [linux-audio-dev] Call for help for LinuxTag2006 Message-ID: <2def88b80601120241u7af0baeev@mail.gmail.com> Hi all, as every year the famous german LinuxTag is taking place. This year in Wiesbaden from 3. to 6. May. Yes, this is just one week after LAC2006, which has several advantages and disadvantages: + It is a good chance to come to Germany for LAC, have one or two days of holiday and then join the LA-Group at LinuxTag! + Maybe even repeat your LAC-Talk at LinuxTag? (see www.linuxtag.org for details on the Call-for-Papers but be aware that it ends January 15...) + Wiesbaden is more in the center of germany so perhaps some LA-folks from the north of germany can join us? - The new place for LinuxTag together with LAC being a week before enforce two of the main-booth-members of the last years (Christoph Eckert and Frank Neumann) to be only a visitor at LinuxTag or even less... That leaves a hole in the organisational part. :-( So here is my call: I am willing to do some work organizing a booth and a group of staff but I need YOUR help! If you are a german LA[DU]-member and have some spare time, join in! A booth at LinuxTag is a good opportunity to present Linux Audio to the people, not only to developers but more to users. The crowd is mostly industry (producers, technicians, musicians) at the weekdays and home-recording-users at the weekend. Don't be afraid, there won't be much questions about setting up drivers for consumer-cards (and If there are, we usually send them to their distributions booth :-) ). But there will be a lot people thinking about using your app in studio! So you definitly don't want to miss this chance! If I get positive answers from at least two other people by weekend, I will apply for a booth and things start rolling, so don't hesitate, check your calendar, plan for another week of holiday and join me (us?). So long and thanks for all the fish, Arnold -- visit http://dillenburg.dyndns.org/~arnold/ --- Wenn man mit Raubkopien Bands wie Brosis oder Britney Spears wirklich verhindern k?nnte, w?rde ich mir noch heute einen Stapel Brenner und einen Sack Rohlinge kaufen. From a at gaydenko.com Thu Jan 12 06:45:14 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Thu Jan 12 06:39:06 2006 Subject: [linux-audio-dev] [ANN] First (alpha) release of JACE In-Reply-To: <20060112093824.GA9846@bth05w.ABSp.alcatel.be> References: <20060111235343.GA5156@linux-1> <200601120407.35380@goldspace.net> <20060112093824.GA9846@bth05w.ABSp.alcatel.be> Message-ID: <200601121445.14991@goldspace.net> Fons, Yes, I did it just now. I have tried to use the demo.conf config, all works. The most impressive is a few seconds period after a 'pause' pressed :-) Andrew ======= On Thursday 12 January 2006 12:38, Alfons Adriaensen wrote: ======= On Thu, Jan 12, 2006 at 04:07:35AM +0300, Andrew Gaydenko wrote: > convolve.cc: In constructor `Convdata::Convdata(size_t, size_t, int)': > convolve.cc:50: error: array bound forbidden after parenthesized type-id > convolve.cc:50: note: try removing the parentheses around the type-id > convolve.cc: In constructor `Convolver::Convolver(size_t, size_t, int, unsigned int, unsigned int)': > convolve.cc:152: error: array bound forbidden after parenthesized type-id > convolve.cc:152: note: try removing the parentheses around the type-id > make: *** [convolve.o] Error 1 And did you try removing the parentheses ? But I wonder what is wrong with _fftd = new (fftwf_complex *)[_npar]; -- FA From tim at quitte.de Thu Jan 12 07:01:10 2006 From: tim at quitte.de (Tim Goetze) Date: Thu Jan 12 07:03:57 2006 Subject: [linux-audio-dev] [ann] caps-0.3.0 In-Reply-To: <87ek3d3ndl.fsf@esben-stien.name> References: <87ek3d3ndl.fsf@esben-stien.name> Message-ID: [Esben Stien] >Tim Goetze writes: > >> CAPS Audio Plugin Suite [..] 0.3.0 > >It would be great if you filled in the TYPE field;). It might just be my pre-coffee slowness but I'm afraid I can't figure out which TYPE field you mean .. LADSPA, RDF, C++, or another 'TYPE' altogether? Please enlighten me! Cheers, Tim From fons.adriaensen at alcatelaleniaspace.com Thu Jan 12 07:41:00 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Thu Jan 12 07:41:14 2006 Subject: [linux-audio-dev] [ANN] First (alpha) release of JACE In-Reply-To: <200601121445.14991@goldspace.net> References: <20060111235343.GA5156@linux-1> <200601120407.35380@goldspace.net> <20060112093824.GA9846@bth05w.ABSp.alcatel.be> <200601121445.14991@goldspace.net> Message-ID: <20060112124100.GC9846@bth05w.ABSp.alcatel.be> On Thu, Jan 12, 2006 at 02:45:14PM +0300, Andrew Gaydenko wrote: > Yes, I did it just now. I have tried to use the demo.conf config, all works. Great ! I'll upload a corrected version later today. > The most impressive is a few seconds period after a 'pause' pressed :-) Yes, it's a nice reverb. I tried it yesterday evening with a relatively dry studio recording of a small baroque orchestra - the type of music one could hear in a church - and it sounded completely natural. It *is* a real reverb of course... -- FA From b0ef at esben-stien.name Thu Jan 12 09:48:50 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Thu Jan 12 07:56:26 2006 Subject: [linux-audio-dev] [ann] caps-0.3.0 In-Reply-To: (Tim Goetze's message of "Thu, 12 Jan 2006 13:01:10 +0100 (CET)") References: <87ek3d3ndl.fsf@esben-stien.name> Message-ID: <87slrtpkml.fsf@esben-stien.name> Tim Goetze writes: > Please enlighten me! RDF, so it's possible to categorize it and look it up quickly;). OT: I think it's wrong to write the type names as plurals. A formal categorization should not use plurals. It's the "Generator" group, not the "Generators" group, f.ex. -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From tim at quitte.de Thu Jan 12 08:02:16 2006 From: tim at quitte.de (Tim Goetze) Date: Thu Jan 12 08:05:04 2006 Subject: [linux-audio-dev] [ann] caps-0.3.0 In-Reply-To: <87slrtpkml.fsf@esben-stien.name> References: <87ek3d3ndl.fsf@esben-stien.name> <87slrtpkml.fsf@esben-stien.name> Message-ID: [Esben Stien] >Tim Goetze writes: > >> Please enlighten me! > >RDF, so it's possible to categorize it and look it up quickly;). > >OT: I think it's wrong to write the type names as plurals. A formal >categorization should not use plurals. It's the "Generator" group, not >the "Generators" group, f.ex. Please send a patch or a complete file, I don't do LADSPA RDF. Cheers, Tim From tim at quitte.de Thu Jan 12 08:14:10 2006 From: tim at quitte.de (Tim Goetze) Date: Thu Jan 12 08:16:59 2006 Subject: [linux-audio-dev] [ann] caps-0.3.0 In-Reply-To: <3a5df3c20601112348q286bff8eq@mail.gmail.com> References: <3a5df3c20601112348q286bff8eq@mail.gmail.com> Message-ID: [Giuseppe Zompatori] >Speaking about the compile flags you use for caps -O6 does nothing >more than -O3 and from -O2 upwards there's no need to specify >"-funroll-loops", also -O3 often bloats the generated code >unecessairly making it slower than -O2 AFAIK. To tell the truth, I've never evaluated different -O settings (neither have I looked up their implication of other optimization flags). I'll keep it in mind, but it's not the highest priority. Also, the benefits of different -O and other flags might differ on PPC, x86, x86+sse, x86+sse2, x86-64, amd or intel etc. I'd happily be convinced by some hard facts (code size vs. execution speed) though. :) >Why introduce PSU emulation (not that it's a bad thing in itself) when >you're still not simulating what makes a guitar sound sweet, namely >output valves? Why yes, AmpV actually models a (granted, _very_ simple but nonetheless sweet to my ears) approximation of output stage saturation. >I've been looking at the source code and it seems you're just >simulating a single 12AX7 preamp having weird tone stacks... In >reality I've never seen something like that in other than valve based >distorion/pedeal boosters... True, it's a single preamp tube. There used to be two, just like in the real circuits I've analyzed, but the effects of the first one are far too subtle to make a palpable difference in tone. Thus, it fell victim to optimization. >It would be cool to have amps based on real good sounding amps models >where you have different preamp stages with the tone stack placed at >different gain stages, or more simply preamp voicings, like say the >difference you find between fender, marshall, vox,mesa boggie and >soldano preamps sections, and then model the output stage with the >same valves arrangements and data from the actual valves like say EL34 >for marshalls and 6L6 for fender/mesa/vox/soldano/whatever... You're forgetting the influence of output transformers on the tone, which is just as important as the power amplification tube stage, plus the non-linear effects of the final output speakers! :) Not that I have anything against modelling all these effects better. Yet, we're talking about a few months of work here, mostly analysis of real circuits and speakers in theory as well as in operation. And, see below .. >It is in the output section valves that the real "juice" comes out in >a real amp, and it's the place where the different valve types and >arrangements can make a huge difference, like class a vs cass ab, >single ended vs parallel and push pull... My opinion is that these effects only become a major tone-forming factor if the amp in question is driven _real_ hard (master gain close or at maximum, up to this the data I have gathered from my real amp indicates it's all fairly linear). I've always been playing small amps at moderate volume in real life, and the only time I ever played one in the vicinity of maximum output power, the output transformer melted down within minutes. Not my cup of tea, thank you. (I didn't even like the sound while it lasted. Go figure :) >I quickly gave a try to AmpV and AmpIV using a DI box, and had issues >with the gain settings of those plugins, the more I rise the knob the >more it gives me a farty distortion up to the point where the sounds >disappears completely. I've tried this with gcc 3.2 and gcc 4.0.2. Have you tried raising the AmpV 'watts' parameter to its maximum setting? The effect you describe should be completely gone by then with AmpV. Also, AmpV has never been designed with high-gain scenarios in mind. With AmpIV however, what you describe is not the expected behaviour. Does the AmpIV from caps-0.2.3 give the same effect? In any event, can you send me your AmpIV settings (and other plugins' settings making up the FX chain) and a short input signal sample so I can recreate the problem? >Due to frustration with free as in freedom guitar amp sims, I recently >bought one of those >http://www.behringer.com/LX1-PRO/index.cfm?lang=ENG, it's a pity >there's nothing even coming close to it in the free world up to now :( Well, glad you found an escape route, and sorry for wasting your time with my poor efforts! :) In the end, it seems the two of us are after a different kind of guitar tone. I've been playing AmpV in a jam lately and not once over the course of the session have I felt the need to fiddle with the sound (and that's a first). I'm more than happy with it, sorry to hear you're not. Thanks for your feedback, I appreciate it, Cheers, Tim From jayv at synth.net Thu Jan 12 08:29:50 2006 From: jayv at synth.net (Jay Vaughan) Date: Thu Jan 12 08:30:18 2006 Subject: [linux-audio-dev] synthesis on gp2x .. (was Fwd: RE: [gpx-dev] hardware interfaces) Message-ID: just to let you guys know .. following up on the GP2X synthesis thread from earlier, the author of littleGPtracker for the GP32 (ARM-based handheld predecessor to the GP2X) has this to say about synthesis on ARM .. j. >Delivered-To: 29-jayv@synth.net >From: "M-.-n" >To: >Subject: RE: [gpx-dev] hardware interfaces >Date: Thu, 12 Jan 2006 09:20:05 +0100 >X-Priority: 3 (Normal) >Importance: Normal >X-BeenThere: gpx-dev@ampfea.org >X-Mailman-Version: 2.1.5 >Reply-To: gpx-dev@ampfea.org >List-Id: gpx-dev.ampfea.org >List-Unsubscribe: , > >List-Archive: >List-Post: >List-Help: >List-Subscribe: , > >Sender: gpx-dev-bounces@ampfea.org > > > >On littleGPtracker (still GP32; running @133Mhz), I do 8 monophonic stereo >voices (sampled based) using about 50% of the CPU. This includes possibility >of arpegiation, pitch shifting, legato & volume envelope control but no >filters yet. Sure the sample engine is pretty crude at the moment but u will >have PLENTY enough power in the 2x to do nifty things. > >-----Original Message----- > >MHz does not say much, I think, but it should be plenty to do a lot of >fun with :) > >-- > >Joost Schuttelaar > >_______________________________________________ >gpx-dev mailing list >gpx-dev@ampfea.org >http://www.ampfea.org/mailman/listinfo/gpx-dev > > > > >_______________________________________________ >gpx-dev mailing list >gpx-dev@ampfea.org >http://www.ampfea.org/mailman/listinfo/gpx-dev -- ; Jay Vaughan From bil at ccrma.Stanford.EDU Thu Jan 12 08:51:52 2006 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Thu Jan 12 08:51:59 2006 Subject: [linux-audio-dev] Re: -O3 etc In-Reply-To: <20060112131700.6EDCC1961C8@music.columbia.edu> References: <20060112131700.6EDCC1961C8@music.columbia.edu> Message-ID: <20060112134509.M69325@ccrma.Stanford.EDU> I ran some timing tests, partly to check out -fast-math -- my informal impression is that it speeds up exp by a factor of about 2, but can slow down other things (FIR filters). I didn't see any obvious improvement in -O3 over -O2. The actual numbers are in the snd tarball, snd-edits.c -- look for "fast-math". (The table is aimed more at comparing int/float/double operations). These timing numbers change by a factor of, say, 20% on each run, so don't put much weight on them. From david at olofson.net Thu Jan 12 10:19:11 2006 From: david at olofson.net (David Olofson) Date: Thu Jan 12 09:27:35 2006 Subject: [linux-audio-dev] ANN: DT-42 DrumToy 0.1.0 In-Reply-To: <200601111219.06649.tito@rumford.de> References: <200601072301.15752.david@olofson.net> <200601111219.06649.tito@rumford.de> Message-ID: <200601121619.11883.david@olofson.net> On Wednesday 11 January 2006 12:19, Wolfgang Woehl wrote: > David Olofson : > > DT-42 DrumToy 0.1.0 - First Release > > Jackify this and you will be worshipped. A fun tracker machine, > thank you. Well, I have a few ideas about what to do with it next. I'd like to keep it as portable as possible, but that doesn't mean it can't support serious APIs on serious platforms. :-) > Oh, it could be a bit more verbose when it fails to > access an > audio device which is the case when jack is in control, had to kill > -9 it. Hmm... I would have thought SDL should fail if it can't open an audio device. If it doesn't, there isn't much I can do, short of bypassing SDL audio entirely. (As in, using JACK instead. :-) //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --' From david at olofson.net Thu Jan 12 10:34:06 2006 From: david at olofson.net (David Olofson) Date: Thu Jan 12 09:42:29 2006 Subject: [linux-audio-dev] ANN: DT-42 DrumToy 0.1.0 In-Reply-To: <20060111120402.GE26293@login.ecs.soton.ac.uk> References: <200601072301.15752.david@olofson.net> <200601111219.06649.tito@rumford.de> <20060111120402.GE26293@login.ecs.soton.ac.uk> Message-ID: <200601121634.06105.david@olofson.net> On Wednesday 11 January 2006 13:04, Steve Harris wrote: > On Wed, Jan 11, 2006 at 12:19:06PM +0100, Wolfgang Woehl wrote: > > David Olofson : > > > DT-42 DrumToy 0.1.0 - First Release > > > > Jackify this and you will be worshipped. > > Or DSSI-ify it? It would be more versatile that way. Maybe... But what would be more useful; making the GUI + sequencer a DSSI host, and the (very simple) synth a DSSI plugin, or basically leaving them integrated, using MIDI to sync and/or trig patterns and stuff? (The "synth" just plays samples and very simple 2 operator FM sounds, so it doesn't seem all that interesting in it's own right. :-) //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --' From pcoccoli at gmail.com Thu Jan 12 09:45:09 2006 From: pcoccoli at gmail.com (Paul Coccoli) Date: Thu Jan 12 09:45:16 2006 Subject: [linux-audio-dev] Re: -O3 etc In-Reply-To: <20060112134509.M69325@ccrma.Stanford.EDU> References: <20060112131700.6EDCC1961C8@music.columbia.edu> <20060112134509.M69325@ccrma.Stanford.EDU> Message-ID: <8d27a0610601120645p13537d67k2ce268a58711db83@mail.gmail.com> On 1/12/06, Bill Schottstaedt wrote: > I ran some timing tests, partly to check out -fast-math -- my informal impression > is that it speeds up exp by a factor of about 2, but can slow down other things > (FIR filters). I didn't see any obvious improvement in -O3 over -O2. The > actual numbers are in the snd tarball, snd-edits.c -- look for "fast-math". > (The table is aimed more at comparing int/float/double operations). These > timing numbers change by a factor of, say, 20% on each run, so don't put > much weight on them. > > I read somewhere that -Os (optimize for "smaller" code, intended for embedded systems maybe?) sometimes produces faster code than -O2 or -O3. Has anybody tried that on their plugins or anything else? Might not help at all if, as Steve Harris said, most plugin inner loops fit in cache already. From m_nels at gmx.net Thu Jan 12 10:11:56 2006 From: m_nels at gmx.net (Michael T D Nelson) Date: Thu Jan 12 10:12:05 2006 Subject: [linux-audio-dev] synthesis on gp2x .. (was Fwd: RE: [gpx-dev] hardware interfaces) In-Reply-To: References: Message-ID: <43C671BC.8000904@gmx.net> Jay Vaughan wrote: > > just to let you guys know .. following up on the GP2X synthesis thread > from earlier, the author of littleGPtracker for the GP32 (ARM-based > handheld predecessor to the GP2X) has this to say about synthesis on ARM .. > That sounds fairly promising. On another note, have you heard about the current situation regarding the availability of source code for the port of the Linux kernel to the GP2X? It seems that the manufacturer have only made a significantly out-of-date release of the source available, almost certainly violating the GPL. Still, I'm hopeful that it will be sorted out. I spoke to the UK distributor today, and it sounds as though the guy in charge here is going to do his best to hassle people. I told him I was keen to buy one - but would hold back until the GPL was being complied with. Regards Michael From mlang at delysid.org Thu Jan 12 10:22:44 2006 From: mlang at delysid.org (Mario Lang) Date: Thu Jan 12 10:21:56 2006 Subject: [linux-audio-dev] liblo lo_message_deserialise? Message-ID: <873bjtpj23.fsf@x2.delysid.org> Hi. While playing a little with the liblo lowlevel interface (I am trying to deliver and receive/decode OSC messages via a non-UDP/TCP transport), I found lo_message_serialise. I also had to rip a bit of code from lo_send_internal and friends. However, I cant find a counterpart for decomposing messages, so I guess currently, I would have to rip even more code out of the lib itself. I am wondering, would anyone else benefit from a clean lowlevel API for decoding messages to a lo_message? I am imagining something like lo_message lo_message_from_buffer (char *buf, int size) Any comments? -- CYa, Mario From jayv at synth.net Thu Jan 12 10:26:49 2006 From: jayv at synth.net (Jay Vaughan) Date: Thu Jan 12 10:27:01 2006 Subject: [linux-audio-dev] synthesis on gp2x .. (was Fwd: RE: [gpx-dev] hardware interfaces) In-Reply-To: <43C671BC.8000904@gmx.net> References: <43C671BC.8000904@gmx.net> Message-ID: >On another note, have you heard about the current situation >regarding the availability of source code for the port of the Linux >kernel to the GP2X? > yes, tho' this is changing the subject. i'm sure the GPL issues with GPH will get resolved; certainly i've been keeping a very close eye on it and i'm pretty sure that there is more to this story than is being reported on slashdot .. in the meantime there is some serious hacking still going on with this console, and there aren't actually any problems with continuing to hack code for the GP2X .. i have it on good authority (guys working directly with GPH) that this issue is getting sorted out finally, for good and all, and that the problems are related to the fact that there are 3 parties involved in the GP2X' codebase .. and all need to get on the same page. this is happening. >I told him I was keen to buy one - but would hold back until the GPL >was being complied with. well, that'd be a pity, because there's not actually anything about their code release thats going to prevent you from running your own code on it .. there's nothing stopping you from upgrading the kernel to an open one, nothing preventing you from writing new code for the platform, which is open, functioning, and able to run whatever code you write for it. the only issue is that there are bins being shipped with source not available; but you can most certainly port whatever source you want to the machine, including source for the onboard apps available elsewhere, so its not really a barrier to enjoying the platform; it is, of course, yet again, "niggly dogmatics" versus 'those who are writing code and getting on with it' .. the gp2x just plain rocks. nothing quite like having a completed linux platform in your pocket, running thousands and thousands of games, and soon .. music software of note. for example, i think you can all expect to see news about drum machines, trackers, sequencers, patch librarians, and editors, on the gp2x platform, in the coming weeks and months .. not bad for a battery-powered pocket, portable linux device. -- ; Jay Vaughan From paul at linuxaudiosystems.com Thu Jan 12 10:52:58 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Thu Jan 12 10:50:01 2006 Subject: [linux-audio-dev] synthesis on gp2x .. (was Fwd: RE: [gpx-dev] hardware interfaces) In-Reply-To: References: <43C671BC.8000904@gmx.net> Message-ID: <1137081178.11947.95.camel@localhost.localdomain> > the gp2x just plain rocks. nothing quite like having a completed > linux platform in your pocket, running thousands and thousands of > games, and soon .. music software of note. for example, i think you > can all expect to see news about drum machines, trackers, sequencers, > patch librarians, and editors, on the gp2x platform, in the coming > weeks and months .. not bad for a battery-powered pocket, portable > linux device. exciting, but it will be completely divergent from the intel/ppc world because of the floating point issue. this is really a great shame. floating point versus fixed point samples will reach deep into most audio/music software, and certainly deep in JACK. i can just about begin to imagine how one might write a JACK and a JACK client that could run on fixed or floating point, but beginning is where i give up. --p From jayv at synth.net Thu Jan 12 10:56:19 2006 From: jayv at synth.net (Jay Vaughan) Date: Thu Jan 12 10:56:31 2006 Subject: [linux-audio-dev] synthesis on gp2x .. (was Fwd: RE: [gpx-dev] hardware interfaces) In-Reply-To: <1137081178.11947.95.camel@localhost.localdomain> References: <43C671BC.8000904@gmx.net> <1137081178.11947.95.camel@localhost.localdomain> Message-ID: > >exciting, but it will be completely divergent from the intel/ppc world >because of the floating point issue. > so? any particular reason a linux hacker should give a damn? are intel/ppc the only CPU's worth writing audio software for? should linux become platform-homogenized, just because of this issue? i think not! >this is really a great shame. its not a shame, its an opportunity. nothing less! >floating point versus fixed point samples >will reach deep into most audio/music software, and certainly deep in >JACK. i can just about begin to imagine how one might write a JACK and a >JACK client that could run on fixed or floating point, but beginning is >where i give up. good thing you aren't the only one writing code then, isn't it .. i mean, sure, JACK is lovely, Ardour too, but its really a shame you can only run them on intel/ppc .. -- ; Jay Vaughan From fons.adriaensen at alcatelaleniaspace.com Thu Jan 12 11:29:22 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Thu Jan 12 11:29:39 2006 Subject: [linux-audio-dev] synthesis on gp2x .. (was Fwd: RE: [gpx-dev] hardware interfaces) In-Reply-To: <1137081178.11947.95.camel@localhost.localdomain> References: <43C671BC.8000904@gmx.net> <1137081178.11947.95.camel@localhost.localdomain> Message-ID: <20060112162922.GD9846@bth05w.ABSp.alcatel.be> On Thu, Jan 12, 2006 at 10:52:58AM -0500, Paul Davis wrote: > i can just about begin to imagine how one might write a JACK and a > JACK client that could run on fixed or floating point, but beginning is > where i give up. JACK itself shouldn't be affected too much. Apart from the dithering it does not do any processing. The standard sample type could be a signed 32 bit, with bits 23 downto 24-N mapped to N-bit hardware. On input bits 24..31 are sign extended from bit 23, on output the values are clipped as they are now. In other words, the standard format could be 9.23 fixed point. This makes the hardware resolution transparent to clients and accomodates all hardware up to 24 bits (it's useless to go beyond that). If you look at the history of digital audio, most of it was integer or fixed point. There is a enormous amount of knowledge gathered over the years on how to do things correctly in that format. I can still remember the JAES papers on how to avoid limit cycles in IIR filters etc... -- FA From david at olofson.net Thu Jan 12 12:26:13 2006 From: david at olofson.net (David Olofson) Date: Thu Jan 12 11:34:36 2006 Subject: [linux-audio-dev] synthesis on gp2x .. (was Fwd: RE: [gpx-dev] =?iso-8859-1?q?=09hardware?= interfaces) In-Reply-To: References: <1137081178.11947.95.camel@localhost.localdomain> Message-ID: <200601121826.13512.david@olofson.net> On Thursday 12 January 2006 16:56, Jay Vaughan wrote: > > > >exciting, but it will be completely divergent from the intel/ppc > >world because of the floating point issue. > > > > so? any particular reason a linux hacker should give a damn? are > intel/ppc the only CPU's worth writing audio software for? should > linux become platform-homogenized, just because of this issue? i > think not! Well, the only problem is that you have to write all DSP code twice, basically. Then again, the DSP code usually accounts for just a fraction of the code of a full application. And heavy duty, DSP centric applications (ie ones with lots of DSP code) probably won't be of much use without a GFLOPS class CPU anyway. > >this is really a great shame. > > its not a shame, its an opportunity. nothing less! > > >floating point versus fixed point samples > >will reach deep into most audio/music software, and certainly deep > >in JACK. i can just about begin to imagine how one might write a > >JACK and a JACK client that could run on fixed or floating point, > >but beginning is where i give up. > > good thing you aren't the only one writing code then, isn't it .. i > mean, sure, JACK is lovely, Ardour too, but its really a shame you > can only run them on intel/ppc .. > > I would think you can compile and run them on just about anything - but without proper FP support (that is, an extremely fast integer CPU + FP emulation, or "anything" with a proper FPU), they won't run fast enough to do anything useful, unless all DSP code is translated to integer/fixed point. I can certainly understand why someone who isn't seriously interested in the odd few platforms with enough oomph but no FP, would lack the motivation to write and/or maintain code that is relevant only on these platforms. //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --' From jayv at synth.net Thu Jan 12 12:06:29 2006 From: jayv at synth.net (Jay Vaughan) Date: Thu Jan 12 12:06:53 2006 Subject: [linux-audio-dev] synthesis on gp2x .. (was Fwd: RE: [gpx-dev] hardware interfaces) In-Reply-To: <200601121826.13512.david@olofson.net> References: <1137081178.11947.95.camel@localhost.localdomain> <200601121826.13512.david@olofson.net> Message-ID: >Then again, the DSP code usually accounts for just a fraction of the >code of a full application. .. unless you put such DSP code in certain 'key infrastructure' components of the system .. >And heavy duty, DSP centric applications >(ie ones with lots of DSP code) probably won't be of much use without >a GFLOPS class CPU anyway. >I would think you can compile and run them on just about anything - >but without proper FP support (that is, an extremely fast integer CPU >+ FP emulation, or "anything" with a proper FPU), they won't run fast >enough to do anything useful, unless all DSP code is translated to >integer/fixed point. its amazing though, how there are good quality examples of audio/DSP code which don't require FP .. which do in fact use integer/fixed point math .. and which function just fine in cheap hardware .. >I can certainly understand why someone who isn't seriously interested >in the odd few platforms with enough oomph but no FP, would lack the >motivation to write and/or maintain code that is relevant only on >these platforms. oh, so can i, for sure.. i mean, if you've taken the easy path once, no need to consider any other path twice .. except to bemoan the existence of such other paths, of course .. regardless, there certainly seems to be potential in the GP2X' lowly cpu's for interesting audio hacking, and i certainly hope its acceptable to the cognescenti to recognize this fact, FP or none .. -- ; Jay Vaughan From rlrevell at joe-job.com Thu Jan 12 15:10:39 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Jan 12 15:10:45 2006 Subject: [linux-audio-dev] synthesis on gp2x .. (was Fwd: RE: [gpx-dev] hardware interfaces) In-Reply-To: References: <43C671BC.8000904@gmx.net> Message-ID: <1137096640.2370.40.camel@mindpipe> On Thu, 2006-01-12 at 16:26 +0100, Jay Vaughan wrote: > >I told him I was keen to buy one - but would hold back until the GPL > >was being complied with. > > well, that'd be a pity, because there's not actually anything about > their code release thats going to prevent you from running your own > code on it .. there's nothing stopping you from upgrading the kernel > to an open one, nothing preventing you from writing new code for the > platform, which is open, functioning, and able to run whatever code > you write for it. the only issue is that there are bins being > shipped with source not available; but you can most certainly port > whatever source you want to the machine, including source for the > onboard apps available elsewhere, so its not really a barrier to > enjoying the platform; it is, of course, yet again, "niggly > dogmatics" versus 'those who are writing code and getting on with it' No, it's not a pity at all, we should not support GPL violators by buying their hardware. Lee From jayv at synth.net Thu Jan 12 15:34:53 2006 From: jayv at synth.net (Jay Vaughan) Date: Thu Jan 12 15:35:41 2006 Subject: [linux-audio-dev] synthesis on gp2x .. (was Fwd: RE: [gpx-dev] hardware interfaces) In-Reply-To: <1137096640.2370.40.camel@mindpipe> References: <43C671BC.8000904@gmx.net> <1137096640.2370.40.camel@mindpipe> Message-ID: >No, it's not a pity at all, we should not support GPL violators by >buying their hardware. errm.. in my limited GPL'itude, i thought the rule was that we should be running GPL software wherever we can, and choose to? fact is, gp2x is nice hardware to run, 100%, your own code on. of the code that currently makes the GP2X fun and great, and great fun, there is a lot, like, a majority of it, that is open, shared, and well-orchestrated as a community resource by its maintainers. and the hardware is the right price. GPH may not be communicating too well, no, but the spirit of the GPL is hot on this box, and i really believe GPH are making GPL compatible, and thus ultra-friendly, hardware, anyway .. i don't read enough korean complaints about it, either, though i certainly wish i could. ever had kimschi, or know how to make it? -- ; Jay Vaughan From S.W.Harris at ecs.soton.ac.uk Thu Jan 12 16:45:11 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu Jan 12 16:45:24 2006 Subject: [linux-audio-dev] [ann] caps-0.3.0 In-Reply-To: <87slrtpkml.fsf@esben-stien.name> References: <87ek3d3ndl.fsf@esben-stien.name> <87slrtpkml.fsf@esben-stien.name> Message-ID: <20060112214510.GE6806@login.ecs.soton.ac.uk> On Thu, Jan 12, 2006 at 03:48:50 +0100, Esben Stien wrote: > Tim Goetze writes: > > > Please enlighten me! > > RDF, so it's possible to categorize it and look it up quickly;). > > OT: I think it's wrong to write the type names as plurals. A formal > categorization should not use plurals. It's the "Generator" group, not > the "Generators" group, f.ex. Its a perosnaly preference thing, rdf types are classes, and in english you talk about the "class of generators"*. But, the RDF type URIs are just symbols for machine consupmtion, they have (should have?) labels that can be used for display purposes, and they can read whatever you like. * though I generally use the singular, dunno why I chose plural that day - Steve From S.W.Harris at ecs.soton.ac.uk Thu Jan 12 16:58:34 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu Jan 12 16:58:46 2006 Subject: [linux-audio-dev] liblo lo_message_deserialise? In-Reply-To: <873bjtpj23.fsf@x2.delysid.org> References: <873bjtpj23.fsf@x2.delysid.org> Message-ID: <20060112215834.GF6806@login.ecs.soton.ac.uk> On Thu, Jan 12, 2006 at 04:22:44 +0100, Mario Lang wrote: > Hi. > > While playing a little with the liblo lowlevel interface > (I am trying to deliver and receive/decode OSC messages via a non-UDP/TCP > transport), I found lo_message_serialise. I also had to rip > a bit of code from lo_send_internal and friends. > However, I cant find a counterpart for decomposing messages, so > I guess currently, I would have to rip even more code out of > the lib itself. I am wondering, would anyone else benefit > from a clean lowlevel API for decoding messages to a lo_message? > > I am imagining something like > > lo_message lo_message_from_buffer (char *buf, int size) > > Any comments? Make sense to me, and it would make lo_server_recv() cleaner if the OSC parsing stuff was seperate from the IO stuff. - Steve From m_nels at gmx.net Thu Jan 12 17:19:21 2006 From: m_nels at gmx.net (Michael T D Nelson) Date: Thu Jan 12 17:19:32 2006 Subject: [linux-audio-dev] [ann] caps-0.3.0 In-Reply-To: <20060112214510.GE6806@login.ecs.soton.ac.uk> References: <87ek3d3ndl.fsf@esben-stien.name> <87slrtpkml.fsf@esben-stien.name> <20060112214510.GE6806@login.ecs.soton.ac.uk> Message-ID: <43C6D5E9.7000909@gmx.net> Steve Harris wrote: > On Thu, Jan 12, 2006 at 03:48:50 +0100, Esben Stien wrote: >>OT: I think it's wrong to write the type names as plurals. A formal >>categorization should not use plurals. It's the "Generator" group, not >>the "Generators" group, f.ex. > Its a perosnaly preference thing, rdf types are classes, and in english > you talk about the "class of generators"*. But you might also talk of a "generator class"... :o) Regards Michael From david at olofson.net Thu Jan 12 23:14:56 2006 From: david at olofson.net (David Olofson) Date: Thu Jan 12 22:23:18 2006 Subject: [linux-audio-dev] synthesis on gp2x .. (was Fwd: RE: [gpx-dev] =?iso-8859-1?q?=09=09hardware?= interfaces) In-Reply-To: References: <200601121826.13512.david@olofson.net> Message-ID: <200601130514.56434.david@olofson.net> On Thursday 12 January 2006 18:06, Jay Vaughan wrote: > > >Then again, the DSP code usually accounts for just a fraction of > >the code of a full application. > > .. unless you put such DSP code in certain 'key infrastructure' > components of the system .. Still shouldn't be much code to change - but someone still has to actually do it. > >And heavy duty, DSP centric applications > >(ie ones with lots of DSP code) probably won't be of much use > >without a GFLOPS class CPU anyway. > >I would think you can compile and run them on just about anything - > >but without proper FP support (that is, an extremely fast integer > >CPU + FP emulation, or "anything" with a proper FPU), they won't > >run fast enough to do anything useful, unless all DSP code is > >translated to integer/fixed point. > > its amazing though, how there are good quality examples of audio/DSP > code which don't require FP .. which do in fact use integer/fixed > point math .. and which function just fine in cheap hardware .. Well, I decided to do it the hard (integer) way in the real time part of Audiality, but as maximum portability was a requirement, I had to do it in pure C - and that's certainly no fun, especially not on compilers without long long support. (MUL and DIV are so much nicer in asm, but AFAIK, no high level languages allow you to make proper use of it. :-/ ) The more interesting part, the modular synth engine (which is to be usable in the real time context in future releases), uses FP, because 1) I didn't have much time for hacking, and I'd rather have it running on FP than not at all, 2) it seems like integer processing is slower than FP on most machines with proper FPUs, 3) at the time, I knew of no integer-only hardware where real time modular synthesis was viable, and 4) most DSP stuff is easier to code in FP anyway, at least as long as you can't throw in some asm. Of course, for maximum scalability (which is a design goal, although not the primary one at this point), it would be best to have both FP and integer versions of everything - and maybe I'll do that eventually. However, the primary target platforms for the stuff I'm working on now is - guess what - x86 and PPC, so I have to focus on getting it to work (and preferably run fast) on those, first. > >I can certainly understand why someone who isn't seriously > >interested in the odd few platforms with enough oomph but no FP, > >would lack the motivation to write and/or maintain code that is > >relevant only on these platforms. > > oh, so can i, for sure.. i mean, if you've taken the easy path once, > no need to consider any other path twice .. except to bemoan the > existence of such other paths, of course .. If you just don't have the proper motivation to hack the code, you won't do it. Goes for everything, whether it's Free/Open Source or commercial. Unless someone needs the software, thinks hacking it would be fun, and/or believes there is money waiting to be made, the code doesn't get written. > regardless, there certainly seems to be potential in the GP2X' lowly > cpu's for interesting audio hacking, and i certainly hope its > acceptable to the cognescenti to recognize this fact, FP or none .. Well, I'm considering getting one, though I'm not totally sure what I'd use it for. (Except plain fun, of course, which is no small part of the whole Free/Open Source thing.) Are there any restrictions WRT which Linux drivers are available? (I'm thinking external USB devices and the like.) Does it support (USB) keyboards and mice? (A foldable rubber keyboard and some sort of tracker-like sequencer could be useful. Or is there a foldable rubber MIDI/USB keyboard out there somewhere?) Another thought: Is there a market for shareware games? (Ports, at least - it'd have to be a rather large market for dedicated game designs to be viable, I think.) //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --' From forums at machinehasnoagenda.com Thu Jan 12 22:49:58 2006 From: forums at machinehasnoagenda.com (Shayne O'Connor) Date: Thu Jan 12 22:50:09 2006 Subject: [linux-audio-dev] [ANN] ninjam with jack support... In-Reply-To: <20060110112725.GA4974@mobilat.informatik.uni-bremen.de> References: <20060110112725.GA4974@mobilat.informatik.uni-bremen.de> Message-ID: <43C72366.10307@machinehasnoagenda.com> torbenh@gmx.de wrote: > hello... i just wanted to announce, that i have written a jack binding > for ninjam. > > ninjam is a network jam session software. > www.ninjam.com > > coolness ... i remember email exchanges with jp mercury (freewheelin) where we dreamed of just this sort of thing ... > the ported consoleclient for ninjam is available here: > > http://galan.sf.net/ninjam-with-jack.tar.bz2 > > and yes... there is a Makefile.. find -name Makefile it... > i just added the jack support... > took me a while to figure out how to build it (i think it already was) ... had to do a "make clean", then "make" > more io ports will follow... > also dont use with too low period sizes, it does not behave so well.. > just did a quick test with it ... had a five minute jam with some dude, and all seemed to go well (didn't do anything fancy, like hooking it into ardour, though). i had a period of 512 in jack, which seemed ok. thanx for the software (xfst, galan, now this), torben ... you (scissors, paper) ROCK! shayne From peppercorn at netspace.net.au Fri Jan 13 06:57:49 2006 From: peppercorn at netspace.net.au (Vaughan Famularo) Date: Fri Jan 13 06:58:22 2006 Subject: [linux-audio-dev] Hello & Help Message-ID: <1137153469.27472.14.camel@studio.kowbouys.org> Hi this is my first post here and I'm hoping you are friendly and understanding to a relative self learner of Linux!! I am a musician first and a computer hacker second. I have learned everyting I know about Linux by stuffing up my computer and learning to refix it via the net and forums such as this one. I have installed Fedora Core 3 and added the ccrma kernels and programs via the how to files on the net. I am SO IMPRESSED with the system that they present. I have so far achieved getting everything running (except midi...more on that in a second) I have even been able to run some VST plugins and programs via FST. I am 3/4 of the way through a song on Ardour and am loving what I am hearing so far and want to continue using Linux as my main form of recording. I have a Hoontech C-Port soundcard succesfully using the ice1712 driver. However "midi in" on this card doesn't work with Alsa. So, I just got a yamaha usb "UX16" midi controller so I can trigger some samples. Here is my problem. The Ux16 shows up in the qjackctrl midi connections gui. BUT nothing appears to be triggered by my exterior keyboard. I have tried everything in my brain but I have finally had to admit defeat. Oh yea I am running the 2.6.11-0.3.rdt.rhfc3.ccrma kernel If anyone can help I'd be much obliged. Thanks in advance. Vaughan From tzahm at punkass.com Fri Jan 13 09:40:45 2006 From: tzahm at punkass.com (Sam Roig) Date: Fri Jan 13 09:40:51 2006 Subject: [linux-audio-dev] synthesis on gp2x .. (was Fwd: RE: [gpx-dev] hardware interfaces) In-Reply-To: <200601130514.56434.david@olofson.net> References: <200601121826.13512.david@olofson.net> <200601130514.56434.david@olofson.net> Message-ID: > Are there any restrictions WRT which Linux drivers are available? (I'm > thinking external USB devices and the like.) Does it support (USB) > keyboards and mice? (A foldable rubber keyboard and some sort of > tracker-like sequencer could be useful. Or is there a foldable rubber > MIDI/USB keyboard out there somewhere?) May your wishes come true: http://www.soundonsound.com/sos/sep05/articles/tahorng.htm -- ::: sam ::: From clemens at ladisch.de Fri Jan 13 10:35:40 2006 From: clemens at ladisch.de (Clemens Ladisch) Date: Fri Jan 13 10:35:48 2006 Subject: [linux-audio-dev] Hello & Help In-Reply-To: <1137153469.27472.14.camel@studio.kowbouys.org> References: <1137153469.27472.14.camel@studio.kowbouys.org> Message-ID: <1137166540.43c7c8cc925e6@webmail.uni-halle.de> Vaughan Famularo wrote: > The Ux16 shows up in the qjackctrl midi connections gui. BUT nothing > appears to be triggered by my exterior keyboard. Do you get anything with "amidi --dump -p ..."? (see "amidi -l" for a list of port names) Regards, Clemens From peppercorn at netspace.net.au Fri Jan 13 12:10:01 2006 From: peppercorn at netspace.net.au (Vaughan Famularo) Date: Fri Jan 13 12:10:35 2006 Subject: [linux-audio-dev] UX16 Message-ID: <1137172201.3827.6.camel@studio.kowbouys.org> Arrrgh!! Thanks Clemens and anyone else that I may have missed, but thankfully I have it going!!!! After sending the last post and walking away for a cuppa I decided to double check some keyboard settings. One of the keyboards panel lights are out and therefore are pretty dim. But no matter what excuse I use I feel pretty dumb and lame having to admit that I overlooked a simple keyboard setting. I wrestled with this thing for 12 hrs and I simply had a setting on my keyboard incorrectly set. Thanks anyway! Vaughan PS. Is there any site where Linux users are posting songs or samples of their songs that they are producing with Linux???? If so where? From a at gaydenko.com Fri Jan 13 16:03:55 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Fri Jan 13 15:57:41 2006 Subject: [linux-audio-dev] one-sample length impulse - HOWTO? Message-ID: <200601140003.55993@goldspace.net> Hi! The aim is to generate audiofile with one/few-sample-length impulse inside silence. Is there suitable software to do the job? Thanks in advance! Andrew From indigo at bitglue.com Fri Jan 13 16:25:23 2006 From: indigo at bitglue.com (Phil Frost) Date: Fri Jan 13 16:26:01 2006 Subject: [linux-audio-dev] one-sample length impulse - HOWTO? In-Reply-To: <200601140003.55993@goldspace.net> References: <200601140003.55993@goldspace.net> Message-ID: <20060113212523.GA22487@unununium.org> On Sat, Jan 14, 2006 at 12:03:55AM +0300, Andrew Gaydenko wrote: > Hi! > > The aim is to generate audiofile with one/few-sample-length impulse inside > silence. Is there suitable software to do the job? > > Thanks in advance! > Andrew You could use your favorite programming language or a hex editor to create a file with some number of binary 1s, then some binary 0s in the desired sample format, then use sox to convert it from raw format to wav or whatever you need. From larsl at users.sourceforge.net Fri Jan 13 16:33:07 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Fri Jan 13 16:32:48 2006 Subject: [linux-audio-dev] one-sample length impulse - HOWTO? In-Reply-To: <200601140003.55993@goldspace.net> References: <200601140003.55993@goldspace.net> Message-ID: <1137187987.8871.1.camel@c213-100-50-8.swipnet.se> On Sat, 2006-01-14 at 00:03 +0300, Andrew Gaydenko wrote: > The aim is to generate audiofile with one/few-sample-length impulse inside > silence. Is there suitable software to do the job? If you don't mind some coding you could probably do it in a few lines using libsndfile. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060113/e6d73d49/attachment.bin From jesse at essej.net Sat Jan 14 02:40:14 2006 From: jesse at essej.net (Jesse Chappell) Date: Sat Jan 14 02:40:19 2006 Subject: [linux-audio-dev] [ANN] ninjam with jack support... In-Reply-To: <43C72366.10307@machinehasnoagenda.com> References: <20060110112725.GA4974@mobilat.informatik.uni-bremen.de> <43C72366.10307@machinehasnoagenda.com> Message-ID: On 1/12/06, Shayne O'Connor wrote: > coolness ... i remember email exchanges with jp mercury (freewheelin) > where we dreamed of just this sort of thing ... Yeah, integrating this with some collaborative loop management/sequencing and we'll really have something. Who's interested? Not sure if the current ninjam codebase could (or should) support this. But after ninjamming for 2 hours tonight, i'm sold on the concept. jlc From jamesmichaelmcdermott at gmail.com Sat Jan 14 09:26:09 2006 From: jamesmichaelmcdermott at gmail.com (James McDermott) Date: Sat Jan 14 09:26:15 2006 Subject: [linux-audio-dev] one-sample length impulse - HOWTO? In-Reply-To: <1137187987.8871.1.camel@c213-100-50-8.swipnet.se> References: <200601140003.55993@goldspace.net> <1137187987.8871.1.camel@c213-100-50-8.swipnet.se> Message-ID: > > The aim is to generate audiofile with one/few-sample-length impulse inside > > silence. Is there suitable software to do the job? If you don't like programming, you can do it in Audacity! Open Audacity and make two tracks. Generate the required length of silence in one, and a *very* short tone (eg a square wave) in the other. Zoom in till you can see the individual samples, and copy-and-paste 1 sample from the square wave into the silence. Good luck, James. From shulmang at colorado.edu Sat Jan 14 14:41:33 2006 From: shulmang at colorado.edu (Garett Shulman) Date: Sat Jan 14 14:45:08 2006 Subject: [linux-audio-dev] timemachine auto recorder patch Message-ID: <43C953ED.9000605@colorado.edu> Hello, I have created a patch that allows timeachine to automatically start and stop recording based on the audio signal. Recording will start when a sample value exceeds a start threashold. Recording stops when sample values remain below a stop threashold for a period of time. Recording of a new file will then start again when a sample value again exceeds the start threashold. These values as well as enabeling auto recording can all be set at the command line. With this functionallity I would like to be able to launch timemachine backgrounded. Eg: timemachine args & I would also need to be able to send the process SIGINT and SIGTERM signals and have it exit gracefully. I have attempted to add the necessary handlers for this. However if I try to start timemachine backgrounded it just seems to exit and brings jack down with it. If I run it in the foreground and try to killall timemachine it does not exit gracefully but brings jack down as well. In either case I see output from jack like: subgraph starting at time timed out (subgraph_wait_fd = 7, status = 0, state = Triggered) jackd watchdog: timeout - killed jack [1]+ Killed timemachine Any suggestions or ideas are greatly appreciated. Also, the auto recorder functionallity works great asside from the backgrounding and SIGTERM business. Thanks! -Garett PATCH FOLLOWS diff -urN timemachine-0.3.1/src/main.c timemachine-0.3.1.autorecord/src/main.c --- timemachine-0.3.1/src/main.c 2005-09-19 03:41:30.000000000 -0600 +++ timemachine-0.3.1.autorecord/src/main.c 2006-01-14 11:24:13.000000000 -0700 @@ -28,6 +28,10 @@ #include #include +/* garetts mod here */ +#include +/* end garetts mod */ + #ifdef HAVE_LASH #include @@ -71,6 +75,10 @@ GdkPixbuf *img_on, *img_off, *img_busy; GdkPixbuf *icon_on, *icon_off; +/* garetts mod here */ +void signal_handler(int signal); +/* end garetts mod */ + int main(int argc, char *argv[]) { unsigned int i; @@ -78,13 +86,22 @@ int help = 0; int console = 0; char port_name[32]; + /* garetts mod here */ + int AUTO_RECORD = 0; + signal(SIGINT, signal_handler); + signal(SIGTERM, signal_handler); + float SECONDS_OF_SILENCE_BEFORE_STOP = 5; + float START_THREASHOLD = 0.000005; + float STOP_THREASHOLD = 0; + /* end garetts mod */ + pthread_t dt; #ifdef HAVE_LASH lash_args_t *lash_args = lash_extract_args(&argc, &argv); lash_event_t *event; #endif - while ((opt = getopt(argc, argv, "hic:t:n:p:f:")) != -1) { + while ((opt = getopt(argc, argv, "hic:t:n:p:f:q:w:e:r")) != -1) { switch (opt) { case 'h': help = 1; @@ -111,6 +128,20 @@ case 'f': format_name = optarg; break; + /* garetts mod here */ + case 'q': + SECONDS_OF_SILENCE_BEFORE_STOP = atof(optarg); + break; + case 'w': + START_THREASHOLD = atof(optarg); + break; + case 'e': + STOP_THREASHOLD = atof(optarg); + break; + case 'r': + AUTO_RECORD = 1; + break; + /* end garetts mod */ default: num_ports = 0; break; @@ -132,6 +163,9 @@ fprintf(stderr, "\t-t\tspecify the pre-recording buffer length\n"); fprintf(stderr, "\t-p\tspecify the saved file prefix, may include path\n"); fprintf(stderr, "\t-f\tspecify the saved file format\n"); + fprintf(stderr, "\t-q\tspecify the seconds of silence before stop\n"); + fprintf(stderr, "\t-w\tspecify the start threashold\n"); + fprintf(stderr, "\t-e\tspecify the stop threashold\n"); fprintf(stderr, "\n"); fprintf(stderr, "\tchannels must be in the range 1-8, default %d\n", DEFAULT_NUM_PORTS); @@ -164,7 +198,10 @@ } DEBUG(1, "registering as %s\n", client_name); - process_init(buf_length); + /* garetts mod here + * process_init(buf_length) + */ + process_init(buf_length, SECONDS_OF_SILENCE_BEFORE_STOP, START_THREASHOLD, STOP_THREASHOLD, AUTO_RECORD); #ifdef HAVE_LASH lash_client = lash_init (lash_args, "TimeMachine", @@ -287,6 +324,11 @@ exit(0); } +void signal_handler(int iSignal) { + recording_stop(); + cleanup(); +} + #ifdef HAVE_LASH gboolean idle_cb(gpointer data) { diff -urN timemachine-0.3.1/src/threads.c timemachine-0.3.1.autorecord/src/threads.c --- timemachine-0.3.1/src/threads.c 2005-07-18 08:03:06.000000000 -0600 +++ timemachine-0.3.1.autorecord/src/threads.c 2006-01-14 10:58:18.000000000 -0700 @@ -19,7 +19,7 @@ #include #include #include -#include +#include #include #include #include @@ -46,6 +46,15 @@ static unsigned int disk_read_pos = 0; static unsigned int disk_write_pos = 0; +/* garetts mod here */ +static float seconds_of_silence_before_stop = 0; +static float start_threashold = 0; +static float stop_threashold = 0; +static float seconds_of_silence = 0; +static int sample_rate = 0; +static int autorecord = 0; +/* end garetts mod */ + /* Peak data for meters */ static volatile float peak[MAX_PORTS]; @@ -69,6 +78,32 @@ fprintf(stderr, "bad buffer!\n"); break; } + + /* garetts mod here */ + if (autorecord) { + if (rec) { + for (i = 0; i < nframes; i++) { + if (fabsf(in[i]) <= stop_threashold) { + seconds_of_silence = seconds_of_silence + 1.0/sample_rate; + } + else { + seconds_of_silence = 0; + } + if (seconds_of_silence > seconds_of_silence_before_stop) { + recording_stop(); + } + } + } + else { + for (i = 0; i < nframes; i++) { + if (fabsf(in[i]) > start_threashold) { + recording_start(); + break; + } + } + } + } + /* end garetts mod */ for (i = 0; i < nframes; i++) { if (fabsf(in[i]) > peak[port]) { @@ -202,7 +236,10 @@ return 0; } -void process_init(unsigned int time) +/* garetts mod here + * void process_init(unsigned int time) + */ +void process_init(unsigned int time, float secs_of_silence_before_stop, float strt_threashold, float stp_threashold, int use_autorecord) { unsigned int port; @@ -220,6 +257,14 @@ pre_size = time * jack_get_sample_rate(client); pre_time = time; + /* garetts mod here */ + seconds_of_silence_before_stop = secs_of_silence_before_stop; + start_threashold = strt_threashold; + stop_threashold = stp_threashold; + sample_rate = jack_get_sample_rate(client); + autorecord = use_autorecord; + /* end garetts mod */ + for (port = 0; port < num_ports; port++) { pre_buffer[port] = calloc(pre_size, sizeof(float)); disk_buffer[port] = calloc(DISK_SIZE, sizeof(float)); diff -urN timemachine-0.3.1/src/threads.h timemachine-0.3.1.autorecord/src/threads.h --- timemachine-0.3.1/src/threads.h 2005-07-18 08:03:06.000000000 -0600 +++ timemachine-0.3.1.autorecord/src/threads.h 2006-01-14 10:56:37.000000000 -0700 @@ -9,7 +9,10 @@ int process(jack_nframes_t nframes, void *arg); -void process_init(unsigned int time); +/* garetts mod here + * void process_init(unsigned int time) + */ +void process_init(unsigned int time, float secs_of_silence_before_stop, float strt_threashold, float stp_threashold, int use_autorecord); int writer_thread(void *d); From S.W.Harris at ecs.soton.ac.uk Sat Jan 14 15:56:43 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Jan 14 15:57:15 2006 Subject: [linux-audio-dev] timemachine auto recorder patch In-Reply-To: <43C953ED.9000605@colorado.edu> References: <43C953ED.9000605@colorado.edu> Message-ID: <20060114205643.GB12232@login.ecs.soton.ac.uk> On Sat, Jan 14, 2006 at 12:41:33 -0700, Garett Shulman wrote: > Hello, I have created a patch that allows timeachine to automatically > start and stop recording based on the audio signal. Recording will start > when a sample value exceeds a start threashold. Recording stops when > sample values remain below a stop threashold for a period of time. Nice. > However if I try to start timemachine backgrounded it just seems to exit > and brings jack down with it. If I run it in the foreground and try to > killall timemachine it does not exit gracefully but brings jack down as > well. In either case I see output from jack like: > > subgraph starting at time timed out (subgraph_wait_fd = 7, status = 0, > state = Triggered) > jackd watchdog: timeout - killed jack > [1]+ Killed timemachine Try adding an atexit(3) handler that exits from the jack graph. Timemachine should not be able to bring down jack, so that is probably a bug in jack, though it might well be triggered by a bug in timemachine. I can't think of any reasons why timemachine might not like being backgrounded offhand. > +/* garetts mod here */ You might want to stop this, the ChangeLog + CVS stuff can represent this in a more programmer friendly way. I everyone did that youd never be able to read the code ;) - Steve From shulmang at colorado.edu Sat Jan 14 17:18:43 2006 From: shulmang at colorado.edu (Garett Shulman) Date: Sat Jan 14 17:22:13 2006 Subject: [linux-audio-dev] timemachine auto recorder patch In-Reply-To: <20060114205643.GB12232@login.ecs.soton.ac.uk> References: <43C953ED.9000605@colorado.edu> <20060114205643.GB12232@login.ecs.soton.ac.uk> Message-ID: <43C978C3.9040007@colorado.edu> Steve Harris wrote: >On Sat, Jan 14, 2006 at 12:41:33 -0700, Garett Shulman wrote: > > >>Hello, I have created a patch that allows timeachine to automatically >>start and stop recording based on the audio signal. Recording will start >>when a sample value exceeds a start threashold. Recording stops when >>sample values remain below a stop threashold for a period of time. >> >> > >Nice. > > > >>However if I try to start timemachine backgrounded it just seems to exit >>and brings jack down with it. If I run it in the foreground and try to >>killall timemachine it does not exit gracefully but brings jack down as >>well. In either case I see output from jack like: >> >>subgraph starting at time timed out (subgraph_wait_fd = 7, status = 0, >>state = Triggered) >>jackd watchdog: timeout - killed jack >>[1]+ Killed timemachine >> >> > >Try adding an atexit(3) handler that exits from the jack graph. >Timemachine should not be able to bring down jack, so that is probably a >bug in jack, though it might well be triggered by a bug in timemachine. > >I can't think of any reasons why timemachine might not like being >backgrounded offhand. > > > >>+/* garetts mod here */ >> >> > >You might want to stop this, the ChangeLog + CVS stuff can represent >this in a more programmer friendly way. I everyone did that youd never >be able to read the code ;) > > > Thanks for the tip. That's mostly a hacking aid. Guess I shouldn've pulled those out of the patch. >- Steve > > From ce at christeck.de Sat Jan 14 17:33:23 2006 From: ce at christeck.de (Christoph Eckert) Date: Sat Jan 14 17:31:33 2006 Subject: [linux-audio-dev] timemachine auto recorder patch In-Reply-To: <43C953ED.9000605@colorado.edu> References: <43C953ED.9000605@colorado.edu> Message-ID: <200601142333.24362.ce@christeck.de> Hi, > Hello, I have created a patch that allows timeachine to automatically > start and stop recording based on the audio signal. sounds cool. As there is some development: any chance to get the command line options read from a config file like ~/timemachinerc :) ? At least the options -f, -t and -p would be really cool to have in a config file. Best regards ce From fbar at footils.org Sat Jan 14 18:19:51 2006 From: fbar at footils.org (Frank Barknecht) Date: Sat Jan 14 18:19:46 2006 Subject: [linux-audio-dev] one-sample length impulse - HOWTO? In-Reply-To: <200601140003.55993@goldspace.net> References: <200601140003.55993@goldspace.net> Message-ID: <20060114231951.GC24555@fliwatut.scifi> Hallo, Andrew Gaydenko hat gesagt: // Andrew Gaydenko wrote: > The aim is to generate audiofile with one/few-sample-length impulse inside > silence. Is there suitable software to do the job? Many. Attached is a patch to do this in Pd. Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ -------------- next part -------------- #N canvas 423 345 510 509 10; #X msg 127 84 const 0 \, 0 1; #X obj 127 62 loadbang; #X obj 125 447 dac~; #X text 122 34 Generate a table with 1 one and 511 zeroes; #X text 125 324 Play it for example like this:; #X floatatom 126 346 5 0 0 0 freq - -; #X obj 126 391 *~ 512; #X obj 121 276 soundfiler; #X obj 127 112 s imp; #X obj 128 139 table imp 512; #X obj 125 416 tabread~ imp; #X obj 126 367 phasor~ 0; #X msg 121 253 write -wave \$1 imp; #X obj 121 231 savepanel; #X obj 121 209 b; #X msg 121 189 save it somewhere; #X text 239 82 set zero \, then write 1 at pos 0; #X connect 0 0 8 0; #X connect 1 0 0 0; #X connect 5 0 11 0; #X connect 6 0 10 0; #X connect 10 0 2 0; #X connect 10 0 2 1; #X connect 11 0 6 0; #X connect 12 0 7 0; #X connect 13 0 12 0; #X connect 14 0 13 0; #X connect 15 0 14 0; From shulmang at colorado.edu Sat Jan 14 18:27:35 2006 From: shulmang at colorado.edu (Garett Shulman) Date: Sat Jan 14 18:31:03 2006 Subject: [linux-audio-dev] timemachine auto recorder patch In-Reply-To: <200601142333.24362.ce@christeck.de> References: <43C953ED.9000605@colorado.edu> <200601142333.24362.ce@christeck.de> Message-ID: <43C988E7.4050005@colorado.edu> Christoph Eckert wrote: >Hi, > > > > >>Hello, I have created a patch that allows timeachine to automatically >>start and stop recording based on the audio signal. >> >> > >sounds cool. > >As there is some development: any chance to get the command line options >read from a config file like ~/timemachinerc :) ? > >At least the options -f, -t and -p would be really cool to have in a >config file. > > > In lieu of this getting implamented I would just use a shell script. >Best regards > > >ce > > From ce at christeck.de Sat Jan 14 18:41:55 2006 From: ce at christeck.de (Christoph Eckert) Date: Sat Jan 14 18:40:04 2006 Subject: [linux-audio-dev] timemachine auto recorder patch In-Reply-To: <43C988E7.4050005@colorado.edu> References: <43C953ED.9000605@colorado.edu> <200601142333.24362.ce@christeck.de> <43C988E7.4050005@colorado.edu> Message-ID: <200601150041.55976.ce@christeck.de> > In lieu of this getting implamented I would just use a shell script. I already do :) . Best regards ce From hans at fugal.net Sat Jan 14 19:50:22 2006 From: hans at fugal.net (Hans Fugal) Date: Sat Jan 14 19:50:39 2006 Subject: [linux-audio-dev] timemachine auto recorder patch In-Reply-To: <43C953ED.9000605@colorado.edu> References: <43C953ED.9000605@colorado.edu> Message-ID: <20060115005022.GA7825@falcon.fugal.net> FWIW I've never had issues running timemachine in the background. On Sat, 14 Jan 2006 at 12:41 -0700, Garett Shulman wrote: > Hello, I have created a patch that allows timeachine to automatically > start and stop recording based on the audio signal. Recording will start > when a sample value exceeds a start threashold. Recording stops when > sample values remain below a stop threashold for a period of time. > Recording of a new file will then start again when a sample value again > exceeds the start threashold. These values as well as enabeling auto > recording can all be set at the command line. > > With this functionallity I would like to be able to launch timemachine > backgrounded. > Eg: timemachine args & > I would also need to be able to send the process SIGINT and SIGTERM > signals and have it exit gracefully. I have attempted to add the > necessary handlers for this. > > However if I try to start timemachine backgrounded it just seems to exit > and brings jack down with it. If I run it in the foreground and try to > killall timemachine it does not exit gracefully but brings jack down as > well. In either case I see output from jack like: > > subgraph starting at time timed out (subgraph_wait_fd = 7, status = 0, > state = Triggered) > jackd watchdog: timeout - killed jack > [1]+ Killed timemachine > > Any suggestions or ideas are greatly appreciated. Also, the auto > recorder functionallity works great asside from the backgrounding and > SIGTERM business. > > Thanks! > -Garett > > PATCH FOLLOWS > diff -urN timemachine-0.3.1/src/main.c > timemachine-0.3.1.autorecord/src/main.c > --- timemachine-0.3.1/src/main.c 2005-09-19 03:41:30.000000000 -0600 > +++ timemachine-0.3.1.autorecord/src/main.c 2006-01-14 > 11:24:13.000000000 -0700 > @@ -28,6 +28,10 @@ > #include > #include > > +/* garetts mod here */ > +#include > +/* end garetts mod */ > + > #ifdef HAVE_LASH > #include > > @@ -71,6 +75,10 @@ > GdkPixbuf *img_on, *img_off, *img_busy; > GdkPixbuf *icon_on, *icon_off; > > +/* garetts mod here */ > +void signal_handler(int signal); > +/* end garetts mod */ > + > int main(int argc, char *argv[]) > { > unsigned int i; > @@ -78,13 +86,22 @@ > int help = 0; > int console = 0; > char port_name[32]; > + /* garetts mod here */ > + int AUTO_RECORD = 0; > + signal(SIGINT, signal_handler); > + signal(SIGTERM, signal_handler); > + float SECONDS_OF_SILENCE_BEFORE_STOP = 5; > + float START_THREASHOLD = 0.000005; > + float STOP_THREASHOLD = 0; > + /* end garetts mod */ > + > pthread_t dt; > #ifdef HAVE_LASH > lash_args_t *lash_args = lash_extract_args(&argc, &argv); > lash_event_t *event; > #endif > > - while ((opt = getopt(argc, argv, "hic:t:n:p:f:")) != -1) { > + while ((opt = getopt(argc, argv, "hic:t:n:p:f:q:w:e:r")) != -1) { > switch (opt) { > case 'h': > help = 1; > @@ -111,6 +128,20 @@ > case 'f': > format_name = optarg; > break; > + /* garetts mod here */ > + case 'q': > + SECONDS_OF_SILENCE_BEFORE_STOP = atof(optarg); > + break; > + case 'w': > + START_THREASHOLD = atof(optarg); > + break; > + case 'e': > + STOP_THREASHOLD = atof(optarg); > + break; > + case 'r': > + AUTO_RECORD = 1; > + break; > + /* end garetts mod */ > default: > num_ports = 0; > break; > @@ -132,6 +163,9 @@ > fprintf(stderr, "\t-t\tspecify the pre-recording buffer length\n"); > fprintf(stderr, "\t-p\tspecify the saved file prefix, may include > path\n"); > fprintf(stderr, "\t-f\tspecify the saved file format\n"); > + fprintf(stderr, "\t-q\tspecify the seconds of silence before stop\n"); > + fprintf(stderr, "\t-w\tspecify the start threashold\n"); > + fprintf(stderr, "\t-e\tspecify the stop threashold\n"); > fprintf(stderr, "\n"); > fprintf(stderr, "\tchannels must be in the range 1-8, default %d\n", > DEFAULT_NUM_PORTS); > @@ -164,7 +198,10 @@ > } > DEBUG(1, "registering as %s\n", client_name); > > - process_init(buf_length); > + /* garetts mod here > + * process_init(buf_length) > + */ > + process_init(buf_length, SECONDS_OF_SILENCE_BEFORE_STOP, > START_THREASHOLD, STOP_THREASHOLD, AUTO_RECORD); > > #ifdef HAVE_LASH > lash_client = lash_init (lash_args, "TimeMachine", > @@ -287,6 +324,11 @@ > exit(0); > } > > +void signal_handler(int iSignal) { > + recording_stop(); > + cleanup(); > +} > + > #ifdef HAVE_LASH > gboolean idle_cb(gpointer data) > { > diff -urN timemachine-0.3.1/src/threads.c > timemachine-0.3.1.autorecord/src/threads.c > --- timemachine-0.3.1/src/threads.c 2005-07-18 08:03:06.000000000 -0600 > +++ timemachine-0.3.1.autorecord/src/threads.c 2006-01-14 > 10:58:18.000000000 -0700 > @@ -19,7 +19,7 @@ > #include > #include > #include > -#include > +#include > #include > #include > #include > @@ -46,6 +46,15 @@ > static unsigned int disk_read_pos = 0; > static unsigned int disk_write_pos = 0; > > +/* garetts mod here */ > +static float seconds_of_silence_before_stop = 0; > +static float start_threashold = 0; > +static float stop_threashold = 0; > +static float seconds_of_silence = 0; > +static int sample_rate = 0; > +static int autorecord = 0; > +/* end garetts mod */ > + > /* Peak data for meters */ > static volatile float peak[MAX_PORTS]; > > @@ -69,6 +78,32 @@ > fprintf(stderr, "bad buffer!\n"); > break; > } > + > + /* garetts mod here */ > + if (autorecord) { > + if (rec) { > + for (i = 0; i < nframes; i++) { > + if (fabsf(in[i]) <= stop_threashold) { > + seconds_of_silence = seconds_of_silence + 1.0/sample_rate; > + } > + else { > + seconds_of_silence = 0; > + } > + if (seconds_of_silence > seconds_of_silence_before_stop) { > + recording_stop(); > + } > + } > + } > + else { > + for (i = 0; i < nframes; i++) { > + if (fabsf(in[i]) > start_threashold) { > + recording_start(); > + break; > + } > + } > + } > + } > + /* end garetts mod */ > > for (i = 0; i < nframes; i++) { > if (fabsf(in[i]) > peak[port]) { > @@ -202,7 +236,10 @@ > return 0; > } > > -void process_init(unsigned int time) > +/* garetts mod here > + * void process_init(unsigned int time) > + */ > +void process_init(unsigned int time, float secs_of_silence_before_stop, > float strt_threashold, float stp_threashold, int use_autorecord) > { > unsigned int port; > > @@ -220,6 +257,14 @@ > pre_size = time * jack_get_sample_rate(client); > pre_time = time; > > + /* garetts mod here */ > + seconds_of_silence_before_stop = secs_of_silence_before_stop; > + start_threashold = strt_threashold; > + stop_threashold = stp_threashold; > + sample_rate = jack_get_sample_rate(client); > + autorecord = use_autorecord; > + /* end garetts mod */ > + > for (port = 0; port < num_ports; port++) { > pre_buffer[port] = calloc(pre_size, sizeof(float)); > disk_buffer[port] = calloc(DISK_SIZE, sizeof(float)); > diff -urN timemachine-0.3.1/src/threads.h > timemachine-0.3.1.autorecord/src/threads.h > --- timemachine-0.3.1/src/threads.h 2005-07-18 08:03:06.000000000 -0600 > +++ timemachine-0.3.1.autorecord/src/threads.h 2006-01-14 > 10:56:37.000000000 -0700 > @@ -9,7 +9,10 @@ > > int process(jack_nframes_t nframes, void *arg); > > -void process_init(unsigned int time); > +/* garetts mod here > + * void process_init(unsigned int time) > + */ > +void process_init(unsigned int time, float secs_of_silence_before_stop, > float strt_threashold, float stp_threashold, int use_autorecord); > > int writer_thread(void *d); > > -- Hans Fugal ; http://hans.fugal.net There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- Johann Sebastian Bach -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060114/d106a05b/attachment.bin From hans at fugal.net Sat Jan 14 20:21:24 2006 From: hans at fugal.net (Hans Fugal) Date: Sat Jan 14 20:21:33 2006 Subject: [linux-audio-dev] detune Message-ID: <20060115012124.GB7825@falcon.fugal.net> I'm about to write a DSSI/LADSPA plugin that among other things, detunes the signal by up to 15 cents. My understanding is that detuning is accomplished by resampling. If that's the case, what do you do with the time difference? Do you pad/truncate to get the same number of samples you started out with? Wouldn't that introduce undesirables? -- Hans Fugal ; http://hans.fugal.net There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- Johann Sebastian Bach -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060114/e313408f/attachment.bin From jens.andreasen at chello.se Sat Jan 14 20:42:55 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sat Jan 14 20:43:01 2006 Subject: [linux-audio-dev] detune In-Reply-To: <20060115012124.GB7825@falcon.fugal.net> References: <20060115012124.GB7825@falcon.fugal.net> Message-ID: <1137289375.9411.8.camel@c80-216-124-251.cm-upc.chello.se> On Sat, 2006-01-14 at 18:21 -0700, Hans Fugal wrote: > I'm about to write a DSSI/LADSPA plugin that among other things, detunes > the signal by up to 15 cents. My understanding is that detuning is > accomplished by resampling. If that's the case, what do you do > with the time difference? Do you pad/truncate to get the same number of > samples you started out with? Wouldn't that introduce undesirables? > Ehrmm ... perhaps I misunderstand you, but the art of resampling is all about keeping undesireable results at a minimum. If you stretch your input, you'll end up with more samples ... But hey ... Could you rephrase the question? -- From hans at fugal.net Sat Jan 14 21:18:23 2006 From: hans at fugal.net (Hans Fugal) Date: Sat Jan 14 21:18:32 2006 Subject: [linux-audio-dev] detune In-Reply-To: <1137289375.9411.8.camel@c80-216-124-251.cm-upc.chello.se> References: <20060115012124.GB7825@falcon.fugal.net> <1137289375.9411.8.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <20060115021823.GA10058@falcon.fugal.net> On Sun, 15 Jan 2006 at 02:42 +0100, Jens M Andreasen wrote: > On Sat, 2006-01-14 at 18:21 -0700, Hans Fugal wrote: > > I'm about to write a DSSI/LADSPA plugin that among other things, detunes > > the signal by up to 15 cents. My understanding is that detuning is > > accomplished by resampling. If that's the case, what do you do > > with the time difference? Do you pad/truncate to get the same number of > > samples you started out with? Wouldn't that introduce undesirables? > > > > Ehrmm ... perhaps I misunderstand you, but the art of resampling is all > about keeping undesireable results at a minimum. > > If you stretch your input, you'll end up with more samples ... > But hey ... Could you rephrase the question? Happy to. I have no doubt that the resampling part will go smoothly, just to clarify. Unless I'm wrong (in which case I'd like to know), resampling necessarily involves changing the duration if it's played back at the original sample rate. In big numbers, when I resample 1 second of 44.1KHz audio to 22050Hz, I end up with 22050 samples. That means one second of 22050Hz audio, or 1/2 second of 44.1KHz audio. This plugin will take as input a block of n samples and return n samples, but if downsampling reduces the number of samples, what am I to do with the extra time? When we're only talking a few cents, there won't be a lot of samples, but can't even a few 0s result in clicks? You mentioned stretching, perhaps that's the solution. Is it better to stretch to the original size after resampling, or to prestretch and then resample? If I've got pitch detuning all wrong, I'd like to know that too. :-) -- Hans Fugal ; http://hans.fugal.net There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- Johann Sebastian Bach -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060114/824211d3/attachment.bin From tim at quitte.de Sat Jan 14 21:20:56 2006 From: tim at quitte.de (Tim Goetze) Date: Sat Jan 14 21:23:52 2006 Subject: [linux-audio-dev] detune In-Reply-To: <20060115012124.GB7825@falcon.fugal.net> References: <20060115012124.GB7825@falcon.fugal.net> Message-ID: [Hans Fugal] >I'm about to write a DSSI/LADSPA plugin that among other things, detunes >the signal by up to 15 cents. My understanding is that detuning is >accomplished by resampling. If that's the case, what do you do >with the time difference? Do you pad/truncate to get the same number of >samples you started out with? Wouldn't that introduce undesirables? It would. As far as I know, there are two common ways to do this: You can periodically window and granulate the signal, resample the grains and resynthesize -- that's the faster way, doing it all in the time domain. You'll get some comb filtering from the time-stretched phase cancelling out during grain overlap, but if you're only doing 15 cent, it might turn out just fine. There's a library out there that does this, I can't seem to remember its name though. Anyone? The other way I know of is to use a phase vocoder. Basically, you periodically window and granulate and then FFT the signal, do a bit of math on the frequency content and resynthesize. The phase vocoder keeps track of signal phase so the comb filtering effect is no issue. The downside is the FFT and the math required to compute phase and amplitude; it's quite a bit heavier on the CPU. Some code that does it this way is at quitte.de/dsp/pvoc.html but for your intended use I'd first look at the simpler solution mentioned above. And of course source code to these: $ locate pitch|grep ladspa /usr/lib/ladspa/am_pitchshift_1433.so /usr/lib/ladspa/pitch_scale_1193.so /usr/lib/ladspa/pitch_scale_1194.so /usr/lib/ladspa/tap_pitch.so should be easily obtainable. :) Cheers, Tim From peppercorn at netspace.net.au Sun Jan 15 03:27:55 2006 From: peppercorn at netspace.net.au (Vaughan Famularo) Date: Sun Jan 15 03:28:25 2006 Subject: [linux-audio-dev] hi Message-ID: <1137313675.30340.3.camel@studio.kowbouys.org> Hi guys After reading the last few days postings, it is obvious that this list is WAY OVER MY HEAD techwise. You are obviously developers!! Hence the name of the mailing list. Sorry I missed that! The thing is where can I get everyday info about triggering samples or the program to use to do it etc.???? These type of questions are obviously beneath where your heads are operating. So, can someone humble themselves for a moment and give me some ideas regarding the above forementioned?? Thaks in anticipation Vaughan From bengan at sunet.se Sun Jan 15 03:34:44 2006 From: bengan at sunet.se (Bengt =?iso-8859-1?B?R/ZyZOlu?=) Date: Sun Jan 15 03:33:49 2006 Subject: [linux-audio-dev] hi In-Reply-To: <1137313675.30340.3.camel@studio.kowbouys.org> References: <1137313675.30340.3.camel@studio.kowbouys.org> Message-ID: <20060115083444.GA9794@sunet.se> On Sun, Jan 15, 2006 at 06:27:55PM +1000, Vaughan Famularo wrote: > Hi guys > > After reading the last few days postings, it is obvious that this list > is WAY OVER MY HEAD techwise. You are obviously developers!! Hence the > name of the mailing list. Sorry I missed that! > > The thing is where can I get everyday info about triggering samples or > the program to use to do it etc.???? > These type of questions are obviously beneath where your heads are > operating. > So, can someone humble themselves for a moment and give me some ideas > regarding the above forementioned?? That would be LAU. http://music.columbia.edu/mailman/listinfo/linux-audio-user regards, - Bengan ------------------------------------------------------------- - KTHNOC/SUNET/NORDUnet | http://www.noc.kth.se/~bengan | 08-7906586 - From krampenschiesser at freenet.de Sun Jan 15 04:46:14 2006 From: krampenschiesser at freenet.de (krampenschiesser@freenet.de) Date: Sun Jan 15 04:46:21 2006 Subject: [linux-audio-dev] A sequencer example Message-ID: <20060115104614.2fe95591.krampenschiesser@freenet.de> Does someone have a very simple sequencer example? Something sending one note in 4/4? I don't get along with the timing of the alsa sequencer. I hope you can help me. Scar -- All the evidence concerning the universe has not yet been collected, so there's still hope. From fons.adriaensen at skynet.be Sun Jan 15 06:04:40 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sun Jan 15 05:58:52 2006 Subject: [linux-audio-dev] detune In-Reply-To: References: <20060115012124.GB7825@falcon.fugal.net> Message-ID: <20060115110440.GA4956@linux-1> On Sun, Jan 15, 2006 at 03:20:56AM +0100, Tim Goetze wrote: > You can periodically window and granulate the signal, resample the > grains and resynthesize -- that's the faster way, doing it all in the > time domain. You'll get some comb filtering from the time-stretched > phase cancelling out during grain overlap, but if you're only doing 15 > cent, it might turn out just fine. Randomising the grain positions a bit gets rid of the comb filtering. It may introduce new artefacts, but these are often 'nice'. -- FA From mista.tapas at gmx.net Sun Jan 15 06:12:11 2006 From: mista.tapas at gmx.net (Florian Schmidt) Date: Sun Jan 15 06:12:18 2006 Subject: [linux-audio-dev] A sequencer example In-Reply-To: <20060115104614.2fe95591.krampenschiesser@freenet.de> References: <20060115104614.2fe95591.krampenschiesser@freenet.de> Message-ID: <20060115121211.5e02df9f@mango.fruits.de> On Sun, 15 Jan 2006 10:46:14 +0100 krampenschiesser@freenet.de wrote: > Does someone have a very simple sequencer example? > Something sending one note in 4/4? > I don't get along with the timing of the alsa sequencer. > I hope you can help me. > Scar Hi, i don't know whether you want to send midi events directly or schedule them via alsa_seq. If the former case have a look at my small test programs in this tarball http://affenbande.org/~tapas/midi_timer-1.tgz There's two programs in that tarball, one using the RTC for timing and the other using the system timer and usleep() (the RTC based one does achieve better accuracy). Both programs simply try to send a stream of note-on events at very regular intervals. If you want to use alsa_seq's queues to schedule events for delivery at a later time, you probably might have a look at rosegarden. Have fun, Flo -- Palimm Palimm! http://tapas.affenbande.org From cannam at all-day-breakfast.com Sun Jan 15 06:24:26 2006 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Sun Jan 15 06:20:08 2006 Subject: [linux-audio-dev] A sequencer example In-Reply-To: <20060115121211.5e02df9f@mango.fruits.de> References: <20060115104614.2fe95591.krampenschiesser@freenet.de> <20060115121211.5e02df9f@mango.fruits.de> Message-ID: <200601151124.26805.cannam@all-day-breakfast.com> On Sunday 15 Jan 2006 11:12, Florian Schmidt wrote: > If you want to use alsa_seq's queues to schedule events for delivery > at a later time, you probably might have a look at rosegarden. There's a file base/test/seq/generator.c in the Rosegarden source tree that does basically what was described using the sequencer queue. It does however schedule in real-time rather than beats (and so does Rosegarden itself). http://cvs.sourceforge.net/viewcvs.py/rosegarden/base/test/seq/generator.c?view=markup Chris From brinkman at math.TU-Berlin.DE Sun Jan 15 07:19:08 2006 From: brinkman at math.TU-Berlin.DE (Peter Brinkmann) Date: Sun Jan 15 07:19:15 2006 Subject: [linux-audio-dev] A sequencer example In-Reply-To: <20060115104614.2fe95591.krampenschiesser@freenet.de> References: <20060115104614.2fe95591.krampenschiesser@freenet.de> Message-ID: <20060115121908.GA7843@fuchs.math.tu-berlin.de> On Sun, Jan 15, 2006 at 10:46:14AM +0100, krampenschiesser@freenet.de wrote: > Does someone have a very simple sequencer example? > Something sending one note in 4/4? > I don't get along with the timing of the alsa sequencer. > I hope you can help me. > Scar I learned this stuff by staring at Matthias Nagorni's miniArp. You can find it at http://www.suse.com/~mana/miniArp.c. Hope this helps, Peter From mlang at delysid.org Sun Jan 15 08:23:08 2006 From: mlang at delysid.org (mlang) Date: Sun Jan 15 08:22:31 2006 Subject: [linux-audio-dev] A sequencer example In-Reply-To: <200601151124.26805.cannam@all-day-breakfast.com> (Chris Cannam's message of "Sun, 15 Jan 2006 11:24:26 +0000") References: <20060115104614.2fe95591.krampenschiesser@freenet.de> <20060115121211.5e02df9f@mango.fruits.de> <200601151124.26805.cannam@all-day-breakfast.com> Message-ID: <87fynpr5fn.fsf@x2.delysid.org> Chris Cannam writes: > On Sunday 15 Jan 2006 11:12, Florian Schmidt wrote: >> If you want to use alsa_seq's queues to schedule events for delivery >> at a later time, you probably might have a look at rosegarden. > > There's a file base/test/seq/generator.c in the Rosegarden source tree > that does basically what was described using the sequencer queue. It > does however schedule in real-time rather than beats (and so does > Rosegarden itself). > > http://cvs.sourceforge.net/viewcvs.py/rosegarden/base/test/seq/generator.c?view=markup Pretty intersting, I just ran this and noticed it (the diff between queue and gettimeofday time) drifts about 70 usecs per second. Is this normal expected behaviour, or another reason to hate the day I decided to buy a X2 CPU? P.S.: ANyone got any hard facts on the TSC SMP issues? 2.6.15 is definitely worse for me than 2.6.14, things that used to work just dont anymore. -- CYa, Mario From rlrevell at joe-job.com Sun Jan 15 08:47:58 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sun Jan 15 08:48:04 2006 Subject: [linux-audio-dev] A sequencer example In-Reply-To: <87fynpr5fn.fsf@x2.delysid.org> References: <20060115104614.2fe95591.krampenschiesser@freenet.de> <20060115121211.5e02df9f@mango.fruits.de> <200601151124.26805.cannam@all-day-breakfast.com> <87fynpr5fn.fsf@x2.delysid.org> Message-ID: <1137332879.25801.12.camel@mindpipe> On Sun, 2006-01-15 at 14:23 +0100, mlang wrote: > Chris Cannam writes: > > > On Sunday 15 Jan 2006 11:12, Florian Schmidt wrote: > >> If you want to use alsa_seq's queues to schedule events for delivery > >> at a later time, you probably might have a look at rosegarden. > > > > There's a file base/test/seq/generator.c in the Rosegarden source tree > > that does basically what was described using the sequencer queue. It > > does however schedule in real-time rather than beats (and so does > > Rosegarden itself). > > > > http://cvs.sourceforge.net/viewcvs.py/rosegarden/base/test/seq/generator.c?view=markup > > Pretty intersting, I just ran this and noticed it (the diff between > queue and gettimeofday time) drifts about 70 usecs per second. Is this > normal expected behaviour, or another reason to hate the day I decided to buy > a X2 CPU? > > P.S.: ANyone got any hard facts on the TSC SMP issues? 2.6.15 > is definitely worse for me than 2.6.14, things that used to work just dont anymore. > Yes, the TSC is useless on these machines, but the kernel can work around it. You need JACK patched to use clock_gettime() for jack_get_microseconds. This really should be in JACK CVS by now, if it is not already. Lee From mlang at delysid.org Sun Jan 15 08:59:40 2006 From: mlang at delysid.org (mlang) Date: Sun Jan 15 08:59:02 2006 Subject: [linux-audio-dev] detune In-Reply-To: (Tim Goetze's message of "Sun, 15 Jan 2006 03:20:56 +0100 (CET)") References: <20060115012124.GB7825@falcon.fugal.net> Message-ID: <87bqydr3qr.fsf@x2.delysid.org> Tim Goetze writes: > [Hans Fugal] > >>I'm about to write a DSSI/LADSPA plugin that among other things, detunes >>the signal by up to 15 cents. My understanding is that detuning is >>accomplished by resampling. If that's the case, what do you do >>with the time difference? Do you pad/truncate to get the same number of >>samples you started out with? Wouldn't that introduce undesirables? > > It would. As far as I know, there are two common ways to do this: > > You can periodically window and granulate the signal, resample the > grains and resynthesize -- that's the faster way, doing it all in the > time domain. You'll get some comb filtering from the time-stretched > phase cancelling out during grain overlap, but if you're only doing 15 > cent, it might turn out just fine. There's a library out there that > does this, I can't seem to remember its name though. Anyone? Probably libSoundTouch? > The other way I know of is to use a phase vocoder. Basically, you > periodically window and granulate and then FFT the signal, do a bit of > math on the frequency content and resynthesize. The phase vocoder > keeps track of signal phase so the comb filtering effect is no issue. > The downside is the FFT and the math required to compute phase and > amplitude; it's quite a bit heavier on the CPU. Some code that does it > this way is at quitte.de/dsp/pvoc.html but for your intended use I'd > first look at the simpler solution mentioned above. I'd like to suggest this article: http://www.dspdimension.com/data/html/pshiftstft.html It is wonderfully detailed, includes all the necessary C source code to take the basic idea and make it fly. I used this method to write my instrument tuner by ripping out the last phase of the algorithm (resynthesis) and only using the exact frequency peak info. Its pretty useful, and I learned a lot from this article. Actually, I think thats the single most useful DSP tutorial I've ever read. It made me really grok FFT, which is something by its own right :-) Oh, and it is pretty simple to make this stuff work with libfftw3, just read tuneit.c (http://delysid.org/tuneit.html). -- CYa, Mario From bil at ccrma.Stanford.EDU Sun Jan 15 09:40:13 2006 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Sun Jan 15 09:40:24 2006 Subject: [linux-audio-dev] Re: detune In-Reply-To: <20060115121920.6181A1F5B3D@music.columbia.edu> References: <20060115121920.6181A1F5B3D@music.columbia.edu> Message-ID: <20060115143428.M98148@ccrma.Stanford.EDU> Another method, related to the vocoder but more "real-time" oriented (i.e. sample-by-sample, not fft block processed) uses a bank of Hilbert transforms (for the pitch shift) and a bank of bandpass filters (each harmonic shifted individually to maintain harmonic relations) -- see ssb-bank et al in dsp.scm in the Snd tarball (ssb refers to the single sideband suppressed carrier amplitude modulation generator). sndscm.html has examples. From mlang at delysid.org Sun Jan 15 13:28:14 2006 From: mlang at delysid.org (mlang) Date: Sun Jan 15 13:27:35 2006 Subject: [linux-audio-dev] A sequencer example In-Reply-To: <1137332879.25801.12.camel@mindpipe> (Lee Revell's message of "Sun, 15 Jan 2006 08:47:58 -0500") References: <20060115104614.2fe95591.krampenschiesser@freenet.de> <20060115121211.5e02df9f@mango.fruits.de> <200601151124.26805.cannam@all-day-breakfast.com> <87fynpr5fn.fsf@x2.delysid.org> <1137332879.25801.12.camel@mindpipe> Message-ID: <87bqydpcqp.fsf@x2.delysid.org> Lee Revell writes: > On Sun, 2006-01-15 at 14:23 +0100, mlang wrote: >> Chris Cannam writes: >> >> > On Sunday 15 Jan 2006 11:12, Florian Schmidt wrote: >> >> If you want to use alsa_seq's queues to schedule events for delivery >> >> at a later time, you probably might have a look at rosegarden. >> > >> > There's a file base/test/seq/generator.c in the Rosegarden source tree >> > that does basically what was described using the sequencer queue. It >> > does however schedule in real-time rather than beats (and so does >> > Rosegarden itself). >> > >> > http://cvs.sourceforge.net/viewcvs.py/rosegarden/base/test/seq/generator.c?view=markup >> >> Pretty intersting, I just ran this and noticed it (the diff between >> queue and gettimeofday time) drifts about 70 usecs per second. Is this >> normal expected behaviour, or another reason to hate the day I decided to buy >> a X2 CPU? >> >> P.S.: ANyone got any hard facts on the TSC SMP issues? 2.6.15 >> is definitely worse for me than 2.6.14, things that used to work just dont anymore. >> > > Yes, the TSC is useless on these machines, but the kernel can work > around it. You need JACK patched to use clock_gettime() for > jack_get_microseconds. THis doesn't make sense to me, either the kernel can work around it properly *OR* we have to patch userland. -- CYa, Mario From rlrevell at joe-job.com Sun Jan 15 13:36:49 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sun Jan 15 13:36:54 2006 Subject: [linux-audio-dev] A sequencer example In-Reply-To: <87bqydpcqp.fsf@x2.delysid.org> References: <20060115104614.2fe95591.krampenschiesser@freenet.de> <20060115121211.5e02df9f@mango.fruits.de> <200601151124.26805.cannam@all-day-breakfast.com> <87fynpr5fn.fsf@x2.delysid.org> <1137332879.25801.12.camel@mindpipe> <87bqydpcqp.fsf@x2.delysid.org> Message-ID: <1137350209.25801.38.camel@mindpipe> On Sun, 2006-01-15 at 19:28 +0100, mlang wrote: > Lee Revell writes: > > > On Sun, 2006-01-15 at 14:23 +0100, mlang wrote: > >> Chris Cannam writes: > >> > >> > On Sunday 15 Jan 2006 11:12, Florian Schmidt wrote: > >> >> If you want to use alsa_seq's queues to schedule events for delivery > >> >> at a later time, you probably might have a look at rosegarden. > >> > > >> > There's a file base/test/seq/generator.c in the Rosegarden source tree > >> > that does basically what was described using the sequencer queue. It > >> > does however schedule in real-time rather than beats (and so does > >> > Rosegarden itself). > >> > > >> > http://cvs.sourceforge.net/viewcvs.py/rosegarden/base/test/seq/generator.c?view=markup > >> > >> Pretty intersting, I just ran this and noticed it (the diff between > >> queue and gettimeofday time) drifts about 70 usecs per second. Is this > >> normal expected behaviour, or another reason to hate the day I decided to buy > >> a X2 CPU? > >> > >> P.S.: ANyone got any hard facts on the TSC SMP issues? 2.6.15 > >> is definitely worse for me than 2.6.14, things that used to work just dont anymore. > >> > > > > Yes, the TSC is useless on these machines, but the kernel can work > > around it. You need JACK patched to use clock_gettime() for > > jack_get_microseconds. > > THis doesn't make sense to me, either the kernel can work around it > properly *OR* we have to patch userland. > The kernel can work around it for the purposes of its own internal timekeeping, so that clock_gettime() and gettimeofday() return the correct results. But the kernel can't do anything if JACK uses rdtsc directly, as the TSCs remain unsynced, kernel workaround or no. So the kernel has to be changed to report the correct values when userspace calls clock_gettime(), but JACK also has to be changed to use clock_gettime() in place of rdtsc. Lee From mlang at delysid.org Sun Jan 15 13:55:29 2006 From: mlang at delysid.org (mlang) Date: Sun Jan 15 13:54:52 2006 Subject: [linux-audio-dev] Re: detune In-Reply-To: <20060115143428.M98148@ccrma.Stanford.EDU> (Bill Schottstaedt's message of "Sun, 15 Jan 2006 06:40:13 -0800") References: <20060115121920.6181A1F5B3D@music.columbia.edu> <20060115143428.M98148@ccrma.Stanford.EDU> Message-ID: <873bjppbha.fsf@x2.delysid.org> "Bill Schottstaedt" writes: > Another method, related to the vocoder but more "real-time" oriented > (i.e. sample-by-sample, not fft block processed) uses a bank of Hilbert > transforms (for the pitch shift) and a bank of bandpass filters (each > harmonic shifted individually to maintain harmonic relations) -- > see ssb-bank et al in dsp.scm in the Snd tarball (ssb refers to the > single sideband suppressed carrier amplitude modulation generator). > sndscm.html has examples. And here is a minimalistic class for SuperCollider to do this (sort of). FreqShift : UGen { *ar { arg input, shift, mul=1.0, add=0.0; var sin1, sin2, cos1, cos2, constFreq, filtFreq; constFreq = SampleRate.ir * 0.25; filtFreq = constFreq * 0.75; cos1 = FSinOsc.ar(constFreq, 0); sin1 = FSinOsc.ar(constFreq, pi/2); cos2 = SinOsc.ar(constFreq + shift, 0); sin2 = SinOsc.ar(constFreq + shift, pi/2); ^(LPF.ar(LPF.ar(input * cos1, filtFreq), filtFreq) * cos2) + (LPF.ar(LPF.ar(input * sin1, filtFreq), filtFreq) * sin2) * mul + add; } } -- CYa, Mario From hans at fugal.net Sun Jan 15 15:11:18 2006 From: hans at fugal.net (Hans Fugal) Date: Sun Jan 15 15:11:31 2006 Subject: [linux-audio-dev] detune In-Reply-To: <87bqydr3qr.fsf@x2.delysid.org> References: <20060115012124.GB7825@falcon.fugal.net> <87bqydr3qr.fsf@x2.delysid.org> Message-ID: <43CAAC66.3090402@fugal.net> mlang wrote: > I'd like to suggest this article: > > http://www.dspdimension.com/data/html/pshiftstft.html > > It is wonderfully detailed, includes all the necessary C source > code to take the basic idea and make it fly. I used this > method to write my instrument tuner by ripping out the last phase > of the algorithm (resynthesis) and only using the exact > frequency peak info. Its pretty useful, and I learned a lot > from this article. Actually, I think thats the single most useful > DSP tutorial I've ever read. It made me really grok FFT, which > is something by its own right :-) > Oh, and it is pretty simple to make this stuff work with libfftw3, just > read tuneit.c (http://delysid.org/tuneit.html). Thanks for these excellent links, I think they will help me understand this very well. And thanks to everyone else for their insights as well. From seablaede at gmail.com Sun Jan 15 15:22:25 2006 From: seablaede at gmail.com (Thomas Vecchione) Date: Sun Jan 15 15:20:38 2006 Subject: [linux-audio-dev] ALSA USB Driver Message-ID: <43CAAF01.2030700@softhome.net> Ok I apologize if this should go on the user list, wasnt really sure.. I am considering purchasing a PDA that will eventually have the express purpose of recording 24/96 audio, and I was looking at picking up an apogee Mini-me USB. I was wondering how uniform USB audio interfaces were, and the likelihood the Apogee would actually work or not as it is not listed at all in the Alsa wiki. Seablade From rlrevell at joe-job.com Sun Jan 15 15:35:44 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sun Jan 15 15:35:49 2006 Subject: [linux-audio-dev] ALSA USB Driver In-Reply-To: <43CAAF01.2030700@softhome.net> References: <43CAAF01.2030700@softhome.net> Message-ID: <1137357344.25801.64.camel@mindpipe> On Sun, 2006-01-15 at 15:22 -0500, Thomas Vecchione wrote: > Ok I apologize if this should go on the user list, wasnt really sure.. > > I am considering purchasing a PDA that will eventually have the express > purpose of recording 24/96 audio, and I was looking at picking up an > apogee Mini-me USB. I was wondering how uniform USB audio interfaces > were, and the likelihood the Apogee would actually work or not as it is > not listed at all in the Alsa wiki. If the device is "class compliant" it will work. If not all bets are off. Lee From smithbone at gmail.com Sun Jan 15 15:49:26 2006 From: smithbone at gmail.com (Richard Smith) Date: Sun Jan 15 15:49:30 2006 Subject: [linux-audio-dev] ALSA USB Driver In-Reply-To: <43CAAF01.2030700@softhome.net> References: <43CAAF01.2030700@softhome.net> Message-ID: <8a0c36780601151249o580b14cbi11f7069a48e6ed88@mail.gmail.com> On 1/15/06, Thomas Vecchione wrote: > I am considering purchasing a PDA that will eventually have the express > purpose of recording 24/96 audio, and I was looking at picking up an > apogee Mini-me USB. I was wondering how uniform USB audio interfaces > were, and the likelihood the Apogee would actually work or not as it is > not listed at all in the Alsa wiki. Take a good look at the specs. I bought a M-Audio Audiophile USB and found out that it was not "class compliant" and then on top of that it was unable to do full-duplex audio at 24/96. I ended up buying a PCI card. The general feedback I got from others was that 24/96 audio on a USB device can be somewhat tricky. -- Richard A. Smith From v2 at iki.fi Sun Jan 15 16:02:17 2006 From: v2 at iki.fi (Sampo Savolainen) Date: Sun Jan 15 16:02:23 2006 Subject: [linux-audio-dev] ALSA USB Driver In-Reply-To: <8a0c36780601151249o580b14cbi11f7069a48e6ed88@mail.gmail.com> References: <43CAAF01.2030700@softhome.net> <8a0c36780601151249o580b14cbi11f7069a48e6ed88@mail.gmail.com> Message-ID: <1137358937.13347.5.camel@puppeli> On Sun, 2006-01-15 at 14:49 -0600, Richard Smith wrote: > Take a good look at the specs. I bought a M-Audio Audiophile USB and > found out that it was not "class compliant" and then on top of that it > was unable to do full-duplex audio at 24/96. I ended up buying a PCI > card. Actually, you don't even have look at the specs. M-audio uses really sneaky tactics with their USB devices. Look at the pictures of the Audiophile USB. See anything missing? Where is the USB logo? They only use the "USB trident" which is used only to identify the connector. They don't use the proper USB logo for which they need to be class complient. If they would use the logo and fail compliency, they would be subject to a flogging from USB-IF. So in effect, their USB devices aren't USB devices at all. They just happen to work with some USB hosts. I got hit by this via their Quattro. Nice piece of kit, too bad it... didn't work properly! -- Sampo Savolainen From rlrevell at joe-job.com Sun Jan 15 16:12:40 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sun Jan 15 16:12:47 2006 Subject: [linux-audio-dev] ALSA USB Driver In-Reply-To: <1137358937.13347.5.camel@puppeli> References: <43CAAF01.2030700@softhome.net> <8a0c36780601151249o580b14cbi11f7069a48e6ed88@mail.gmail.com> <1137358937.13347.5.camel@puppeli> Message-ID: <1137359560.25801.77.camel@mindpipe> On Sun, 2006-01-15 at 23:02 +0200, Sampo Savolainen wrote: > On Sun, 2006-01-15 at 14:49 -0600, Richard Smith wrote: > > Take a good look at the specs. I bought a M-Audio Audiophile USB and > > found out that it was not "class compliant" and then on top of that it > > was unable to do full-duplex audio at 24/96. I ended up buying a PCI > > card. > > Actually, you don't even have look at the specs. M-audio uses really > sneaky tactics with their USB devices. > > Look at the pictures of the Audiophile USB. See anything missing? Where > is the USB logo? They only use the "USB trident" which is used only to > identify the connector. They don't use the proper USB logo for which > they need to be class complient. If they would use the logo and fail > compliency, they would be subject to a flogging from USB-IF. > > So in effect, their USB devices aren't USB devices at all. They just > happen to work with some USB hosts. > > I got hit by this via their Quattro. Nice piece of kit, too bad it... > didn't work properly! > Do some vendors actually make it difficult to find out whether the device is class compliant or not? Man, that would be evil. I've never used a USB audio device and don't plan to, but would expect this to be included in the specs posted on the web site... Also it's possible for a device to be USB compliant but not a "class compliant audio device". It used to be the easiest way to tell was "does it work on OSX without a driver", I'm not sure if that's still the case. Lee From seablaede at gmail.com Sun Jan 15 16:20:35 2006 From: seablaede at gmail.com (Thomas Vecchione) Date: Sun Jan 15 16:18:51 2006 Subject: [linux-audio-dev] ALSA USB Driver In-Reply-To: <1137359560.25801.77.camel@mindpipe> References: <43CAAF01.2030700@softhome.net> <8a0c36780601151249o580b14cbi11f7069a48e6ed88@mail.gmail.com> <1137358937.13347.5.camel@puppeli> <1137359560.25801.77.camel@mindpipe> Message-ID: <43CABCA3.5080606@gmail.com> Thanks for the info, will check on wether or not it is class compliant, was exactly what I needed to know. In as far as the M-Audio thing goes, I have had some nasty run ins with them recently(Exact things like this)unfortunatly and am trying to steer clear for a bit from them, part of the reason I decided to spend the extra money for an RME interface;) Seablade From v2 at iki.fi Sun Jan 15 17:00:58 2006 From: v2 at iki.fi (Sampo Savolainen) Date: Sun Jan 15 17:01:04 2006 Subject: [linux-audio-dev] ALSA USB Driver In-Reply-To: <43CABCA3.5080606@gmail.com> References: <43CAAF01.2030700@softhome.net> <8a0c36780601151249o580b14cbi11f7069a48e6ed88@mail.gmail.com> <1137358937.13347.5.camel@puppeli> <1137359560.25801.77.camel@mindpipe> <43CABCA3.5080606@gmail.com> Message-ID: <1137362458.13347.8.camel@puppeli> On Sun, 2006-01-15 at 16:20 -0500, Thomas Vecchione wrote: > In as far as the M-Audio thing goes, I have had some nasty run ins with > them recently(Exact things like this)unfortunatly and am trying to steer > clear for a bit from them, part of the reason I decided to spend the > extra money for an RME interface;) Good choice. :) Except for one exception. Even the great almighty RME has been reluctant in releasing details for their fireface. That device is definitely out of the question for linux users. You might have heard about freebob, which is a alpha-stage driver for some firewire devices. it doesn't work with the fireface. (and isn't there yet for serious work for any device anyway). -- Sampo Savolainen From seablaede at gmail.com Sun Jan 15 17:48:56 2006 From: seablaede at gmail.com (Thomas Vecchione) Date: Sun Jan 15 17:47:10 2006 Subject: [linux-audio-dev] ALSA USB Driver In-Reply-To: <1137362458.13347.8.camel@puppeli> References: <43CAAF01.2030700@softhome.net> <8a0c36780601151249o580b14cbi11f7069a48e6ed88@mail.gmail.com> <1137358937.13347.5.camel@puppeli> <1137359560.25801.77.camel@mindpipe> <43CABCA3.5080606@gmail.com> <1137362458.13347.8.camel@puppeli> Message-ID: <43CAD158.3090505@gmail.com> > :) > > Except for one exception. Even the great almighty RME has been reluctant > in releasing details for their fireface. That device is definitely out > of the question for linux users. Yes I was aware of this, but it never hurts to get a reminder. It looks like once my rep gets back in at sweetwater I will probably be ordering the RME Hammerfall 9632(The 24/192 Interface with Analog In/Outs and 192kHz optional expansion boards... Insert Drool here) as it is a nice balance for my budget at the moment. I was thinking about the 96/52 as I like ADAT as a medium, I just dont have the money for some AD/DA converters to do it justice though and replace my Pres. I think the 96/32 will serve me good as that one IS listed in Alsa, Thanks Paul is it who wrote the drivers for that one?;) Yea at the moment I ahve one of the earlier interfaces that could do 24/96 and am having problems, in particular at the upper end of the sample rates, but even in general(See my post Sorting Out XRuns in Audio-User) that I think are more to do with the card showing its age and possible consumerness;) What I mentioned above though was for a possible portable setup, I have a Marantz but I am not happy with the Pres on it, and was considering picking up a decent QTopia based PDA, putting ALSA on it, and using the USB connection for the Apogee to give me a nice portable 24/96 setup with good pres. Still considering it, but I havent found anything that says USB standards compliant on the Apogee docs, even though from looking at their installation docs I woudl bet it is, I am not spending that 1.2k before I know for sure;) Besides that would be a ways off. Anyways I ramble, thanks for the help again. Have fun. Seablade From ce at christeck.de Sun Jan 15 17:58:00 2006 From: ce at christeck.de (Christoph Eckert) Date: Sun Jan 15 17:56:07 2006 Subject: [linux-audio-dev] ALSA USB Driver In-Reply-To: <8a0c36780601151249o580b14cbi11f7069a48e6ed88@mail.gmail.com> References: <43CAAF01.2030700@softhome.net> <8a0c36780601151249o580b14cbi11f7069a48e6ed88@mail.gmail.com> Message-ID: <200601152358.00495.ce@christeck.de> > The general feedback I got from others was that 24/96 audio on a USB > device can be somewhat tricky. Doesn't full duplex on 24/96 simply hit the limit of USB 1.1 bandwidth? I have an Edirol UA-25. When switching it from 24/48 to 24/96 it is onedirectional only. Best regards ce From erdof at bluebottle.com Sun Jan 15 21:09:03 2006 From: erdof at bluebottle.com (Ferdinand Vesely) Date: Sun Jan 15 19:59:13 2006 Subject: [linux-audio-dev] Live music performing setup using VNC? Message-ID: <20060116030903.331a792f.erdof@bluebottle.com> Hello! I'm not quite shure, if this belongs here, or to the LAU list, but I am subscribed here, so this is why I post it here. First, let me explain: I'm in an urgent need for a notebook, as I am a university student (from Slovakia) working as a part time PHP programmer and playing in a (prog)rock band. I don't have much money I can spend on that book and I need it now, so I am considering buying a refurbished IBM ThinkPad 600X (PIII/450MHz, 128 or 256 MB RAM, 12 GB HDD). I'm not very demanding, but I would be very glad, if I could use it for performing music on stage. In the beginning maybe only playing a bit with PD and playing samples and loops. I had an idea (this is why I'm writing) to buy later a better desktop PC (with a good audio interface; maybe with a rack-mount case) which would be running some audio apps (Jack, softsynths, sequencer, ...) and could be controlled on stage via MIDI and/or from the notebook using VNC (or NX) or MIDI. Or do you have any suggestion, what could work better with lower latencies? Or is this idea foolish as a whole? I'm also interested if it is worth thinking about Linux HPC clustering in a studio environment (Ardour with MPI?). Thank you! FerD From bengan at sunet.se Mon Jan 16 05:21:52 2006 From: bengan at sunet.se (Bengt =?iso-8859-1?B?R/ZyZOlu?=) Date: Mon Jan 16 05:20:58 2006 Subject: [linux-audio-dev] Live music performing setup using VNC? In-Reply-To: <20060116030903.331a792f.erdof@bluebottle.com> References: <20060116030903.331a792f.erdof@bluebottle.com> Message-ID: <20060116102152.GC9843@sunet.se> On Mon, Jan 16, 2006 at 03:09:03AM +0100, Ferdinand Vesely wrote: > Hello! > > I'm not quite shure, if this belongs here, or to the LAU list, but I am > subscribed here, so this is why I post it here. First, let me explain: > I'm in an urgent need for a notebook, as I am a university student > (from Slovakia) working as a part time PHP programmer and playing in a > (prog)rock band. I don't have much money I can spend on that book and I > need it now, so I am considering buying a refurbished IBM ThinkPad 600X > (PIII/450MHz, 128 or 256 MB RAM, 12 GB HDD). I'm not very demanding, Just some thoughts about laptops and audio. This might not be relevant to you because you will work with VNC or something similar in the end. But any way. My experience is that it is some what a coin flip if you will be able to do some real audio work with a laptop. Especially an older one. The SMBus (system management bus) is in a lot of cases something that you can't tamper with and that means that the management kicks in once in a while. On my really lousy Acer Ferrari 3000 (soon to be exchanged with an IBM/Lenovo) the SMBus starts every 50 second and then after 10 second the fourth time. This system management will affect your xruns. I hear a click every 50 sec (and then after 10 sec also). This is nothing that I can do anything about because it is not reachable from software. So I would not by a PC-laptop to do serious audio work. I don't know every (in fact I've only tested 3 of them) vendor out there so there could be good laptops two. If you really want to buy one. Try it out with a Live-CD (for audio first). I can't find the references now for the SMB-thing but it was Alan Cox that saw this first. You should be able to find it in the kernel-list archives. regards, - Bengan ------------------------------------------------------------- - KTHNOC/SUNET/NORDUnet | http://www.noc.kth.se/~bengan | 08-7906586 - From dave at pawfal.org Mon Jan 16 06:38:24 2006 From: dave at pawfal.org (Dave Griffiths) Date: Mon Jan 16 06:38:34 2006 Subject: [linux-audio-dev] Live music performing setup using VNC? In-Reply-To: <20060116030903.331a792f.erdof@bluebottle.com> References: <20060116030903.331a792f.erdof@bluebottle.com> Message-ID: <36181.193.203.82.226.1137411504.squirrel@www.webmail.pawfal.org> > Hello! > > I'm not quite shure, if this belongs here, or to the LAU list, but I am > subscribed here, so this is why I post it here. First, let me explain: > I'm in an urgent need for a notebook, as I am a university student > (from Slovakia) working as a part time PHP programmer and playing in a > (prog)rock band. I don't have much money I can spend on that book and I > need it now, so I am considering buying a refurbished IBM ThinkPad 600X > (PIII/450MHz, 128 or 256 MB RAM, 12 GB HDD). I'm not very demanding, > but I would be very glad, if I could use it for performing music on > stage. In the beginning maybe only playing a bit with PD and playing > samples and loops. for samples and loops with something like pd, that setup should be fine, but if you want to start using more synthesis you'll probably need something with a little more power. thinkpads are good laptops for live use, as they are pretty robust and reliable. funnily enough, I've found the little light they put on the lid to be essential for gigs, for when you need to see the keyboard :) > I had an idea (this is why I'm writing) to buy later > a better desktop PC (with a good audio interface; maybe with a > rack-mount case) which would be running some audio apps (Jack, > softsynths, sequencer, ...) and could be controlled on stage via MIDI > and/or from the notebook using VNC (or NX) or MIDI. Or do you have any > suggestion, what could work better with lower latencies? Or is this > idea foolish as a whole? I've known a few people to use this technique - even across different operating systems. Personally, I'd try and use osc for this sort of thing, but not everything supports that yet. cheers, dave From asbjs at stud.ntnu.no Mon Jan 16 06:57:19 2006 From: asbjs at stud.ntnu.no (=?iso-8859-1?B?QXNiavhybiBT5mL4?=) Date: Mon Jan 16 06:57:24 2006 Subject: [linux-audio-dev] one-sample length impulse - HOWTO? In-Reply-To: <200601140003.55993@goldspace.net> References: <200601140003.55993@goldspace.net> Message-ID: <20060116115719.GA26588@stud.ntnu.no> On Sat, Jan 14, 2006 at 12:03:55AM +0300, Andrew Gaydenko wrote: > Hi! > > The aim is to generate audiofile with one/few-sample-length impulse inside > silence. Is there suitable software to do the job? I usually use Matlab for this. Octave may also be used. Both of these are very suitable for that kind of work. In Octave: ----------------------------------------- % Make a 100000 sample vector of zeros, % set sample 50000 to one (the impulse), % write to file t = zeros(1,100000); t(50000) = 1; ausave('impulse.wav',t,44100,'long'); ----------------------------------------- Asbj?rn From fbar at footils.org Mon Jan 16 07:20:27 2006 From: fbar at footils.org (Frank Barknecht) Date: Mon Jan 16 07:20:21 2006 Subject: [linux-audio-dev] Live music performing setup using VNC? In-Reply-To: <20060116030903.331a792f.erdof@bluebottle.com> References: <20060116030903.331a792f.erdof@bluebottle.com> Message-ID: <20060116122027.GJ11424@fliwatut.scifi> Hallo, Ferdinand Vesely hat gesagt: // Ferdinand Vesely wrote: > I'm not quite shure, if this belongs here, or to the LAU list, but I am > subscribed here, so this is why I post it here. I think, this is more a topic for LAU, so you may want to subscribe there, too. > First, let me explain: I'm in an urgent need for a notebook, as I am > a university student (from Slovakia) working as a part time PHP > programmer and playing in a (prog)rock band. I don't have much money > I can spend on that book and I need it now, so I am considering > buying a refurbished IBM ThinkPad 600X (PIII/450MHz, 128 or 256 MB > RAM, 12 GB HDD). I'm not very demanding, but I would be very glad, > if I could use it for performing music on stage. In the beginning > maybe only playing a bit with PD and playing samples and loops. I > had an idea (this is why I'm writing) to buy later a better desktop > PC (with a good audio interface; maybe with a rack-mount case) which > would be running some audio apps (Jack, softsynths, sequencer, ...) > and could be controlled on stage via MIDI and/or from the notebook > using VNC (or NX) or MIDI. Or do you have any suggestion, what could > work better with lower latencies? Or is this idea foolish as a > whole? Generally a standard PC will of course give you "more bang for the buck". Laptops are more expensive and cannot be upgraded as easily. Still on stage you see people perform with laptops almost exclusively because they are much easier to transport and set up on stage. You will be able to do a lot with a 450MHz CPU already. Playing samples and loops is not very demanding CPU-wise. You may want to make sure to have at least 256MB RAM, though. I don't think, VNC is a good idea for remote control of audio applications. VNC has a certain lag which makes controlling graphical audio applications difficult, at least in my opinion. I would rather build a GUI on the local machine with Pd and control the other side through Midi or better yet through networking/OSC. This way you don't generate that much load on your network and gain a consistent latency. Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From fons.adriaensen at alcatelaleniaspace.com Mon Jan 16 07:21:53 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Mon Jan 16 07:22:06 2006 Subject: [linux-audio-dev] Live music performing setup using VNC? In-Reply-To: <36181.193.203.82.226.1137411504.squirrel@www.webmail.pawfal.org> References: <20060116030903.331a792f.erdof@bluebottle.com> <36181.193.203.82.226.1137411504.squirrel@www.webmail.pawfal.org> Message-ID: <20060116122153.GA11325@bth05w.ABSp.alcatel.be> On Mon, Jan 16, 2006 at 11:38:24AM -0000, Dave Griffiths wrote: > thinkpads are good laptops for live use, as they are pretty robust and > reliable. I can confirmn that. I'm quite happy with mine. Only problem is that at 1.7G it's rather hungry (for battery power) - more so if for reliable audio at low latencies you have to disable the CPU speed scaling. > funnily enough, I've found the little light they put on the lid > to be essential for gigs, for when you need to see the keyboard :) Yep. When you first try the 'Thinklight' as it's called it seems ridiculously weak. But it's just the right intensity to clearly see the white legends on the black keytops. I also have a USB light on a flex arm, but rarely use for the keyboard - it's too much. But fine for scores etc. besides the computer. -- FA From kouhia at nic.funet.fi Mon Jan 16 12:56:36 2006 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Mon Jan 16 12:56:42 2006 Subject: [linux-audio-dev] Re: ANN: DT-42 DrumToy 0.1.0 Message-ID: Hello. I downloaded the mentioned TR808 samples. The samples are in some odd SGI package file, and so, I quickly wrote an extractor. But to save your time, I placed all at http://www.funet.fi/~kouhia/sgitr808samples.tar.gz The extractor and the original sample package are at http://www.funet.fi/~kouhia/sgitr808.tar.gz Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From david at olofson.net Mon Jan 16 14:51:57 2006 From: david at olofson.net (David Olofson) Date: Mon Jan 16 13:51:04 2006 Subject: [linux-audio-dev] Re: ANN: DT-42 DrumToy 0.1.0 In-Reply-To: References: Message-ID: <200601162051.57323.david@olofson.net> On Monday 16 January 2006 18:56, Juhana Sadeharju wrote: > > Hello. I downloaded the mentioned TR808 samples. The samples are > in some odd SGI package file, and so, I quickly wrote an extractor. > But to save your time, I placed all at > http://www.funet.fi/~kouhia/sgitr808samples.tar.gz Nice! I was thinking about grabbing some more of these sounds, but as I had misplaced the original archive (and because I was getting a bit bored with just drums), I decided to throw in that "fm2" thing instead. Probably doesn't belong there, but I guess it made the demo songs slightly less boring. ;-) Anyway, with a proper instrument editor in DT-42, you can easilly import whatever WAV files you want. (It's already possible, though editing the I*: tags in your song file might not be your idea of a nice user interface. :-D ) //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --' From drobilla at connect.carleton.ca Tue Jan 17 14:16:12 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue Jan 17 14:16:36 2006 Subject: [linux-audio-dev] liblo lo_message_deserialise? In-Reply-To: <20060112215834.GF6806@login.ecs.soton.ac.uk> References: <873bjtpj23.fsf@x2.delysid.org> <20060112215834.GF6806@login.ecs.soton.ac.uk> Message-ID: <1137525372.9846.1.camel@localhost.localdomain> On Thu, 2006-12-01 at 21:58 +0000, Steve Harris wrote: > On Thu, Jan 12, 2006 at 04:22:44 +0100, Mario Lang wrote: > > Hi. > > > > While playing a little with the liblo lowlevel interface > > (I am trying to deliver and receive/decode OSC messages via a non-UDP/TCP > > transport), I found lo_message_serialise. I also had to rip > > a bit of code from lo_send_internal and friends. > > However, I cant find a counterpart for decomposing messages, so > > I guess currently, I would have to rip even more code out of > > the lib itself. I am wondering, would anyone else benefit > > from a clean lowlevel API for decoding messages to a lo_message? > > > > I am imagining something like > > > > lo_message lo_message_from_buffer (char *buf, int size) > > > > Any comments? > > Make sense to me, and it would make lo_server_recv() cleaner if the OSC > parsing stuff was seperate from the IO stuff. I would also like very much a simple mechanism to serialize and deserialize OSC messages to/from raw OSC packets, FWIW. -DR- From drobilla at connect.carleton.ca Tue Jan 17 14:21:21 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue Jan 17 14:24:55 2006 Subject: [linux-audio-dev] A sequencer example In-Reply-To: <87fynpr5fn.fsf@x2.delysid.org> References: <20060115104614.2fe95591.krampenschiesser@freenet.de> <20060115121211.5e02df9f@mango.fruits.de> <200601151124.26805.cannam@all-day-breakfast.com> <87fynpr5fn.fsf@x2.delysid.org> Message-ID: <1137525681.9846.5.camel@localhost.localdomain> On Sun, 2006-15-01 at 14:23 +0100, mlang wrote: > Chris Cannam writes: > > > On Sunday 15 Jan 2006 11:12, Florian Schmidt wrote: > >> If you want to use alsa_seq's queues to schedule events for delivery > >> at a later time, you probably might have a look at rosegarden. > > > > There's a file base/test/seq/generator.c in the Rosegarden source tree > > that does basically what was described using the sequencer queue. It > > does however schedule in real-time rather than beats (and so does > > Rosegarden itself). > > > > http://cvs.sourceforge.net/viewcvs.py/rosegarden/base/test/seq/generator.c?view=markup > > Pretty intersting, I just ran this and noticed it (the diff between > queue and gettimeofday time) drifts about 70 usecs per second. Is this > normal expected behaviour, or another reason to hate the day I decided to buy > a X2 CPU? > > P.S.: ANyone got any hard facts on the TSC SMP issues? 2.6.15 > is definitely worse for me than 2.6.14, things that used to work just dont anymore. I just bought a shiny new X2 3800+ and am dealing with all this garbage as well. Extremely unimpressed with the whole situation in general, but anyway.... Right now I'm booting my kernel with clock=pmtmr and I've applied the attached patch to Jack and things seem to be working fine, at least superficially. -DR- P.S. Someone (who I forget) was having problems with Om and every action taking _seconds_ to produce a visible/audible response. This was the source of that problem, for the record. -------------- next part -------------- A non-text attachment was scrubbed... Name: jack-clock3.patch Type: text/x-patch Size: 8649 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060117/e75d9d7d/jack-clock3.bin From paul at linuxaudiosystems.com Tue Jan 17 14:34:36 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Tue Jan 17 14:32:03 2006 Subject: [linux-audio-dev] A sequencer example In-Reply-To: <1137525681.9846.5.camel@localhost.localdomain> References: <20060115104614.2fe95591.krampenschiesser@freenet.de> <20060115121211.5e02df9f@mango.fruits.de> <200601151124.26805.cannam@all-day-breakfast.com> <87fynpr5fn.fsf@x2.delysid.org> <1137525681.9846.5.camel@localhost.localdomain> Message-ID: <1137526476.22907.156.camel@localhost.localdomain> > P.S. Someone (who I forget) was having problems with Om and every > action taking _seconds_ to produce a visible/audible response. This was > the source of that problem, for the record. "The time that an action may take to occur will depend on how long it takes your operating system to schedule a thread onto the same processor as the one used to schedule the action. This is indeterminate." :)) From rlrevell at joe-job.com Tue Jan 17 17:55:54 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Tue Jan 17 17:56:25 2006 Subject: [linux-audio-dev] A sequencer example In-Reply-To: <1137526476.22907.156.camel@localhost.localdomain> References: <20060115104614.2fe95591.krampenschiesser@freenet.de> <20060115121211.5e02df9f@mango.fruits.de> <200601151124.26805.cannam@all-day-breakfast.com> <87fynpr5fn.fsf@x2.delysid.org> <1137525681.9846.5.camel@localhost.localdomain> <1137526476.22907.156.camel@localhost.localdomain> Message-ID: <1137538554.19678.57.camel@mindpipe> Paul, is that clock_gettime patch in JACK CVS yet? It appears that the kernel has been fixed as of 2.6.15. Lee From jayv at synth.net Wed Jan 18 04:38:23 2006 From: jayv at synth.net (Jay Vaughan) Date: Wed Jan 18 04:41:24 2006 Subject: [linux-audio-dev] synthesis on gp2x .. (was Fwd: RE: [gpx-dev] hardware interfaces) In-Reply-To: <200601130514.56434.david@olofson.net> References: <200601121826.13512.david@olofson.net> <200601130514.56434.david@olofson.net> Message-ID: At 5:14 +0100 13/1/06, David Olofson wrote: >Well, I'm considering getting one, though I'm not totally sure what >I'd use it for. (Except plain fun, of course, which is no small part >of the whole Free/Open Source thing.) > the GP2X sure is fun. i have two now, and another two on their way for siblings/family .. >Are there any restrictions WRT which Linux drivers are available? (I'm >thinking external USB devices and the like.) Does it support (USB) >keyboards and mice? (A foldable rubber keyboard and some sort of >tracker-like sequencer could be useful. Or is there a foldable rubber >MIDI/USB keyboard out there somewhere?) the only restrictions are what you can get compiled to run on the included 2.4.24 kernel .. and the USB is definitely usable for peripherals, once you've made (or obtained/bought) an EXT breakout cable for the job .. i've got one for Serial/MIDI .. adding Video, Audio, and USB to it this week .. >Another thought: Is there a market for shareware games? (Ports, at >least - it'd have to be a rather large market for dedicated game >designs to be viable, I think.) i think there is .. well-marketed games could do well on this platform, and its at least as much of an opportunity as there is for cell-phone games.. and those do well, once the marketing machine is up to support the effort of getting games in kids' hands.. but i honestly thing the GP2X could be a very fun synthesis/audio platform, most of all, and thats my purpose for getting into it .. just great fun, portable, pocketable, audio mania .. -- ; Jay Vaughan From jayv at synth.net Wed Jan 18 04:39:57 2006 From: jayv at synth.net (Jay Vaughan) Date: Wed Jan 18 04:41:42 2006 Subject: [linux-audio-dev] synthesis on gp2x .. (was Fwd: RE: [gpx-dev] hardware interfaces) In-Reply-To: References: <200601121826.13512.david@olofson.net> <200601130514.56434.david@olofson.net> Message-ID: At 15:40 +0100 13/1/06, Sam Roig wrote: >May your wishes come true: >http://www.soundonsound.com/sos/sep05/articles/tahorng.htm yeah, that looks like a lot of fun .. definitely will keep an eye out for that as a near-future accessory for the GP2X .. -- ; Jay Vaughan From torbenh at gmx.de Wed Jan 18 12:15:40 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Wed Jan 18 12:22:48 2006 Subject: [linux-audio-dev] [ANN] ninjam with jack support... In-Reply-To: References: <20060110112725.GA4974@mobilat.informatik.uni-bremen.de> <43C72366.10307@machinehasnoagenda.com> Message-ID: <20060118171540.GA4545@mobilat> On Sat, Jan 14, 2006 at 02:40:14AM -0500, Jesse Chappell wrote: > On 1/12/06, Shayne O'Connor wrote: > > > coolness ... i remember email exchanges with jp mercury (freewheelin) > > where we dreamed of just this sort of thing ... > > Yeah, integrating this with some collaborative loop > management/sequencing and we'll really have something. Who's > interested? Not sure if the current ninjam codebase could (or should) > support this. But after ninjamming for 2 hours tonight, i'm sold on > the concept. i cant do much developing currently (need to get rid of this ninjam addiction :) my plans for ninjam are currently to add some code to make it sync to jack_transport. while this looks trivial, its not really trivial, because jack_transport must sync to ninjam transport. and making ninjam the transport master will render ardour pretty useless. i will however make this fly soon. so how shall we proceed ? the problem is that the ninjam server must run on a machine with some moderate upload bandwidth, which i dont have. so if we want to change/implement another ninjam server we have to make sure we got a testing environment... i am tempted to write a gtk client for ninjam, because i consider this ncurses code quite unmaintainable... we also need a tool, which converts the recorded session to something we can actually edit on linux. converting it to an ardour session looks like the way to go for me... ok guys... lets try to get on with this... it such a cool idea... -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From torbenh at gmx.de Wed Jan 18 12:16:42 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Wed Jan 18 12:23:59 2006 Subject: [linux-audio-dev] [ANN] ninjam with jack support... In-Reply-To: <43C72366.10307@machinehasnoagenda.com> References: <20060110112725.GA4974@mobilat.informatik.uni-bremen.de> <43C72366.10307@machinehasnoagenda.com> Message-ID: <20060118171642.GB4545@mobilat> On Fri, Jan 13, 2006 at 02:49:58PM +1100, Shayne O'Connor wrote: > torbenh@gmx.de wrote: > >hello... i just wanted to announce, that i have written a jack binding > >for ninjam. > > > >ninjam is a network jam session software. > >www.ninjam.com > > > > > > coolness ... i remember email exchanges with jp mercury (freewheelin) > where we dreamed of just this sort of thing ... > > >the ported consoleclient for ninjam is available here: > > > >http://galan.sf.net/ninjam-with-jack.tar.bz2 > > > >and yes... there is a Makefile.. find -name Makefile it... > >i just added the jack support... > > > > took me a while to figure out how to build it (i think it already was) > ... had to do a "make clean", then "make" sorry for that... > > >more io ports will follow... > >also dont use with too low period sizes, it does not behave so well.. > > > > just did a quick test with it ... had a five minute jam with some dude, > and all seemed to go well (didn't do anything fancy, like hooking it > into ardour, though). i had a period of 512 in jack, which seemed ok. > > thanx for the software (xfst, galan, now this), torben ... you > (scissors, paper) ROCK! thanks... > > shayne > -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From jacob01 at gmx.net Wed Jan 18 14:06:43 2006 From: jacob01 at gmx.net (Jacob) Date: Wed Jan 18 14:06:31 2006 Subject: [linux-audio-dev] synthesis on gp2x .. (was Fwd: RE: [gpx-dev] hardware interfaces) In-Reply-To: References: <200601121826.13512.david@olofson.net> <200601130514.56434.david@olofson.net> Message-ID: <20060118190643.GA8824@localhost> Hello, On Wed, Jan 18, 2006 at 10:38:23AM +0100, Jay Vaughan wrote: > At 5:14 +0100 13/1/06, David Olofson wrote: > [...] > the GP2X sure is fun. i have two now, and another two on their way > for siblings/family .. > > >Are there any restrictions WRT which Linux drivers are available? (I'm > >thinking external USB devices and the like.) Does it support (USB) > >keyboards and mice? (A foldable rubber keyboard and some sort of > >tracker-like sequencer could be useful. Or is there a foldable rubber > >MIDI/USB keyboard out there somewhere?) > > the only restrictions are what you can get compiled to run on the > included 2.4.24 kernel .. and the USB is definitely usable for > peripherals, once you've made (or obtained/bought) an EXT breakout > cable for the job .. i've got one for Serial/MIDI .. adding Video, > Audio, and USB to it this week .. Sounds great, but I'm a little bit confused by other information I found on the web about USB host mode support: citing from http://www.gp32x.com/board/index.php?showtopic=20717: I/O Ports: Headphones, USB (not powered), EXT, DC Power (possibly SDIO in the future) *note* it may be possible to use self-powered USB peripherals with GP2X, i.e. USB hubs & harddrives etc. USB Peripherals: Recent information unfortunately reveals the GP2X does NOT feature USB host mode due to the chip implementation used in the final design. Where can I find information on how to make such a EXT adaptor cable that provides USB host mode IO with current of-the-shelf gp2x? TIA. ciao, Jacob > > [...] From rlrevell at joe-job.com Wed Jan 18 14:14:01 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Jan 18 14:14:06 2006 Subject: [linux-audio-dev] synthesis on gp2x .. (was Fwd: RE: [gpx-dev] hardware interfaces) In-Reply-To: <20060118190643.GA8824@localhost> References: <200601121826.13512.david@olofson.net> <200601130514.56434.david@olofson.net> <20060118190643.GA8824@localhost> Message-ID: <1137611641.26812.5.camel@mindpipe> On Wed, 2006-01-18 at 20:06 +0100, Jacob wrote: > Sounds great, but I'm a little bit confused by other information I found > on the web about USB host mode support: I'm confused too. I've never heard of "USB host mode", what is it? Lee From smithbone at gmail.com Wed Jan 18 14:16:55 2006 From: smithbone at gmail.com (Richard Smith) Date: Wed Jan 18 14:16:59 2006 Subject: [linux-audio-dev] synthesis on gp2x .. (was Fwd: RE: [gpx-dev] hardware interfaces) In-Reply-To: <1137611641.26812.5.camel@mindpipe> References: <200601121826.13512.david@olofson.net> <200601130514.56434.david@olofson.net> <20060118190643.GA8824@localhost> <1137611641.26812.5.camel@mindpipe> Message-ID: <8a0c36780601181116y390ba5b9tdd6270155eb75211@mail.gmail.com> > > Sounds great, but I'm a little bit confused by other information I found > > on the web about USB host mode support: > > I'm confused too. I've never heard of "USB host mode", what is it? I believe he is refering to if the device can operate as a USB host bridge rather than just as a usb device. OTG devices and some embedded chips can be both. -- Richard A. Smith From paul at linuxaudiosystems.com Wed Jan 18 14:46:05 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Jan 18 14:44:56 2006 Subject: [linux-audio-dev] synthesis on gp2x .. (was Fwd: RE: [gpx-dev] hardware interfaces) In-Reply-To: <8a0c36780601181116y390ba5b9tdd6270155eb75211@mail.gmail.com> References: <200601121826.13512.david@olofson.net> <200601130514.56434.david@olofson.net> <20060118190643.GA8824@localhost> <1137611641.26812.5.camel@mindpipe> <8a0c36780601181116y390ba5b9tdd6270155eb75211@mail.gmail.com> Message-ID: <1137613565.5010.18.camel@localhost.localdomain> On Wed, 2006-01-18 at 13:16 -0600, Richard Smith wrote: > > > Sounds great, but I'm a little bit confused by other information I found > > > on the web about USB host mode support: > > > > I'm confused too. I've never heard of "USB host mode", what is it? > > I believe he is refering to if the device can operate as a USB host > bridge rather than just as a usb device. OTG devices and some > embedded chips can be both. we have an iAudio X5 compressed music + video player around that is capable of this, for example. you can plug a USB mass storage based camera in, and the X5 acts as the USB host. --p From jacob01 at gmx.net Wed Jan 18 15:06:38 2006 From: jacob01 at gmx.net (Jacob) Date: Wed Jan 18 15:06:27 2006 Subject: [linux-audio-dev] synthesis on gp2x .. (was Fwd: RE: [gpx-dev] hardware interfaces) In-Reply-To: <8a0c36780601181116y390ba5b9tdd6270155eb75211@mail.gmail.com> References: <200601121826.13512.david@olofson.net> <200601130514.56434.david@olofson.net> <20060118190643.GA8824@localhost> <1137611641.26812.5.camel@mindpipe> <8a0c36780601181116y390ba5b9tdd6270155eb75211@mail.gmail.com> Message-ID: <20060118200638.GC8824@localhost> On Wed, Jan 18, 2006 at 01:16:55PM -0600, Richard Smith wrote: > > > Sounds great, but I'm a little bit confused by other information I found > > > on the web about USB host mode support: > > > > I'm confused too. I've never heard of "USB host mode", what is it? > > I believe he is refering to if the device can operate as a USB host > bridge rather than just as a usb device. OTG devices and some > embedded chips can be both. Yes, that is what I'm refering to. AFAIK I haven't any chance to access an USB 'device' (device/slave/peripheral mode, eg MIDI/audio interfaces) from another one that isn't capable to do/switch to 'host mode', be it a host controller or an on-the-go (OTG) device. Citing from http://en.wikipedia.org/wiki/USB A USB system has an asymmetric design, consisting of a host controller and multiple devices connected in a tree-like fashion using special hub devices, called USB hubs. and An extension to USB called USB On-The-Go allows a single port to act as either a host or a device - chosen by which end of the cable plugs into the socket on the unit. Even after the cable is hooked up and the units are talking, the two units may "swap" ends under program control. This facility targets units such as PDAs where the USB link might connect to a PC's host port as a device in one instance, yet connect as a host itself to a keyboard and mouse device in another instance. Jacob From jayv at synth.net Wed Jan 18 16:15:23 2006 From: jayv at synth.net (Jay Vaughan) Date: Wed Jan 18 16:15:38 2006 Subject: [linux-audio-dev] synthesis on gp2x .. (was Fwd: RE: [gpx-dev] hardware interfaces) In-Reply-To: <20060118200638.GC8824@localhost> References: <200601121826.13512.david@olofson.net> <200601130514.56434.david@olofson.net> <20060118190643.GA8824@localhost> <1137611641.26812.5.camel@mindpipe> <8a0c36780601181116y390ba5b9tdd6270155eb75211@mail.gmail.com> <20060118200638.GC8824@localhost> Message-ID: >Yes, that is what I'm refering to. AFAIK I haven't any chance to access >an USB 'device' (device/slave/peripheral mode, eg MIDI/audio interfaces) >from another one that isn't capable to do/switch to 'host mode', be it a >host controller or an on-the-go (OTG) device. its not OTG on the gp2x; there are two separate USB control subsections; one makes the gp2x a 'usb device', and the other able to be a 'usb host' for other devices. separate chips, not OTG .. but both sides of the USB fence. -- ; Jay Vaughan From jayv at synth.net Wed Jan 18 16:13:17 2006 From: jayv at synth.net (Jay Vaughan) Date: Wed Jan 18 16:15:54 2006 Subject: [linux-audio-dev] synthesis on gp2x .. (was Fwd: RE: [gpx-dev] hardware interfaces) In-Reply-To: <8a0c36780601181116y390ba5b9tdd6270155eb75211@mail.gmail.com> References: <200601121826.13512.david@olofson.net> <200601130514.56434.david@olofson.net> <20060118190643.GA8824@localhost> <1137611641.26812.5.camel@mindpipe> <8a0c36780601181116y390ba5b9tdd6270155eb75211@mail.gmail.com> Message-ID: At 13:16 -0600 18/1/06, Richard Smith wrote: > > > Sounds great, but I'm a little bit confused by other information I found > > > on the web about USB host mode support: > > > > I'm confused too. I've never heard of "USB host mode", what is it? > >I believe he is refering to if the device can operate as a USB host >bridge rather than just as a usb device. OTG devices and some >embedded chips can be both. > no, you see .. the gp2x has, sorta, 'two' of everything, including USB. there's the on-chip (magiceyes) USB1 'host device' (like in your PC) routed only to EXT2 (not a standard 'flat' USB jack), and there's the additional 'slave device' USB2 chipset going to the mini-USB-socket on the side. its quite possible to put a USB-Gadget, class compliant audio driver onboard that would turn the gp2x into a 'sound device' for your PC, or Mac, or whatever .. and use the USB hosting abilities to do MIDI, other sound cards, etc... -- ; Jay Vaughan From jacob01 at gmx.net Wed Jan 18 16:56:37 2006 From: jacob01 at gmx.net (Jacob) Date: Wed Jan 18 16:56:20 2006 Subject: [linux-audio-dev] synthesis on gp2x .. (was Fwd: RE: [gpx-dev] hardware interfaces) In-Reply-To: References: <200601121826.13512.david@olofson.net> <200601130514.56434.david@olofson.net> <20060118190643.GA8824@localhost> <1137611641.26812.5.camel@mindpipe> <8a0c36780601181116y390ba5b9tdd6270155eb75211@mail.gmail.com> Message-ID: <20060118215637.GE8824@localhost> On Wed, Jan 18, 2006 at 10:13:17PM +0100, Jay Vaughan wrote: > > no, you see .. the gp2x has, sorta, 'two' of everything, including > USB. there's the on-chip (magiceyes) USB1 'host device' (like in > your PC) routed only to EXT2 (not a standard 'flat' USB jack), and > there's the additional 'slave device' USB2 chipset going to the > mini-USB-socket on the side. > > its quite possible to put a USB-Gadget, class compliant audio driver > onboard that would turn the gp2x into a 'sound device' for your PC, > or Mac, or whatever .. and use the USB hosting abilities to do MIDI, > other sound cards, etc... :-) I _am_ impressed. Jacob From musound at jps.net Wed Jan 18 18:04:54 2006 From: musound at jps.net (Sean Bolton) Date: Wed Jan 18 18:04:54 2006 Subject: [linux-audio-dev] hexter DSSI plugin 0.5.9 Message-ID: <8252f5d5732c282b26dfdbddee129828@jps.net> A minor update of hexter, the Yamaha DX7 modeling DSSI plugin, is now available at: http://sourceforge.net/project/showfiles.php? group_id=104230&package_id=134428 Changes include: * The coarse frequency of each operator now can be controlled in real time via MIDI control changes. * Fixes for RPM, gcc 2.9x and 4.x, and Mac OS X 10.4 'Tiger'. More information about hexter and DSSI can be found at: http://dssi.sourceforge.net/hexter.html hexter is written by Sean Bolton, and copyright (c)2006 under the GNU General Public License, version 2 or later. From conrad.berhoerster at gmx.de Wed Jan 18 18:41:58 2006 From: conrad.berhoerster at gmx.de (conrad =?iso-8859-1?q?berh=F6rster?=) Date: Wed Jan 18 18:43:54 2006 Subject: [linux-audio-dev] templates - little bit OT Message-ID: <200601190041.59361.conrad.berhoerster@gmx.de> Hello, maybe the c++ gurus out there have an idea. currently i think it is unpossible. i try to use a template a a class member variable, like that: asume a template matrix class template < int cols, int rows> class matrix { // implementation } everything works fine when i'm doing something like matrix<<3,4> mymat; matrix <5,5> quad; but now i try to do it a little more generic i try to build a class, which have a member of this matrix like class MyClass { MyClass(); MyClass(n,n); private: matrix }; this means, at runtime, i want to set the size of the matrix. is this possible? this are divers concepts (templates and runtime) , aren't they? thanks c~ From larsl at users.sourceforge.net Wed Jan 18 18:51:35 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Wed Jan 18 18:51:13 2006 Subject: [linux-audio-dev] templates - little bit OT In-Reply-To: <200601190041.59361.conrad.berhoerster@gmx.de> References: <200601190041.59361.conrad.berhoerster@gmx.de> Message-ID: <1137628295.8734.3.camel@c213-100-50-8.swipnet.se> On Thu, 2006-01-19 at 00:41 +0100, conrad berh?rster wrote: > class MyClass > { > MyClass(); > MyClass(n,n); > private: > matrix > }; > > this means, at runtime, i want to set the size of the matrix. is this > possible? this are divers concepts (templates and runtime) , aren't they? It is not possible. Templates are instantiated at compile time. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060119/3e4f850c/attachment.bin From torbenh at gmx.de Wed Jan 18 22:01:11 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Wed Jan 18 22:08:17 2006 Subject: [linux-audio-dev] [ANN] ninjam with jack support... In-Reply-To: <20060118171540.GA4545@mobilat> References: <20060110112725.GA4974@mobilat.informatik.uni-bremen.de> <43C72366.10307@machinehasnoagenda.com> <20060118171540.GA4545@mobilat> Message-ID: <20060119030111.GA7410@mobilat> On Wed, Jan 18, 2006 at 06:15:40PM +0100, torbenh@gmx.de wrote: > > Yeah, integrating this with some collaborative loop > > management/sequencing and we'll really have something. Who's > > interested? Not sure if the current ninjam codebase could (or should) > > support this. But after ninjamming for 2 hours tonight, i'm sold on > > the concept. > > i cant do much developing currently > (need to get rid of this ninjam addiction :) just had some hour without jamming.... > > my plans for ninjam are currently to add some code to make it sync to > jack_transport. a first test is here: http://galan.sf.net/ninjam-with-jack-0.02.tar.bz2 this make ninjam the transport master... slave code will follow.... -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From smithbone at gmail.com Thu Jan 19 13:52:15 2006 From: smithbone at gmail.com (Richard Smith) Date: Thu Jan 19 13:52:19 2006 Subject: [linux-audio-dev] Using UTF-8 Message-ID: <8a0c36780601191052k2e31f217kfb7c828c6a9d2115@mail.gmail.com> A while ago the list moderator requested that all of us gmail users "fix" our mail by setting the UTF-8 option. Which I did. However, I'm now on another mailing list on Sourceforge where the utf-8 thing causes junk to be added after my signature. This is some sort of bug in sorceforge's base64 handleing. I've been asked by why I had it set that way. So I was just wondering what the issue with non- utf8 mail was on lad. -- Richard A. Smith From dominique.michel at citycable.ch Thu Jan 19 17:08:11 2006 From: dominique.michel at citycable.ch (Dominique Michel) Date: Thu Jan 19 17:08:17 2006 Subject: [linux-audio-dev] MIDI library Message-ID: <20060119230811.66818038@pingouin.banquise> Hi all, I am new to this list, living in Switzerland and working mainly with electronic. I have done it was some time ago a monophonic realtime note recognition software on an embeded dsp56k system and I want to adapt it to linux. It will take some time to me to do that because I know almost nothing about c and c++ programming, as about the alsa and jack libraries. But I know my algorytm, and it is working just fine on my dsp. The latency is very low, 1+(~1/4) period of the sound, the (~1/4) term depend of the harmonic content of the sound. I believe at it is worth to do a jack-alsa software with it. A gui will be needed, giving the possibility to change, save and recall some parameters of the recognition loop on an per instrument basis. Can you recommand me a good, and if possible simple to use and fast, MIDI library? I will use only basic functionalities as the possibility to send MIDI notes to the sound server. Ciao, Dominique From capocasa at gmx.net Fri Jan 20 06:31:34 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Fri Jan 20 06:29:02 2006 Subject: [linux-audio-dev] C++ Keyboard Event Handling Message-ID: Hi, new to this list and knowing absolutely nothing about C++ audio programming I would like to ask for a little bit of help. I want to create a console keyboard to MIDI application and for this I would like to read the physical status of keyboard keys. Thank you. Carlo Capocasa From david at olofson.net Fri Jan 20 07:24:08 2006 From: david at olofson.net (David Olofson) Date: Fri Jan 20 07:25:24 2006 Subject: [linux-audio-dev] C++ Keyboard Event Handling In-Reply-To: References: Message-ID: <200601201324.08819.david@olofson.net> On Friday 20 January 2006 12:31, Carlo Capocasa wrote: [...] > I want to create a console keyboard to MIDI application and for this > I would like to read the physical status of keyboard keys. That is, MIDI output, as in sending MIDI messages to an onboard or external hardware synth, or a softsynth running in the driver or as a separate application? (As opposed to generating "wave" audio in your application.) Anyway, keybord input is done by handling "press" and "release" events. When you get a "press" event, you set some state variable for the corresponding key to "down", and when you get a "release" event, you clear that state variable. SDL also has an alternative API that has this logic built in: SDL_GetKeyState(): 'man SDL_GetKeyState': ---------------------------------------------------------------------- ... SYNOPSIS #include "SDL.h" Uint8 *SDL_GetKeyState(int *numkeys); DESCRIPTION Gets a snapshot of the current keyboard state. The current state is return as a pointer to an array, the size of this array is stored in numkeys. The array is indexed by the SDLK_* symbols. A value of 1 means the key is pressed and a value of 0 means its not. The pointer returned is a pointer to an internal SDL array and should not be freed by the caller. Note: Use SDL_PumpEvents to update the state array. EXAMPLE Uint8 *keystate = SDL_GetKeyState(NULL); if ( keystate[SDLK_RETURN] ) printf("Return Key Pressed."); ... ---------------------------------------------------------------------- //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --' From capocasa at gmx.net Fri Jan 20 07:44:03 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Fri Jan 20 07:41:21 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: <200601201324.08819.david@olofson.net> References: <200601201324.08819.david@olofson.net> Message-ID: Hi David! Thanks for your reply! I'm impressed with your credentials, too :) > That is, MIDI output, as in sending MIDI messages to an onboard or > external hardware synth, or a softsynth running in the driver or as a > separate application? (As opposed to generating "wave" audio in your > application.) MIDI output, sending events to the ALSA sequencer, and from there to the softsynths... > Anyway, keybord input is done by handling "press" and "release" > events. When you get a "press" event, you set some state variable for > the corresponding key to "down", and when you get a "release" event, > you clear that state variable. Sounds great! Do you have a code example? > SDL also has an alternative API that has this logic built in: > SDL_GetKeyState(): Hm, I'm wondering if I could do this sticking to C++ builtins... Carlo From tewner at jct.ac.il Fri Jan 20 07:49:17 2006 From: tewner at jct.ac.il (Michael Tewner) Date: Fri Jan 20 07:44:06 2006 Subject: [linux-audio-dev] C++ Keyboard Event Handling In-Reply-To: References: Message-ID: <43D0DC4D.7040100@jct.ac.il> There is a similar example in Charles Petzold's Programming Windows book - if I remember correctly. Carlo Capocasa wrote: > Hi, > > new to this list and knowing absolutely nothing about C++ audio > programming I would like to ask for a little bit of help. > > I want to create a console keyboard to MIDI application and for this I > would like to read the physical status of keyboard keys. Thank you. > > Carlo Capocasa From tewner at jct.ac.il Fri Jan 20 07:51:25 2006 From: tewner at jct.ac.il (Michael Tewner) Date: Fri Jan 20 07:46:12 2006 Subject: [linux-audio-dev] C++ Keyboard Event Handling In-Reply-To: <43D0DC4D.7040100@jct.ac.il> References: <43D0DC4D.7040100@jct.ac.il> Message-ID: <43D0DCCD.1000007@jct.ac.il> Woopsie - Wrong list :-) Michael Tewner wrote: > There is a similar example in Charles Petzold's Programming Windows book > - if I remember correctly. > > > > Carlo Capocasa wrote: >> Hi, >> >> new to this list and knowing absolutely nothing about C++ audio >> programming I would like to ask for a little bit of help. >> >> I want to create a console keyboard to MIDI application and for this I >> would like to read the physical status of keyboard keys. Thank you. >> >> Carlo Capocasa From Cedric.Roux at eurecom.fr Fri Jan 20 07:49:35 2006 From: Cedric.Roux at eurecom.fr (Cedric Roux) Date: Fri Jan 20 07:49:39 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: Message-ID: On Fri, 20 Jan 2006, Carlo Capocasa wrote: > > SDL also has an alternative API that has this logic built in: > > SDL_GetKeyState(): > > Hm, I'm wondering if I could do this sticking to C++ builtins... > > Carlo You can't. Getting the key is a I/O operation on the terminal. Each terminal has its own language, which is out of the scope of the standard C++ (well, at least I am sure of that for C, C++ should be the same I guess). You need to use some layer, like ncurses or something. Or go to X Window where you can handle Key events. Maybe SDL is good for that also (I don't know if it works for terminals, check it). C?dric. From paul at linuxaudiosystems.com Fri Jan 20 07:58:51 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Jan 20 07:56:21 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: References: <200601201324.08819.david@olofson.net> Message-ID: <1137761931.9170.54.camel@localhost.localdomain> > > Anyway, keybord input is done by handling "press" and "release" > > events. When you get a "press" event, you set some state variable for > > the corresponding key to "down", and when you get a "release" event, > > you clear that state variable. > > Sounds great! Do you have a code example? not possible without specifying which graphical user toolkit you want to use. if you don't want to use a GUI toolkit, you are talking about raw terminal keycodes, which can be done but its hard, non-portable and hacky. > Hm, I'm wondering if I could do this sticking to C++ builtins... > totally out of the question. From fons.adriaensen at alcatelaleniaspace.com Fri Jan 20 08:05:30 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Fri Jan 20 08:05:38 2006 Subject: [linux-audio-dev] C++ Keyboard Event Handling In-Reply-To: References: Message-ID: <20060120130530.GA13173@bth05w.ABSp.alcatel.be> On Fri, Jan 20, 2006 at 12:31:34PM +0100, Carlo Capocasa wrote: > new to this list and knowing absolutely nothing about C++ audio > programming I would like to ask for a little bit of help. > > I want to create a console keyboard to MIDI application and for this I > would like to read the physical status of keyboard keys. Thank you. Such a thing exists, it's called vkeybd. Written by someone@suse IIRC. -- FA From bengan at sunet.se Fri Jan 20 08:12:13 2006 From: bengan at sunet.se (Bengt =?iso-8859-1?B?R/ZyZOlu?=) Date: Fri Jan 20 08:11:22 2006 Subject: [linux-audio-dev] C++ Keyboard Event Handling In-Reply-To: <20060120130530.GA13173@bth05w.ABSp.alcatel.be> References: <20060120130530.GA13173@bth05w.ABSp.alcatel.be> Message-ID: <20060120131213.GF9789@sunet.se> On Fri, Jan 20, 2006 at 02:05:30PM +0100, Alfons Adriaensen wrote: > On Fri, Jan 20, 2006 at 12:31:34PM +0100, Carlo Capocasa wrote: > > > new to this list and knowing absolutely nothing about C++ audio > > programming I would like to ask for a little bit of help. > > > > I want to create a console keyboard to MIDI application and for this I > > would like to read the physical status of keyboard keys. Thank you. > > Such a thing exists, it's called vkeybd. Written by someone@suse IIRC. Was it really such a thing he was asking for? Anyway. The vkeybd I know of is this: http://www.alsa-project.org/~iwai/alsa.html#vkeybd regards, - Bengan ------------------------------------------------------------- - KTHNOC/SUNET/NORDUnet | http://www.noc.kth.se/~bengan | 08-7906586 - From capocasa at gmx.net Fri Jan 20 08:21:46 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Fri Jan 20 08:19:09 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: References: Message-ID: > You need to use some layer, like ncurses or something. Hi Cedric, perfect, that's exactly what I need to know! Thank you very much. Carlo From capocasa at gmx.net Fri Jan 20 08:29:49 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Fri Jan 20 08:26:58 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: <1137761931.9170.54.camel@localhost.localdomain> References: <200601201324.08819.david@olofson.net> <1137761931.9170.54.camel@localhost.localdomain> Message-ID: Hi Paul! > not possible without specifying which graphical user toolkit you want to use. I would like to stick to console. > if you don't want to use a GUI toolkit, you are talking about raw terminal keycodes, > which can be done but its hard, non-portable and hacky. Cedric mentioned ncurses, do you think this would be suitable for quasi-realtime operation? Thank you for your reply. Carlo From capocasa at gmx.net Fri Jan 20 08:35:47 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Fri Jan 20 08:33:17 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: <20060120131213.GF9789@sunet.se> References: <20060120130530.GA13173@bth05w.ABSp.alcatel.be> <20060120131213.GF9789@sunet.se> Message-ID: Hi! Yes, vkeybd is what I am using now. I set out to create a console alternative that is also more stable when pressing many keys at once. I also have a little bit of distrust for TCL scripted keyboard event handling when operating quasi-realtime. Carlo From Cedric.Roux at eurecom.fr Fri Jan 20 08:35:54 2006 From: Cedric.Roux at eurecom.fr (Cedric Roux) Date: Fri Jan 20 08:36:00 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: Message-ID: On Fri, 20 Jan 2006, Carlo Capocasa wrote: > Yes, vkeybd is what I am using now. I set out to create a console > alternative that is also more stable when pressing many keys at once. You have to know that keyboards cannot handle tons of keys pressed simultaneously (at least the ones I tried). This might explain that. C?dric. From david at olofson.net Fri Jan 20 08:35:34 2006 From: david at olofson.net (David Olofson) Date: Fri Jan 20 08:36:35 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: References: Message-ID: <200601201435.34361.david@olofson.net> On Friday 20 January 2006 13:49, Cedric Roux wrote: [...] > Maybe SDL is good for that also (I don't know if it works for > terminals, check it). SDL doesn't do keyboard input unless you open up a display - but it *does* support aalib... //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --' From paul at linuxaudiosystems.com Fri Jan 20 08:43:53 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Jan 20 08:40:47 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: References: <20060120130530.GA13173@bth05w.ABSp.alcatel.be> <20060120131213.GF9789@sunet.se> Message-ID: <1137764633.9170.61.camel@localhost.localdomain> On Fri, 2006-01-20 at 14:35 +0100, Carlo Capocasa wrote: > Hi! > > Yes, vkeybd is what I am using now. I set out to create a console > alternative that is also more stable when pressing many keys at once. > > I also have a little bit of distrust for TCL scripted keyboard event > handling when operating quasi-realtime. first of all, the design of almost all keyboards makes arbitrary use of multiple key presses at once impossible. you can google for information on this; basically there is a sensor strip below the keys that has a number of "busses" on it. different keys share these busses, and it is physically impossible to detect one key press when another is held down. as for use ncurses, it works but provides no way to detect raw key presses, only character input. hence, there is no difference in ncurses between a user pressing the tab key or the control key and "i". you also cannot detect key press and release. ardour's "ksi" interface has code that handles raw keycodes, even on another machine (network transparent raw keycode transmission, heh). it doesn't interact well with a running instance of X Window, so you can't use it inside a terminal window, but on a text console, its perfect, if i say so myself ;) --p From fons.adriaensen at alcatelaleniaspace.com Fri Jan 20 08:49:12 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Fri Jan 20 08:49:20 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: References: <20060120130530.GA13173@bth05w.ABSp.alcatel.be> <20060120131213.GF9789@sunet.se> Message-ID: <20060120134912.GB13173@bth05w.ABSp.alcatel.be> On Fri, Jan 20, 2006 at 02:35:47PM +0100, Carlo Capocasa wrote: > Yes, vkeybd is what I am using now. I set out to create a console > alternative that is also more stable when pressing many keys at once. Computer keyboards are not designed to handle this. If some key combinations do not work in vkeybd, they'll probably fail whatever method you use. -- FA From david at olofson.net Fri Jan 20 08:51:50 2006 From: david at olofson.net (David Olofson) Date: Fri Jan 20 08:52:30 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: References: <20060120131213.GF9789@sunet.se> Message-ID: <200601201451.50782.david@olofson.net> On Friday 20 January 2006 14:35, Carlo Capocasa wrote: > Hi! > > Yes, vkeybd is what I am using now. I set out to create a console > alternative that is also more stable when pressing many keys at > once. You're talking about ghosting issues? (For example, if you hold A, S and Z, the keyboard will either generate a ghost X, or the X key is filtered out and won't respond, depending on how smart the keyboard MCU is.) I'm afraid there's no way to fix that, as it's the result of keyboard hardware limitations. As if that isn't bad enough, the behavior varies across models and makes of keyboards. You can "sort of" make it work well enough for games buy picking keys that don't conflict in normal use, but polyphonic musical applications? No, I think that's pretty much futile, unless you modify the keyboard. (With a very simple MCU that doesn't do any smart filtering, you might get away with adding diodes at the key switches.) You need to get a proper MIDI master keyboard. Or, if you *really* want to use a PC keyboard, replace the keyboard MCU with one of these boards they use for interfacing arcade joysticks and buttons with the keyboard port or USB. Or maybe something like this: http://www.creative.com/products/product.asp?category=8&subcategory=234&product=14118 (I don't know if that one's Linux compatible, though.) > I also have a little bit of distrust for TCL scripted keyboard event > handling when operating quasi-realtime. Well, I don't know about TCL, but your average (garbage collected) scripting language won't exactly make things more deterministic. Then again, the keyboard input subsystem isn't designed for rock solid real time operation either. If timing is critical, you should probably stick with MIDI and use ALSA directly from C code running in your audio thread, or maybe even a high priority real time thread that timestamps events as they arrive. //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --' From david at olofson.net Fri Jan 20 08:56:40 2006 From: david at olofson.net (David Olofson) Date: Fri Jan 20 08:57:21 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: <200601201451.50782.david@olofson.net> References: <200601201451.50782.david@olofson.net> Message-ID: <200601201456.40903.david@olofson.net> On Friday 20 January 2006 14:51, David Olofson wrote: [...] > You need to get a proper MIDI master keyboard. Or, if you *really* > want to use a PC keyboard, replace the keyboard MCU with one of > these boards they use for interfacing arcade joysticks and buttons > with the keyboard port or USB. (Actually, you'd have to replace pretty much everything, as it's not really the MCU, but the keyboard switch matrix that is at fault - and that usually concists of three layers of thick plastic film these days, so it's hard, if at all possible to modify.) //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --' From capocasa at gmx.net Fri Jan 20 09:18:49 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Fri Jan 20 09:16:23 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: <200601201456.40903.david@olofson.net> References: <200601201451.50782.david@olofson.net> <200601201456.40903.david@olofson.net> Message-ID: > >>You need to get a proper MIDI master keyboard. Or, if you *really* >>want to use a PC keyboard, replace the keyboard MCU with one of >>these boards they use for interfacing arcade joysticks and buttons >>with the keyboard port or USB. > > > (Actually, you'd have to replace pretty much everything, as it's not > really the MCU, but the keyboard switch matrix that is at fault - and > that usually concists of three layers of thick plastic film these > days, so it's hard, if at all possible to modify.) > Hmmmmmmm... well, I think you've got me pretty much convinced there are some limitations I've got to live with using the keyboard for sound :) But I see you like to push the limits and I think that's really great! Carlo From capocasa at gmx.net Fri Jan 20 09:19:48 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Fri Jan 20 09:20:37 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: <20060120134912.GB13173@bth05w.ABSp.alcatel.be> References: <20060120130530.GA13173@bth05w.ABSp.alcatel.be> <20060120131213.GF9789@sunet.se> <20060120134912.GB13173@bth05w.ABSp.alcatel.be> Message-ID: > Computer keyboards are not designed to handle this. If some key > combinations do not work in vkeybd, they'll probably fail whatever > method you use. I just tried the ZynAddSubFX Virtual Keyboard and you're right... :( From capocasa at gmx.net Fri Jan 20 09:21:07 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Fri Jan 20 09:30:33 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: <1137764633.9170.61.camel@localhost.localdomain> References: <20060120130530.GA13173@bth05w.ABSp.alcatel.be> <20060120131213.GF9789@sunet.se> <1137764633.9170.61.camel@localhost.localdomain> Message-ID: > as for use ncurses, it works but provides no way to detect raw key > presses, only character input. hence, there is no difference in ncurses > between a user pressing the tab key or the control key and "i". you also > cannot detect key press and release. Ah, so that's out of the question... > ardour's "ksi" interface has code that handles raw keycodes, even on > another machine (network transparent raw keycode transmission, heh). it > doesn't interact well with a running instance of X Window, so you can't > use it inside a terminal window, but on a text console, its perfect, if > i say so myself ;) So you are saying the ksi interface could be used in a GTK application, or in a console application when there is no X server running? Carlo From capocasa at gmx.net Fri Jan 20 09:22:08 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Fri Jan 20 09:40:29 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: References: Message-ID: > You have to know that keyboards cannot handle tons of keys pressed > simultaneously (at least the ones I tried). This might explain that. Sad, but true! So I will have to live with that part... Carlo From paul at linuxaudiosystems.com Fri Jan 20 09:47:05 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Jan 20 09:44:21 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: References: <20060120130530.GA13173@bth05w.ABSp.alcatel.be> <20060120131213.GF9789@sunet.se> <1137764633.9170.61.camel@localhost.localdomain> Message-ID: <1137768425.9170.77.camel@localhost.localdomain> On Fri, 2006-01-20 at 15:21 +0100, Carlo Capocasa wrote: > > as for use ncurses, it works but provides no way to detect raw key > > presses, only character input. hence, there is no difference in ncurses > > between a user pressing the tab key or the control key and "i". you also > > cannot detect key press and release. > > Ah, so that's out of the question... > > > ardour's "ksi" interface has code that handles raw keycodes, even on > > another machine (network transparent raw keycode transmission, heh). it > > doesn't interact well with a running instance of X Window, so you can't > > use it inside a terminal window, but on a text console, its perfect, if > > i say so myself ;) > > So you are saying the ksi interface could be used in a GTK application, > or in a console application when there is no X server running? From paul at linuxaudiosystems.com Fri Jan 20 09:47:39 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Jan 20 09:44:51 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: References: <20060120130530.GA13173@bth05w.ABSp.alcatel.be> <20060120131213.GF9789@sunet.se> <1137764633.9170.61.camel@localhost.localdomain> Message-ID: <1137768459.9170.79.camel@localhost.localdomain> On Fri, 2006-01-20 at 15:21 +0100, Carlo Capocasa wrote: > > as for use ncurses, it works but provides no way to detect raw key > > presses, only character input. hence, there is no difference in ncurses > > between a user pressing the tab key or the control key and "i". you also > > cannot detect key press and release. > > Ah, so that's out of the question... > > > ardour's "ksi" interface has code that handles raw keycodes, even on > > another machine (network transparent raw keycode transmission, heh). it > > doesn't interact well with a running instance of X Window, so you can't > > use it inside a terminal window, but on a text console, its perfect, if > > i say so myself ;) > > So you are saying the ksi interface could be used in a GTK application, > or in a console application when there is no X server running? i am saying that the KSI interface contains code that could be reused in a console application. From capocasa at gmx.net Fri Jan 20 10:02:01 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Fri Jan 20 09:59:48 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: <1137768459.9170.79.camel@localhost.localdomain> References: <20060120130530.GA13173@bth05w.ABSp.alcatel.be> <20060120131213.GF9789@sunet.se> <1137764633.9170.61.camel@localhost.localdomain> <1137768459.9170.79.camel@localhost.localdomain> Message-ID: > i am saying that the KSI interface contains code that could be reused in > a console application. Great! Thanks for your time. Carlo From capocasa at gmx.net Fri Jan 20 12:30:41 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Fri Jan 20 12:28:05 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: <1137768459.9170.79.camel@localhost.localdomain> References: <20060120130530.GA13173@bth05w.ABSp.alcatel.be> <20060120131213.GF9789@sunet.se> <1137764633.9170.61.camel@localhost.localdomain> <1137768459.9170.79.camel@localhost.localdomain> Message-ID: Paul, could you help me find the KSI source? Thanks, Carlo From paul at linuxaudiosystems.com Fri Jan 20 13:07:29 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Jan 20 13:04:36 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: References: <20060120130530.GA13173@bth05w.ABSp.alcatel.be> <20060120131213.GF9789@sunet.se> <1137764633.9170.61.camel@localhost.localdomain> <1137768459.9170.79.camel@localhost.localdomain> Message-ID: <1137780449.9170.91.camel@localhost.localdomain> On Fri, 2006-01-20 at 18:30 +0100, Carlo Capocasa wrote: > Paul, could you help me find the KSI source? Thanks, Carlo download http://ardour.org/releases/ardour-0.99.tar.bz2 the code is in the "ksi" directory. look at physical_keyboard.{cc,h} to get started. From capocasa at gmx.net Fri Jan 20 14:57:34 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Fri Jan 20 14:55:12 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: <1137780449.9170.91.camel@localhost.localdomain> References: <20060120130530.GA13173@bth05w.ABSp.alcatel.be> <20060120131213.GF9789@sunet.se> <1137764633.9170.61.camel@localhost.localdomain> <1137768459.9170.79.camel@localhost.localdomain> <1137780449.9170.91.camel@localhost.localdomain> Message-ID: > the code is in the "ksi" directory. look at physical_keyboard.{cc,h} > to get started. There is no ksi directory in ardour-0.99. Got lucky in the CVS tarball though. Sorry, gotta say the 'd' word :) Is there any documentation available? Carlo From paul at linuxaudiosystems.com Fri Jan 20 15:05:39 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Jan 20 15:02:38 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: References: <20060120130530.GA13173@bth05w.ABSp.alcatel.be> <20060120131213.GF9789@sunet.se> <1137764633.9170.61.camel@localhost.localdomain> <1137768459.9170.79.camel@localhost.localdomain> <1137780449.9170.91.camel@localhost.localdomain> Message-ID: <1137787539.9170.97.camel@localhost.localdomain> On Fri, 2006-01-20 at 20:57 +0100, Carlo Capocasa wrote: > > the code is in the "ksi" directory. look at physical_keyboard.{cc,h} > > to get started. > > There is no ksi directory in ardour-0.99. Got lucky in the CVS tarball > though. > > Sorry, gotta say the 'd' word :) Is there any documentation available? don't be ridiculous :) this was written as a private, non-library chunk of code. why would i document that? the source is much more accurate than any docs, and google will fill in the blanks. From capocasa at gmx.net Fri Jan 20 16:05:13 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Fri Jan 20 16:02:35 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: <1137787539.9170.97.camel@localhost.localdomain> References: <20060120130530.GA13173@bth05w.ABSp.alcatel.be> <20060120131213.GF9789@sunet.se> <1137764633.9170.61.camel@localhost.localdomain> <1137768459.9170.79.camel@localhost.localdomain> <1137780449.9170.91.camel@localhost.localdomain> <1137787539.9170.97.camel@localhost.localdomain> Message-ID: > don't be ridiculous :) this was written as a private, non-library chunk > of code. why would i document that? the source is much more accurate > than any docs, and google will fill in the blanks. errrrm... as a service to humanity? no, seriously, I can understand why you would have your priorities elsewhere. all right i'll see how i can figure it out... if i do, i claim for myself the title 'c++ assistant genius'. ;) Carlo PS: I'm really impressed with how responsive this list is and I'm really starting to understand how a whole operating system could be developed by a bunch of people having fun in their spare time. It's just bubbly! You almost HAVE to code :) Infectuous spirit. So, thanks Paul and all others! C. From eviltwin69 at cableone.net Fri Jan 20 17:33:17 2006 From: eviltwin69 at cableone.net (Jan Depner) Date: Fri Jan 20 17:34:51 2006 Subject: [linux-audio-dev] C++ Keyboard Event Handling In-Reply-To: References: Message-ID: <1137796397.18672.2.camel@eviltwin> On Fri, 2006-01-20 at 12:31 +0100, Carlo Capocasa wrote: > Hi, > > new to this list and knowing absolutely nothing about C++ audio > programming I would like to ask for a little bit of help. > > I want to create a console keyboard to MIDI application and for this I > would like to read the physical status of keyboard keys. Thank you. > > Carlo Capocasa > Check out Qt - it's just keypress event handling. -- Jan 'Evil Twin' Depner The Fuzzy Dice http://myweb.cableone.net/eviltwin69/fuzzy.html "As we enjoy great advantages from the invention of others, we should be glad of an opportunity to serve others by any invention of ours, and this we should do freely and generously." Benjamin Franklin, on declining patents offered by the governor of Pennsylvania for his "Pennsylvania Fireplace", c. 1744 From kjetil at ccrma.stanford.edu Fri Jan 20 17:43:20 2006 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Fri Jan 20 17:43:30 2006 Subject: [linux-audio-dev] Re: templates - little bit OT In-Reply-To: <20060120124125.C46032AFE9E@music.columbia.edu> References: <20060120124125.C46032AFE9E@music.columbia.edu> Message-ID: Lars Luthman: > > On Thu, 2006-01-19 at 00:41 +0100, conrad berh?rster wrote: >> class MyClass >> { >> MyClass(); >> MyClass(n,n); >> private: >> matrix >> }; >> >> this means, at runtime, i want to set the size of the matrix. is this >> possible? this are divers concepts (templates and runtime) , aren't they? > > It is not possible. Templates are instantiated at compile time. > Nah, its possible on the fly to generate code, compile the code, and link it. I have done that many times. -- From capocasa at gmx.net Sat Jan 21 05:29:46 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Sat Jan 21 05:27:03 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: <1137796397.18672.2.camel@eviltwin> References: <1137796397.18672.2.camel@eviltwin> Message-ID: <43D20D1A.4020404@gmx.net> > Check out Qt - it's just keypress event handling. Hi Jan, thanks for replying! Qt needs X to run, doesn't it? I would like to use something that will run on the console. Carlo From fons.adriaensen at skynet.be Sat Jan 21 08:51:37 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sat Jan 21 08:45:31 2006 Subject: [linux-audio-dev] Additional chunks in WAV files with libsndfile ? Message-ID: <20060121135137.GA4999@linux-1> Hi all, is there a recommended way to write / read additional chunks in WAV files, using libsndfile (assuming it's possible at all - I didn't find any hints to this in the docs) ? What I need in particular is some way to calibrate the time axis - i.e. to say frame #N corresponds to t = 0, and some other similar info, mostly sample indices. TIA, -- FA From jacob01 at gmx.net Sat Jan 21 10:54:42 2006 From: jacob01 at gmx.net (Jacob) Date: Sat Jan 21 10:54:31 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: <43D20D1A.4020404@gmx.net> References: <1137796397.18672.2.camel@eviltwin> <43D20D1A.4020404@gmx.net> Message-ID: <20060121155442.GA28462@localhost> Hello, did you look at pathtoyourkernelsource/Documentation/input/input.txt . This covers the /dev/input* devices and is something to use from plain C (and C++) without the need to use any lib (probably Linux only). Jacob On Sat, Jan 21, 2006 at 11:29:46AM +0100, Carlo Capocasa wrote: > > > Check out Qt - it's just keypress event handling. > > Hi Jan, thanks for replying! > > Qt needs X to run, doesn't it? I would like to use something that will > run on the console. > > Carlo > From jens.andreasen at chello.se Sat Jan 21 12:28:22 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sat Jan 21 12:28:27 2006 Subject: [linux-audio-dev] MIDI library In-Reply-To: <20060119230811.66818038@pingouin.banquise> References: <20060119230811.66818038@pingouin.banquise> Message-ID: <1137864502.9411.21.camel@c80-216-124-251.cm-upc.chello.se> The library you are looking for is alsa snd_seq* The API is described here: http://www.alsa-project.org/alsa-doc/alsa-lib/seq.html On Thu, 2006-01-19 at 23:08 +0100, Dominique Michel wrote: > Hi all, > > I am new to this list, living in Switzerland and working mainly with > electronic. I have done it was some time ago a monophonic realtime note > recognition software on an embeded dsp56k system and I want to adapt it > to linux. > > It will take some time to me to do that because I know almost nothing > about c and c++ programming, as about the alsa and jack libraries. But I > know my algorytm, and it is working just fine on my dsp. > > The latency is very low, 1+(~1/4) period of the sound, the (~1/4) term > depend of the harmonic content of the sound. I believe > at it is worth to do a jack-alsa software with it. This all sounds very interresting! > > A gui will be needed, giving the possibility to change, save and recall > some parameters of the recognition loop on an per instrument basis. > > Can you recommand me a good, and if possible simple to use and fast, > MIDI library? I will use only basic functionalities as the possibility > to send MIDI notes to the sound server. > > Ciao, > Dominique -- From dominique.michel at citycable.ch Sat Jan 21 13:17:07 2006 From: dominique.michel at citycable.ch (Dominique Michel) Date: Sat Jan 21 13:17:17 2006 Subject: [linux-audio-dev] MIDI library In-Reply-To: <1137864502.9411.21.camel@c80-216-124-251.cm-upc.chello.se> References: <20060119230811.66818038@pingouin.banquise> <1137864502.9411.21.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <20060121191707.1d340899@pingouin.banquise> On Sat, 21 Jan 2006 18:28:22 +0100 Jens M Andreasen wrote: > The library you are looking for is alsa snd_seq* > > The API is described here: > http://www.alsa-project.org/alsa-doc/alsa-lib/seq.html > Hej Jens, Tack s? mycket. I have found it it was a few hours ago. I asked because I was stick with the alsa rawmidi librarie. It is a similar project,mindingsolo http://home.gna.org/midingsolo/index.html I took a look on its source code. It use a music library that is a part of the program. I believe at I can use it. It implement almost all the functions I will use, and as it use only the alsa sequencer, it will be less work to me to add a pitch function in it, as to write all from the scratch. I will contact the mindingsolo gui later. For now I must focus on a few small programs in order to learn how to use alsa and jack, and how to adapt the algorithm. Ciao, Dominique > > On Thu, 2006-01-19 at 23:08 +0100, Dominique Michel wrote: > > Hi all, > > > > I am new to this list, living in Switzerland and working mainly with > > electronic. I have done it was some time ago a monophonic realtime > > note recognition software on an embeded dsp56k system and I want to > > adapt it to linux. > > > > It will take some time to me to do that because I know almost > > nothing about c and c++ programming, as about the alsa and jack > > libraries. But I know my algorytm, and it is working just fine on > > my dsp. > > > > The latency is very low, 1+(~1/4) period of the sound, the (~1/4) > > term depend of the harmonic content of the sound. I believe > > at it is worth to do a jack-alsa software with it. > > This all sounds very interresting! Yes. I believe at my algorithm can work with jack and alsa because the clock of a modern pc is much faster as the 20MHz of my dsp board. As the linux threads are very well done, I believe at the processing time will be proportional to the audio sampling frequency and at it will work. > > > > > A gui will be needed, giving the possibility to change, save and > > recall some parameters of the recognition loop on an per instrument > > basis. > > > > Can you recommand me a good, and if possible simple to use and fast, > > MIDI library? I will use only basic functionalities as the > > possibility to send MIDI notes to the sound server. > > > > Ciao, > > Dominique From eviltwin69 at cableone.net Sat Jan 21 13:19:18 2006 From: eviltwin69 at cableone.net (Jan Depner) Date: Sat Jan 21 13:20:54 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: <43D20D1A.4020404@gmx.net> References: <1137796397.18672.2.camel@eviltwin> <43D20D1A.4020404@gmx.net> Message-ID: <1137867558.30701.0.camel@eviltwin> On Sat, 2006-01-21 at 11:29 +0100, Carlo Capocasa wrote: > > Check out Qt - it's just keypress event handling. > > Hi Jan, thanks for replying! > > Qt needs X to run, doesn't it? I would like to use something that will > run on the console. > Yeah, sorry, I missed that part. -- Jan 'Evil Twin' Depner The Fuzzy Dice http://myweb.cableone.net/eviltwin69/fuzzy.html "As we enjoy great advantages from the invention of others, we should be glad of an opportunity to serve others by any invention of ours, and this we should do freely and generously." Benjamin Franklin, on declining patents offered by the governor of Pennsylvania for his "Pennsylvania Fireplace", c. 1744 From cuse at users.sourceforge.net Sat Jan 21 16:27:26 2006 From: cuse at users.sourceforge.net (Christian Schoenebeck) Date: Sat Jan 21 16:31:26 2006 Subject: [linux-audio-dev] Additional chunks in WAV files with libsndfile ? In-Reply-To: <20060121135137.GA4999@linux-1> References: <20060121135137.GA4999@linux-1> Message-ID: <200601212227.26742.cuse@users.sourceforge.net> Am Samstag, 21. Januar 2006 14:51 schrieb fons adriaensen: > Hi all, > > is there a recommended way to write / read additional chunks in > WAV files, using libsndfile (assuming it's possible at all - I > didn't find any hints to this in the docs) ? Not sure if this is possible with libsndfile. If not you could i.e. use the RIFF classes of libgig: http://cvs.linuxsampler.org/cgi-bin/viewcvs.cgi/libgig/src/RIFF.h C++ though. :P CU Christian From capocasa at gmx.net Sun Jan 22 03:16:22 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Sun Jan 22 03:13:33 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: <1137867558.30701.0.camel@eviltwin> References: <1137796397.18672.2.camel@eviltwin> <43D20D1A.4020404@gmx.net> <1137867558.30701.0.camel@eviltwin> Message-ID: > Yeah, sorry, I missed that part. No problem, thanks for taking the time! Carlo From capocasa at gmx.net Sun Jan 22 05:11:13 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Sun Jan 22 05:08:23 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: <20060121155442.GA28462@localhost> References: <1137796397.18672.2.camel@eviltwin> <43D20D1A.4020404@gmx.net> <20060121155442.GA28462@localhost> Message-ID: Hi Jacob! Thank you very much! Do you have any coded examples handy? Carlo Jacob schrieb: > Hello, > > did you look at pathtoyourkernelsource/Documentation/input/input.txt . > This covers the /dev/input* devices and is something to use from plain C > (and C++) without the need to use any lib (probably Linux only). > > Jacob From capocasa at gmx.net Sun Jan 22 06:05:43 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Sun Jan 22 06:03:07 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: <43D0DCCD.1000007@jct.ac.il> References: <43D0DC4D.7040100@jct.ac.il> <43D0DCCD.1000007@jct.ac.il> Message-ID: > Woopsie - Wrong list :-) Hi Mike! If I ever happen to change lists I'll remember your info. ;) Carlo From jacob01 at gmx.net Sun Jan 22 07:05:03 2006 From: jacob01 at gmx.net (Jacob) Date: Sun Jan 22 07:04:40 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: References: <1137796397.18672.2.camel@eviltwin> <43D20D1A.4020404@gmx.net> <20060121155442.GA28462@localhost> Message-ID: <20060122120502.GC31120@localhost> Hi Carlo, On Sun, Jan 22, 2006 at 11:11:13AM +0100, Carlo Capocasa wrote: > Hi Jacob! > > Thank you very much! Do you have any coded examples handy? Maybe a look into DirectFB-0.9.24/inputdrivers/linux_input/linux_input.c might help you. Get it from www.directfb.org . I don't know whether you can use the input event handling of directfb without using framebuffer or SDL, but they already have c++ bindings and they support other input sources than /dev/input/event* , too. Jacob > > Carlo > > Jacob schrieb: > > Hello, > > > > did you look at pathtoyourkernelsource/Documentation/input/input.txt . > > This covers the /dev/input* devices and is something to use from plain C > > (and C++) without the need to use any lib (probably Linux only). > > > > Jacob > From mlang at delysid.org Sun Jan 22 15:03:25 2006 From: mlang at delysid.org (mlang) Date: Sun Jan 22 15:02:11 2006 Subject: [linux-audio-dev] C++ Keyboard Event Handling In-Reply-To: <20060120130530.GA13173@bth05w.ABSp.alcatel.be> (Alfons Adriaensen's message of "Fri, 20 Jan 2006 14:05:30 +0100") References: <20060120130530.GA13173@bth05w.ABSp.alcatel.be> Message-ID: <87psmk2foy.fsf@x2.delysid.org> Alfons Adriaensen writes: > On Fri, Jan 20, 2006 at 12:31:34PM +0100, Carlo Capocasa wrote: > >> new to this list and knowing absolutely nothing about C++ audio >> programming I would like to ask for a little bit of help. >> >> I want to create a console keyboard to MIDI application and for this I >> would like to read the physical status of keyboard keys. Thank you. > > Such a thing exists, it's called vkeybd. Written by someone@suse IIRC. No, its not for console, period. -- CYa, Mario From mle+la at mega-nerd.com Mon Jan 23 17:02:23 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Mon Jan 23 17:02:33 2006 Subject: [linux-audio-dev] Additional chunks in WAV files with libsndfile ? In-Reply-To: <20060121135137.GA4999@linux-1> References: <20060121135137.GA4999@linux-1> Message-ID: <20060124090223.18c2f4b8.mle+la@mega-nerd.com> fons adriaensen wrote: > Hi all, > > is there a recommended way to write / read additional chunks in > WAV files, using libsndfile (assuming it's possible at all - I > didn't find any hints to this in the docs) ? libsndfile already supports the addition of a number of specific chunk types like PEAK, strings in the INFO chunk etc. > What I need in particular is some way to calibrate the time > axis - i.e. to say frame #N corresponds to t = 0, and some > other similar info, mostly sample indices. There is no existing chunk type which does what you require. In addition, it would be a bad idea to define your own custom chunk type to do this. However, it would be possible to add a comment string containing the data you require as a text string. See: http://www.mega-nerd.com/libsndfile/api.html#string HTH, Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "The object-oriented model makes it easy to build up programs by accretion. What this often means, in practice, is that it provides a structured way to write spaghetti code." -- Paul Graham From dplist at free.fr Mon Jan 23 17:33:22 2006 From: dplist at free.fr (David) Date: Mon Jan 23 17:32:55 2006 Subject: [linux-audio-dev] libsamplerate question Message-ID: <20060123233322.3069a631.dplist@free.fr> Hello everybody ! I've just added a resampling function to my code thanks to the excellent work of Erik de Castro Lopo (thanks a lot !). Combined with libsndfile (thanks again) it is really easy to load any sound file I want. But I'd like to make sure I'm using it correctly. I process my input data in one pass using src_simple() and I have to compute the length of the output data buffer beforehand. So I did somehting like this : out_len = (long int) ceil((double) in_len * ratio); It seems that my output buffer is always one frame too big (I checked this by reading the output_frames_gen field of the SRC_DATA structure after the processing is done). Is it safe to assume that using floor() instead of ceil() will not lead to a too short output buffer in some cases ? I can live with wasting a malloced float but I'd like to be sure it cannot be done in a prettier way. Thanks. -- David From fons.adriaensen at skynet.be Mon Jan 23 18:08:11 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Mon Jan 23 18:01:59 2006 Subject: [linux-audio-dev] Additional chunks in WAV files with libsndfile ? In-Reply-To: <20060124090223.18c2f4b8.mle+la@mega-nerd.com> References: <20060121135137.GA4999@linux-1> <20060124090223.18c2f4b8.mle+la@mega-nerd.com> Message-ID: <20060123230810.GB4997@linux-1> On Tue, Jan 24, 2006 at 09:02:23AM +1100, Erik de Castro Lopo wrote: > fons adriaensen wrote: > > > What I need in particular is some way to calibrate the time > > axis - i.e. to say frame #N corresponds to t = 0, and some > > other similar info, mostly sample indices. > > There is no existing chunk type which does what you require. In > addition, it would be a bad idea to define your own custom > chunk type to do this. Would it ? It solves the problem, and all other apps will - or at least _should_ according to the WAV spec - just ignore it. What problems would be created by adding a new chunk ? The alternative would be a format that isn't standard at all. > However, it would be possible to add a comment string containing > the data you require as a text string. See: > > http://www.mega-nerd.com/libsndfile/api.html#string Yes, been there before I posted. It's probably a matter of taste, but I don't find this much cleaner than adding a new chunk. Thanks for the suggestions ! -- FA From paul at linuxaudiosystems.com Mon Jan 23 18:20:51 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Jan 23 18:18:05 2006 Subject: [linux-audio-dev] Additional chunks in WAV files with libsndfile ? In-Reply-To: <20060123230810.GB4997@linux-1> References: <20060121135137.GA4999@linux-1> <20060124090223.18c2f4b8.mle+la@mega-nerd.com> <20060123230810.GB4997@linux-1> Message-ID: <1138058451.4000.11.camel@localhost.localdomain> On Tue, 2006-01-24 at 00:08 +0100, fons adriaensen wrote: > On Tue, Jan 24, 2006 at 09:02:23AM +1100, Erik de Castro Lopo wrote: > > fons adriaensen wrote: > > > > > What I need in particular is some way to calibrate the time > > > axis - i.e. to say frame #N corresponds to t = 0, and some > > > other similar info, mostly sample indices. > > > > There is no existing chunk type which does what you require. In > > addition, it would be a bad idea to define your own custom > > chunk type to do this. > > Would it ? It solves the problem, and all other apps will - or > at least _should_ according to the WAV spec - just ignore it. > What problems would be created by adding a new chunk ? > The alternative would be a format that isn't standard at all. BWF supports such a timestamp (the origination time). > > However, it would be possible to add a comment string containing > > the data you require as a text string. See: > > > > http://www.mega-nerd.com/libsndfile/api.html#string > > Yes, been there before I posted. It's probably a matter of taste, > but I don't find this much cleaner than adding a new chunk. > > Thanks for the suggestions ! > From mle+la at mega-nerd.com Mon Jan 23 18:51:37 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Mon Jan 23 18:51:51 2006 Subject: [linux-audio-dev] Additional chunks in WAV files with libsndfile ? In-Reply-To: <20060123230810.GB4997@linux-1> References: <20060121135137.GA4999@linux-1> <20060124090223.18c2f4b8.mle+la@mega-nerd.com> <20060123230810.GB4997@linux-1> Message-ID: <20060124105137.0b0966b2.mle+la@mega-nerd.com> fons adriaensen wrote: > Would it ? It solves the problem, and all other apps will - or > at least _should_ according to the WAV spec - just ignore it. > What problems would be created by adding a new chunk ? > The alternative would be a format that isn't standard at all. The problems are as follows: - There are many very broken WAV (and AIFF) file parsers. - There is no central registry of the chunk names and hence your chunk name may colide with a current or future chunk name defined by someone else. > > http://www.mega-nerd.com/libsndfile/api.html#string > > Yes, been there before I posted. It's probably a matter of taste, > but I don't find this much cleaner than adding a new chunk. It has the advantage of being robuts, future proof and usable now. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ C++: The power, elegance and simplicity of a hand grenade. From mle+la at mega-nerd.com Mon Jan 23 18:56:20 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Mon Jan 23 18:56:33 2006 Subject: [linux-audio-dev] libsamplerate question In-Reply-To: <20060123233322.3069a631.dplist@free.fr> References: <20060123233322.3069a631.dplist@free.fr> Message-ID: <20060124105620.690273a0.mle+la@mega-nerd.com> David wrote: > I process my input data in one pass using src_simple() and I have to > compute the length of the output data buffer beforehand. So I did > somehting like this : > > out_len = (long int) ceil((double) in_len * ratio); > > It seems that my output buffer is always one frame too big (I checked > this by reading the output_frames_gen field of the SRC_DATA structure > after the processing is done). > > Is it safe to assume that using floor() instead of ceil() will not lead > to a too short output buffer in some cases ? The most you should ever loose is one sample. In addition, src_simple will not write beyond the length of the output buffer length that you specify in the output_frames field. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." -- Alan Kay From dplist at free.fr Mon Jan 23 19:05:42 2006 From: dplist at free.fr (David) Date: Mon Jan 23 19:05:15 2006 Subject: [linux-audio-dev] libsamplerate question In-Reply-To: <20060124105620.690273a0.mle+la@mega-nerd.com> References: <20060123233322.3069a631.dplist@free.fr> <20060124105620.690273a0.mle+la@mega-nerd.com> Message-ID: <20060124010542.6e816431.dplist@free.fr> On Tue, 24 Jan 2006 10:56:20 +1100 Erik de Castro Lopo wrote: > > Is it safe to assume that using floor() instead of ceil() will not > > lead to a too short output buffer in some cases ? > > The most you should ever loose is one sample. Yes, so what is the cleanest : malloc'ing an additionnal frame and not filling it or loosing a frame of data that should have come from the SRC ? > In addition, src_simple will not write beyond the length of the > output buffer length that you specify in the output_frames field. You obviously designed this field for this, yes. > Erik Thanks Erik. -- David From musound at jps.net Mon Jan 23 20:02:25 2006 From: musound at jps.net (Sean Bolton) Date: Mon Jan 23 20:02:25 2006 Subject: [linux-audio-dev] [ANN] WhySynth DSSI plugin 20060122 release Message-ID: <9c5e3a67e66a7f0306268275b07caf09@jps.net> Announcing the 20060122 release of WhySynth, a DSSI softsynth plugin. New since the last major release: * A new oscillator mode, based on Nasca O. Paul's gorgeous PADsynth algorithm. * A new filter mode, essentially the low-pass filter from amSynth. * A new dual delay effect. * Improved and extended wavetables. * More patches. * Lots of cleanups and bug fixes, including fixes for more stable operation especially under Rosegarden, and for compilation on Mac OS X 10.4 'Tiger'. Find WhySynth here: http://home.jps.net/~musound/whysynth.html More information on the DSSI plugin standard, available hosts and plugins can be found here: http://dssi.sourceforge.net/ WhySynth is written and copyright (c) 2006 by Sean Bolton, under the GNU General Public License, version 2. From mle+la at mega-nerd.com Tue Jan 24 00:15:56 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Tue Jan 24 00:16:05 2006 Subject: [linux-audio-dev] libsamplerate question In-Reply-To: <20060124010542.6e816431.dplist@free.fr> References: <20060123233322.3069a631.dplist@free.fr> <20060124105620.690273a0.mle+la@mega-nerd.com> <20060124010542.6e816431.dplist@free.fr> Message-ID: <20060124161556.2ee7ffa1.mle+la@mega-nerd.com> David wrote: > Yes, so what is the cleanest : malloc'ing an additionnal frame and not > filling it or loosing a frame of data that should have come from the > SRC ? It realy doesn't make much difference. Feel free to do as you like :-). Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one?" -- Tom Cargill From rlrevell at joe-job.com Wed Jan 25 19:33:09 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Jan 25 19:33:12 2006 Subject: [linux-audio-dev] pthread_mutex_unlock Message-ID: <1138235589.3087.81.camel@mindpipe> One Harold Chu on LKML is insisting that POSIX requires pthread_mutex_unlock to reschedule if other threads are waiting on the mutex, and that even if the calling thread immediately tries to lock the mutex again another thread must get it. I contend that both of these assertions are wrong - first, I just don't read the standard that way, and second, it would lead to obviously incorrect behavior - unlocking a mutex would no longer be an RT safe operation. What would be the point of trylock() in RT code if unlocking is going to cause a reschedule anyway? Can anyone back me up on this? Lee From pcoccoli at gmail.com Wed Jan 25 22:27:07 2006 From: pcoccoli at gmail.com (Paul Coccoli) Date: Wed Jan 25 22:27:11 2006 Subject: [linux-audio-dev] pthread_mutex_unlock In-Reply-To: <1138235589.3087.81.camel@mindpipe> References: <1138235589.3087.81.camel@mindpipe> Message-ID: <8d27a0610601251927j4fcf0923wffde977179b400f3@mail.gmail.com> On 1/25/06, Lee Revell wrote: > One Harold Chu on LKML is insisting that POSIX requires > pthread_mutex_unlock to reschedule if other threads are waiting on the > mutex, and that even if the calling thread immediately tries to lock the > mutex again another thread must get it. I contend that both of these > assertions are wrong - first, I just don't read the standard that way, > and second, it would lead to obviously incorrect behavior - unlocking a > mutex would no longer be an RT safe operation. What would be the point > of trylock() in RT code if unlocking is going to cause a reschedule > anyway? > > Can anyone back me up on this? > > Lee > > In "Programming with POSIX Threads" by David R. Butenhof, pthread_mutex_unlock is said to do this: "Unlock a mutex. The mutex becomes unowned. If any threads are waiting for the mutex, one is awakened..." Seems to suggest a reschedule. Butenhof worked on the POSIX standards, so I would consider him an authority. From rlrevell at joe-job.com Wed Jan 25 22:32:17 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Jan 25 22:32:25 2006 Subject: [linux-audio-dev] pthread_mutex_unlock In-Reply-To: <8d27a0610601251927j4fcf0923wffde977179b400f3@mail.gmail.com> References: <1138235589.3087.81.camel@mindpipe> <8d27a0610601251927j4fcf0923wffde977179b400f3@mail.gmail.com> Message-ID: <1138246337.3087.103.camel@mindpipe> On Wed, 2006-01-25 at 22:27 -0500, Paul Coccoli wrote: > On 1/25/06, Lee Revell wrote: > > One Harold Chu on LKML is insisting that POSIX requires > > pthread_mutex_unlock to reschedule if other threads are waiting on the > > mutex, and that even if the calling thread immediately tries to lock the > > mutex again another thread must get it. I contend that both of these > > assertions are wrong - first, I just don't read the standard that way, > > and second, it would lead to obviously incorrect behavior - unlocking a > > mutex would no longer be an RT safe operation. What would be the point > > of trylock() in RT code if unlocking is going to cause a reschedule > > anyway? > > > > Can anyone back me up on this? > > > > Lee > > > > > > In "Programming with POSIX Threads" by David R. Butenhof, > pthread_mutex_unlock is said to do this: > > "Unlock a mutex. The mutex becomes unowned. If any threads are > waiting for the mutex, one is awakened..." > > Seems to suggest a reschedule. Butenhof worked on the POSIX > standards, so I would consider him an authority. > On a multiprocessor yes, another thread will be immediately awakened. I don't think it implies that on a UP the unlocking thread must immediately schedule away, even if it remains the highest priority runnable thread (SCHED_FIFO) or still has timeslice left (SCHED_OTHER). Is pthread_mutex_unlock really not an RT safe operation? Lee From jens.andreasen at chello.se Thu Jan 26 03:18:50 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Thu Jan 26 03:18:57 2006 Subject: [linux-audio-dev] pthread_mutex_unlock In-Reply-To: <1138246337.3087.103.camel@mindpipe> References: <1138235589.3087.81.camel@mindpipe> <8d27a0610601251927j4fcf0923wffde977179b400f3@mail.gmail.com> <1138246337.3087.103.camel@mindpipe> Message-ID: <1138263530.9386.31.camel@c80-216-124-251.cm-upc.chello.se> On Wed, 2006-01-25 at 22:32 -0500, Lee Revell wrote: > On Wed, 2006-01-25 at 22:27 -0500, Paul Coccoli wrote: > > On 1/25/06, Lee Revell wrote: > > > One Harold Chu on LKML is insisting that POSIX requires > > > pthread_mutex_unlock to reschedule if other threads are waiting on the > > > mutex, and that even if the calling thread immediately tries to lock the > > > mutex again another thread must get it. I contend that both of these > > > assertions are wrong - first, I just don't read the standard that way, > > > and second, it would lead to obviously incorrect behavior - unlocking a > > > mutex would no longer be an RT safe operation. What would be the point > > > of trylock() in RT code if unlocking is going to cause a reschedule > > > anyway? > > > > > > Can anyone back me up on this? > > > > > > Lee > > > > > > > > > > In "Programming with POSIX Threads" by David R. Butenhof, > > pthread_mutex_unlock is said to do this: > > > > "Unlock a mutex. The mutex becomes unowned. If any threads are > > waiting for the mutex, one is awakened..." > > > > Seems to suggest a reschedule. Butenhof worked on the POSIX > > standards, so I would consider him an authority. > > > > On a multiprocessor yes, another thread will be immediately awakened. I > don't think it implies that on a UP the unlocking thread must > immediately schedule away, even if it remains the highest priority > runnable thread (SCHED_FIFO) or still has timeslice left (SCHED_OTHER). > > Is pthread_mutex_unlock really not an RT safe operation? > Only if you lock/unlock the mutex in an RT aware manner ie; not when you leave the critical section, but rather when you are done processing and have met your RT goal. Your high priority thread will then be hanging on the mutex and can grab the processor again the instant the low priority thread leaves its critical section, unlocking the mutex. -- From fons.adriaensen at alcatelaleniaspace.com Thu Jan 26 04:17:27 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Thu Jan 26 04:17:35 2006 Subject: [linux-audio-dev] pthread_mutex_unlock In-Reply-To: <1138246337.3087.103.camel@mindpipe> References: <1138235589.3087.81.camel@mindpipe> <8d27a0610601251927j4fcf0923wffde977179b400f3@mail.gmail.com> <1138246337.3087.103.camel@mindpipe> Message-ID: <20060126091727.GA15514@bth05w.ABSp.alcatel.be> On Wed, Jan 25, 2006 at 10:32:17PM -0500, Lee Revell wrote: > On Wed, 2006-01-25 at 22:27 -0500, Paul Coccoli wrote: > > > In "Programming with POSIX Threads" by David R. Butenhof, > > pthread_mutex_unlock is said to do this: > > > > "Unlock a mutex. The mutex becomes unowned. If any threads are > > waiting for the mutex, one is awakened..." > > > > Seems to suggest a reschedule. Butenhof worked on the POSIX > > standards, so I would consider him an authority. > > > > On a multiprocessor yes, another thread will be immediately awakened. I > don't think it implies that on a UP the unlocking thread must > immediately schedule away, even if it remains the highest priority > runnable thread (SCHED_FIFO) or still has timeslice left (SCHED_OTHER). If it remains the highest priority one that can be run, clearly it should just continue. If there is a higher priority one that was waiting for the mutex, that one should take over - that's the normal priority game. The only corner case I can imagine is when the contention was between equal priority threads. But even in that case I'd say that a SCHED_FIFO thread should run until either it blocks itself, or it is pre-empted by an higher priority one. So the unlock should have no effect at all. > Is pthread_mutex_unlock really not an RT safe operation? Depends on your definition of RT-safe. If it amounts to 'the running thread can't be pre-empted' then clearly the unlock is not safe. But with that definition _nothing_ is safe - you can be pre-empted at any time by a higher priority thread that is woken up by an interrupt. The normal meaning of RT-safe is more like 'doing this will not block the caller', and in that sense the unlock is RT-safe: when a higher priority thread takes over, you have not blocked yourself - you are being pre-empted. That you triggered this yourself doesn't make it 'blocking'. -- FA From jens.andreasen at chello.se Thu Jan 26 05:52:17 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Thu Jan 26 05:52:23 2006 Subject: [linux-audio-dev] pthread_mutex_unlock In-Reply-To: <8d27a0610601251927j4fcf0923wffde977179b400f3@mail.gmail.com> References: <1138235589.3087.81.camel@mindpipe> <8d27a0610601251927j4fcf0923wffde977179b400f3@mail.gmail.com> Message-ID: <1138272737.9386.46.camel@c80-216-124-251.cm-upc.chello.se> Lee! Forget my other post ... On Wed, 2006-01-25 at 22:27 -0500, Paul Coccoli wrote: > In "Programming with POSIX Threads" by David R. Butenhof, > pthread_mutex_unlock is said to do this: > > "Unlock a mutex. The mutex becomes unowned. If any threads are > waiting for the mutex, one is awakened..." > Yes, but what is the completion of that sentence? Could it be: ... and placed in the ready state. Or perhaps: ... in priority order to aquire the lock. > Seems to suggest a reschedule. Butenhof worked on the POSIX > standards, so I would consider him an authority. There seems to be consensus among Solaris/HPUX/DEC/Linux implementations that the thread is only awake long enough to aquire the lock. And then a rescheduling *may* take place. The posix documentation is a bit vague though. -- From James at superbug.co.uk Thu Jan 26 06:54:49 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Thu Jan 26 06:54:55 2006 Subject: [linux-audio-dev] pthread_mutex_unlock In-Reply-To: <1138235589.3087.81.camel@mindpipe> References: <1138235589.3087.81.camel@mindpipe> Message-ID: <43D8B889.3090300@superbug.co.uk> Lee Revell wrote: > One Harold Chu on LKML is insisting that POSIX requires > pthread_mutex_unlock to reschedule if other threads are waiting on the > mutex, and that even if the calling thread immediately tries to lock the > mutex again another thread must get it. I contend that both of these > assertions are wrong - first, I just don't read the standard that way, > and second, it would lead to obviously incorrect behavior - unlocking a > mutex would no longer be an RT safe operation. What would be the point > of trylock() in RT code if unlocking is going to cause a reschedule > anyway? > > Can anyone back me up on this? > > Lee > On a uniprocessor machine with two threads. Thread A waiting for the lock. Thread B has the lock. If thread B unlocks the lock, and then locks it again, Thread A is unlikely to get a chance to get the lock. Thread A will only get the lock if the kernel happens to do a task switch between Thread B to Thread A. If one wants B to release the lock, and give Thread A a chance to grab it, Thread B will have to co-operatively trigger the kernel to task switch to Thread A. Methods for Thread B to trigger the kernel to task switch to Thread A is not well defined, as it is just as likely that some other process will get the task switch, and not Thread A at all. The reliable way to fix this problem is to keep in mind that pthread_mutex_lock/unlock is NOT FAIR. This results in one just designing one's software differently. The Linux kernel developers all know this fact, and have manged to always provide a solution that works. This was discussed during the KS, and the performance hit from making things "fair" is too high to bother trying to implement it. James From jens.andreasen at chello.se Thu Jan 26 10:02:45 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Thu Jan 26 10:02:51 2006 Subject: [linux-audio-dev] pthread_mutex_unlock In-Reply-To: <43D8B889.3090300@superbug.co.uk> References: <1138235589.3087.81.camel@mindpipe> <43D8B889.3090300@superbug.co.uk> Message-ID: <1138287765.9386.74.camel@c80-216-124-251.cm-upc.chello.se> On Thu, 2006-01-26 at 11:54 +0000, James Courtier-Dutton wrote: > On a uniprocessor machine with two threads. > Thread A waiting for the lock. > Thread B has the lock. > If thread B unlocks the lock, and then locks it again, Thread A is > unlikely to get a chance to get the lock. If B unlocks the mutex and A is the only thread waiting for it, then pthread_mutex_unlock() gives the lock to A. B can't get it back before A have had a chance to run (whenever that'll be.) > Thread A will only get the lock if the kernel happens to do a task > switch between Thread B to Thread A. Not according to posix. Perhaps all this talk about "aquiring the lock" is what confuses us, suggesting that A has to be competitively active to get anything. Instead it is the running thread that giveth the lock away ... Again, according to posix. -- From fons.adriaensen at alcatelaleniaspace.com Thu Jan 26 11:01:01 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Thu Jan 26 11:01:13 2006 Subject: [linux-audio-dev] pthread_mutex_unlock In-Reply-To: <1138287765.9386.74.camel@c80-216-124-251.cm-upc.chello.se> References: <1138235589.3087.81.camel@mindpipe> <43D8B889.3090300@superbug.co.uk> <1138287765.9386.74.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <20060126160101.GD15514@bth05w.ABSp.alcatel.be> On Thu, Jan 26, 2006 at 04:02:45PM +0100, Jens M Andreasen wrote: > On Thu, 2006-01-26 at 11:54 +0000, James Courtier-Dutton wrote: > > > Thread A will only get the lock if the kernel happens to do a task > > switch between Thread B to Thread A. > > Not according to posix. Perhaps all this talk about "aquiring the lock" > is what confuses us, suggesting that A has to be competitively active to > get anything. Instead it is the running thread that giveth the lock > away ... > Again, according to posix. That is probably an accurate description. In one possible implementation, the lock has a priority-ordered list of threads waiting for it. Inside the unlock call, the thread at the head of the list (if any) is removed from the list, gets the lock, and is added to another priority ordered list of runnable threads. If its priority is higher than the current one, its also gets the CPU. In other words, the new thread gets the lock even before it runs again, and the original owner can't take it back. But there is a completely different (but not very efficient) way to do this sort of thing. In this model, waiting for something (e.g. a lock) involves trying to get it inside a loop, and going to sleep when that fails. When for example a lock is released, all threads that could be waiting for it (or even in the limit all threads that are waiting for anything) are woken up, and when rescheduled and running again, try one more iteration of the loop. One of them will succeed and all the others will fail and go to sleep again. In such a system, the lock is not effectively taken until the new owner is actually running, and the original owner could take it back if it continues after the unlock. This method can involve a *lot* of rescheduling that is just a waste of time. But early UNIX kernels worked like this AFAIK (using hash lists to limit the number of wasted wakeups). -- FA From zen95156 at zen.co.uk Thu Jan 26 12:05:45 2006 From: zen95156 at zen.co.uk (zen95156@zen.co.uk) Date: Thu Jan 26 12:05:50 2006 Subject: [linux-audio-dev] little question regarding Ardour Message-ID: Hello I started a session in Ardour - drag and dropped a .wav file, then recorded (sucessfully) from a Jack input. Checking the session folder, Ardour appears to record to disc as it's going along (on-the-fly). I presume Ardour can also route the incoming sound to its outputs, for monitoring. Does anyone know what mechanism Ardour uses to do this? (I'll walk blindly into speculation. Ardour uses a jack ringbuffer on its Jack input port, in the approved way - but that only leaves one read on the ringbuffer output...) Robert From larsl at users.sourceforge.net Thu Jan 26 12:16:55 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Thu Jan 26 12:16:31 2006 Subject: [linux-audio-dev] little question regarding Ardour In-Reply-To: References: Message-ID: <1138295815.8943.4.camel@c213-100-50-8.swipnet.se> On Thu, 2006-01-26 at 17:05 +0000, zen95156@zen.co.uk wrote: > Checking the session folder, Ardour appears to record to disc as it's going > along (on-the-fly). I presume Ardour can also route the incoming sound to > its outputs, for monitoring. Does anyone know what mechanism Ardour uses > to do this? > (I'll walk blindly into speculation. Ardour uses a jack ringbuffer on its Jack > input port, in the approved way - but that only leaves one read on the > ringbuffer output...) A ringbuffer is only needed if you need to transport the data from the JACK thread to another thread (like when you record incoming data to disc). If you want to route the sound to a JACK output the data never has to leave the JACK thread, it can be processed and copied directly to the output buffer - so there's nothing stopping you from copying the incoming data from the JACK input buffer to a ringbuffer _and_ to another JACK output buffer. (That being said I don't know anything about the internals of Ardour) -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060126/2209d812/attachment.bin From david at olofson.net Thu Jan 26 13:25:14 2006 From: david at olofson.net (David Olofson) Date: Thu Jan 26 13:25:43 2006 Subject: [linux-audio-dev] liblo method handler lookup logic Message-ID: <200601261925.14318.david@olofson.net> Hacked some test code here and discovered something "interesting" with lo_server_add_method() and method handling. If I try to do it like in the examples and add the default/debug ("match all") method first, it gets called for every incoming message, before the real handler is called. That is, I see an error message - and then the correct method handler is invoked anyway. Looking quickly at the code, I'd actually expect this behavior, as lo_server_add_method() does indeed add methods at the end of the list. Trying the examples again, I realize that they demonstrate this behavior as well, so maybe it's not just my code doing something funny. :-) This is with liblo 0.22 on Gentoo/AMD64. //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --' From v2 at iki.fi Thu Jan 26 15:29:59 2006 From: v2 at iki.fi (Sampo Savolainen) Date: Thu Jan 26 15:30:06 2006 Subject: [linux-audio-dev] little question regarding Ardour In-Reply-To: References: Message-ID: <1138307399.8430.10.camel@puppeli> On Thu, 2006-01-26 at 17:05 +0000, zen95156@zen.co.uk wrote: > Hello > > I started a session in Ardour - drag and dropped a .wav file, then recorded (sucessfully) from a Jack input. > > Checking the session folder, Ardour appears to record to disc as it's going along (on-the-fly). > > I presume Ardour can also route the incoming sound to its outputs, for monitoring. > > Does anyone know what mechanism Ardour uses to do this? See Windows -> Options-> misc -> "Use Software Monitoring" This mechanism will push the input sound to the track outputs when the track is record enabled. > (I'll walk blindly into speculation. Ardour uses a jack ringbuffer on its Jack input port, in the approved way - but that only leaves one read on the ringbuffer output...) You don't need to care about ringbuffers to get monitoring working. :) -- Sampo Savolainen From jens.andreasen at chello.se Fri Jan 27 06:09:20 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Fri Jan 27 06:09:26 2006 Subject: [linux-audio-dev] pthread_mutex_unlock In-Reply-To: <20060126160101.GD15514@bth05w.ABSp.alcatel.be> References: <1138235589.3087.81.camel@mindpipe> <43D8B889.3090300@superbug.co.uk> <1138287765.9386.74.camel@c80-216-124-251.cm-upc.chello.se> <20060126160101.GD15514@bth05w.ABSp.alcatel.be> Message-ID: <1138360160.9386.173.camel@c80-216-124-251.cm-upc.chello.se> On Thu, 2006-01-26 at 17:01 +0100, Alfons Adriaensen wrote: - > But there is a completely different (but not very efficient) way to > do this sort of thing. In this model, waiting for something (e.g. a > lock) involves trying to get it inside a loop, and going to sleep > when that fails. When for example a lock is released, all threads that > could be waiting for it (or even in the limit all threads that are > waiting for anything) are woken up, and when rescheduled and running > again, try one more iteration of the loop. One of them will succeed > and all the others will fail and go to sleep again. In such a system, > the lock is not effectively taken until the new owner is actually > running, and the original owner could take it back if it continues > after the unlock. This method can involve a *lot* of rescheduling > that is just a waste of time. But early UNIX kernels worked like > this AFAIK (using hash lists to limit the number of wasted wakeups). > It gets better. I dusted off one oldish book, the Pthreads Primer. It has been a free download from Sun since 1996, so I expect quite a few people to have read it (else, go do it now.) On page 104 I find the following code snippet which attempts at explaining how to create a basic mutual exclusion lock: try_again: ldstub address -> register compare register, 0 branch_equal got_it call go_to_sleep jump try_again got_it: return The go_to_sleep/try_again sequence suggests a busy wait. Furthermore the surrounding text says "Notice that there is nothing that guarantee the thread that goes to sleep will ever get the lock when it wakes up." Now, this is not exactly how pthread_mutex_lock should work. In all fairness though, the section at hand is about atomic operations rather than the implementation of pthreads. (Here, ldstub is an instruction guaranteed to load and store atomically systemwide, no matter how many processors you have installed. It loads a memory location and immediately sets that location to 0xFF.) Let us flip a few pages forward and have a look at the actual implementation. Here we have pretty pictures with sleeper queues just like we expected. But we also have a description of a rare corner case, where one running thread, not in the queue yet, can grab the lock before any of those in the queue have had a chance to run. This again suggest that the thread has to be, not only runable, but even running to get the lock. It also suggests that pthread_mutex_unlock will do something like: mx[mutex] = 0 if (mxq[mutex]) wakeup_one(mxq[mutex]) ... which is weired when we look at the pre and post conditions of the mutex when there are threads waiting. It is bloody locked! So why would we ever want to unlock it? The described behaviour may or may not have have been true for Solaris in 1996, but a more reasonable implementation would have been: if (mxq[mutex]) wakeup_one(mxq[mutex]) else mx[mutex] = 0 Race condition, thou be gone! -- mvh // Jens M Andreasen From paul at linuxaudiosystems.com Fri Jan 27 07:54:00 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Jan 27 07:51:06 2006 Subject: [linux-audio-dev] xt2 coming to linux Message-ID: <1138366440.4214.126.camel@localhost.localdomain> Screenshot: http://www.kvraudio.com/forum/viewtopic.php? t=114488&postdays=0&postorder=asc&highlight=linux&start=105 i will be interested to see just how good its audio handling capabilities are. --p From core at jacklab.net Fri Jan 27 09:03:29 2006 From: core at jacklab.net (Michael Bohle) Date: Fri Jan 27 09:03:36 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <1138366440.4214.126.camel@localhost.localdomain> References: <1138366440.4214.126.camel@localhost.localdomain> Message-ID: <1138370609.5609.79.camel@jacklab.metanet> As far as i see Jorgen only want to support the obsolet OSS driver model and native VST Linux plugins... No chance for eXT on Linux... Did you ever hear about a native Linux VST-SDK ?(LOL) the screenshot that you can see there is only a w32.dll wrapped in dssi-vst. I don't like dssi-vst so much, too buggy, no midilearn etc. It dosn't work with fst 1.7 because of a graphical prob. Michael > Screenshot: > > http://www.kvraudio.com/forum/viewtopic.php? > t=114488&postdays=0&postorder=asc&highlight=linux&start=105 > > i will be interested to see just how good its audio handling > capabilities are. > > --p From cannam at all-day-breakfast.com Fri Jan 27 09:13:58 2006 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Fri Jan 27 09:13:46 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <1138370609.5609.79.camel@jacklab.metanet> References: <1138366440.4214.126.camel@localhost.localdomain> <1138370609.5609.79.camel@jacklab.metanet> Message-ID: <200601271413.58688.cannam@all-day-breakfast.com> On Friday 27 Jan 2006 14:03, Michael Bohle wrote: > I don't like dssi-vst so much, too buggy Your bug reports and fixes have been invaluable. > It dosn't work with fst 1.7 because of a graphical prob. I notice jacklab.net offers a binary distribution of libfst, and says "an experimental version of ardour-fst is in preparation". How do you deal with the licensing problem? Chris From paul at linuxaudiosystems.com Fri Jan 27 09:25:30 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Jan 27 09:22:35 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <200601271413.58688.cannam@all-day-breakfast.com> References: <1138366440.4214.126.camel@localhost.localdomain> <1138370609.5609.79.camel@jacklab.metanet> <200601271413.58688.cannam@all-day-breakfast.com> Message-ID: <1138371930.4214.135.camel@localhost.localdomain> On Fri, 2006-01-27 at 14:13 +0000, Chris Cannam wrote: > On Friday 27 Jan 2006 14:03, Michael Bohle wrote: > > I don't like dssi-vst so much, too buggy > > Your bug reports and fixes have been invaluable. > > > It dosn't work with fst 1.7 because of a graphical prob. > > I notice jacklab.net offers a binary distribution of libfst, and says "an > experimental version of ardour-fst is in preparation". How do you deal with > the licensing problem? an excellent question. i want to repeat and stress what is said within Ardour, but probably not clearly enough: It is illegal to distribute binaries of a GPL'ed application compiled with VST support. Illegal, OK? Don't do it. We didn't ask for this situation, but its the situation we have and nobody is going to be helped by people breaking licensing agreements. I would remind distributors that if you break the license in any way, you lose all ability to distribute a GPL'ed application at all. So please, don't do it. --p From jamesmichaelmcdermott at gmail.com Fri Jan 27 09:42:50 2006 From: jamesmichaelmcdermott at gmail.com (James McDermott) Date: Fri Jan 27 09:42:55 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <1138370609.5609.79.camel@jacklab.metanet> References: <1138366440.4214.126.camel@localhost.localdomain> <1138370609.5609.79.camel@jacklab.metanet> Message-ID: > As far as i see Jorgen only want to support the obsolet OSS driver model > and native VST Linux plugins... No chance for eXT on Linux... From the KVR forum (http://www.kvraudio.com/forum/viewtopic.php?t=114488): --- the midi/audio driver part of xt2 is open source, so anyone can add jack support for it (knowing c/c++ and jack that is). xt currently works with OSS only. Works great on kernel 2.6. I get very low latencies with it over here. --- I'm not sure about that... I thought there was no OSS in kernel 2.6? Anyway, looks positive doesn't it? From core at jacklab.net Fri Jan 27 09:47:44 2006 From: core at jacklab.net (Michael Bohle) Date: Fri Jan 27 09:47:53 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <1138371930.4214.135.camel@localhost.localdomain> References: <1138366440.4214.126.camel@localhost.localdomain> <1138370609.5609.79.camel@jacklab.metanet> <200601271413.58688.cannam@all-day-breakfast.com> <1138371930.4214.135.camel@localhost.localdomain> Message-ID: <1138373265.5609.86.camel@jacklab.metanet> OK, thank you Paul for saving our project... we cancel now vst support in any way. The binary will be deleted. Also LMMS will be informed because of the violation of the licences. Michael Am Freitag, den 27.01.2006, 09:25 -0500 schrieb Paul Davis: > On Fri, 2006-01-27 at 14:13 +0000, Chris Cannam wrote: > > On Friday 27 Jan 2006 14:03, Michael Bohle wrote: > > > I don't like dssi-vst so much, too buggy > > > > Your bug reports and fixes have been invaluable. > > > > > It dosn't work with fst 1.7 because of a graphical prob. > > > > I notice jacklab.net offers a binary distribution of libfst, and says "an > > experimental version of ardour-fst is in preparation". How do you deal with > > the licensing problem? > > an excellent question. i want to repeat and stress what is said within > Ardour, but probably not clearly enough: > > It is illegal to distribute binaries of a GPL'ed application > compiled with VST support. > > Illegal, OK? Don't do it. We didn't ask for this situation, but its the > situation we have and nobody is going to be helped by people breaking > licensing agreements. I would remind distributors that if you break the > license in any way, you lose all ability to distribute a GPL'ed > application at all. So please, don't do it. > > --p > > From paul at linuxaudiosystems.com Fri Jan 27 09:59:20 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Jan 27 09:56:25 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: References: <1138366440.4214.126.camel@localhost.localdomain> <1138370609.5609.79.camel@jacklab.metanet> Message-ID: <1138373960.4214.139.camel@localhost.localdomain> On Fri, 2006-01-27 at 14:42 +0000, James McDermott wrote: > > As far as i see Jorgen only want to support the obsolet OSS driver model > > and native VST Linux plugins... No chance for eXT on Linux... > > From the KVR forum (http://www.kvraudio.com/forum/viewtopic.php?t=114488): > > --- > the midi/audio driver part of xt2 is open source, so anyone can add > jack support for it (knowing c/c++ and jack that is). xt currently > works with OSS only. Works great on kernel 2.6. I get very low > latencies with it over here. > --- > > I'm not sure about that... I thought there was no OSS in kernel 2.6? > Anyway, looks positive doesn't it? fer cryin out loud, will you guys *look* at the screenshot! it already has JACK working! From core at jacklab.net Fri Jan 27 09:57:11 2006 From: core at jacklab.net (Michael Bohle) Date: Fri Jan 27 09:57:34 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <200601271413.58688.cannam@all-day-breakfast.com> References: <1138366440.4214.126.camel@localhost.localdomain> <1138370609.5609.79.camel@jacklab.metanet> <200601271413.58688.cannam@all-day-breakfast.com> Message-ID: <1138373831.5609.96.camel@jacklab.metanet> Am Freitag, den 27.01.2006, 14:13 +0000 schrieb Chris Cannam: > On Friday 27 Jan 2006 14:03, Michael Bohle wrote: > > I don't like dssi-vst so much, too buggy > > Your bug reports and fixes have been invaluable. Sorry for this harsh words: dssi-vst needing very old wine for compiling and there is no development happens since long time. The "bugs" are mostly because of missing impelentations of some vst standards like sync to host or heavy freezes when activating any kind of midi learn within the vst. u know that ;) But anyway, VST on Linux is dead now, beause most of the user are not able to compile it for themself. Thats pity, what can we do now? > > > It dosn't work with fst 1.7 because of a graphical prob. > > I notice jacklab.net offers a binary distribution of libfst, and says "an > experimental version of ardour-fst is in preparation". How do you deal with > the licensing problem? As I write to Paul... We giving up VST Support in any way. Michael > > > Chris From core at jacklab.net Fri Jan 27 10:03:59 2006 From: core at jacklab.net (Michael Bohle) Date: Fri Jan 27 10:04:06 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: References: <1138366440.4214.126.camel@localhost.localdomain> <1138370609.5609.79.camel@jacklab.metanet> Message-ID: <1138374240.5609.102.camel@jacklab.metanet> Am Freitag, den 27.01.2006, 14:42 +0000 schrieb James McDermott: > > As far as i see Jorgen only want to support the obsolet OSS driver model > > and native VST Linux plugins... No chance for eXT on Linux... > > From the KVR forum (http://www.kvraudio.com/forum/viewtopic.php?t=114488): > > --- > the midi/audio driver part of xt2 is open source, so anyone can add > jack support for it (knowing c/c++ and jack that is). xt currently > works with OSS only. Works great on kernel 2.6. I get very low > latencies with it over here. > --- > > I'm not sure about that... I thought there was no OSS in kernel 2.6? > Anyway, looks positive doesn't it? As I heard from eXT on Linux, I bought a licence f?r eXT for my Windows DAW. It is a fantastic little programm, very stable and full of nice features. I really hope that the linux port will be a great one - but I see Ardour with (hopefully soon with midisupport) and so I dont see so much chances for an eXT without Jack support. Michael From core at jacklab.net Fri Jan 27 10:10:07 2006 From: core at jacklab.net (Michael Bohle) Date: Fri Jan 27 10:10:16 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <1138373960.4214.139.camel@localhost.localdomain> References: <1138366440.4214.126.camel@localhost.localdomain> <1138370609.5609.79.camel@jacklab.metanet> <1138373960.4214.139.camel@localhost.localdomain> Message-ID: <1138374607.5609.107.camel@jacklab.metanet> Am Freitag, den 27.01.2006, 09:59 -0500 schrieb Paul Davis: > On Fri, 2006-01-27 at 14:42 +0000, James McDermott wrote: > > > As far as i see Jorgen only want to support the obsolet OSS driver model > > > and native VST Linux plugins... No chance for eXT on Linux... > > > > From the KVR forum (http://www.kvraudio.com/forum/viewtopic.php?t=114488): > > > > --- > > the midi/audio driver part of xt2 is open source, so anyone can add > > jack support for it (knowing c/c++ and jack that is). xt currently > > works with OSS only. Works great on kernel 2.6. I get very low > > latencies with it over here. > > --- > > > > I'm not sure about that... I thought there was no OSS in kernel 2.6? > > Anyway, looks positive doesn't it? > > fer cryin out loud, will you guys *look* at the screenshot! > it already has JACK working! Hmm, must have something on my eyes, see only screenshots with dssi-vst wrapping eXT. OK, dssi-vst working as a Jackclient... but where for hell is the screenshot of a native build of a jackified eXT? Can you post the exact url? Michael > From cannam at all-day-breakfast.com Fri Jan 27 10:13:50 2006 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Fri Jan 27 10:13:33 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <1138373831.5609.96.camel@jacklab.metanet> References: <1138366440.4214.126.camel@localhost.localdomain> <200601271413.58688.cannam@all-day-breakfast.com> <1138373831.5609.96.camel@jacklab.metanet> Message-ID: <200601271513.50815.cannam@all-day-breakfast.com> On Friday 27 Jan 2006 14:57, Michael Bohle wrote: > Sorry for this harsh words: dssi-vst needing very old wine for compiling > and there is no development happens since long time. > The "bugs" are mostly because of missing impelentations of some vst > standards like sync to host or heavy freezes when activating any kind of > midi learn within the vst. Fixes, including build fixes, are always welcome. So are specific examples of VST features that would be useful. Some VST features don't map well onto DSSI at all (e.g. I haven't yet thought of a good way of handling VST chunks: any ideas welcome) but others aren't there just because I haven't found the time to deal with them. > But anyway, VST on Linux is dead now, beause most of the user are not > able to compile it for themself. Thats pity, what can we do now? Distribute binaries of dssi-vst. That's one reason it exists in the first place. It won't solve all your problems, but it's better than nothing. Honestly, none of this is news. Even the jacklab.net site itself makes reference to the licensing problem... at the same time as ignoring it. Chris From paul at linuxaudiosystems.com Fri Jan 27 10:28:26 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Jan 27 10:25:31 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <1138374607.5609.107.camel@jacklab.metanet> References: <1138366440.4214.126.camel@localhost.localdomain> <1138370609.5609.79.camel@jacklab.metanet> <1138373960.4214.139.camel@localhost.localdomain> <1138374607.5609.107.camel@jacklab.metanet> Message-ID: <1138375706.4214.141.camel@localhost.localdomain> > > fer cryin out loud, will you guys *look* at the screenshot! > > it already has JACK working! > > Hmm, must have something on my eyes, see only screenshots with dssi-vst > wrapping eXT. OK, dssi-vst working as a Jackclient... but where for hell > is the screenshot of a native build of a jackified eXT? Can you post the > exact url? *blush* my mistake. i don't use dssi-vst, so i did not realize that the presence of xt2 qjackctl's connections was created that way. many apologies for being so rude. --p From thockin at hockin.org Fri Jan 27 11:29:51 2006 From: thockin at hockin.org (thockin@hockin.org) Date: Fri Jan 27 11:25:24 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <1138375706.4214.141.camel@localhost.localdomain> References: <1138366440.4214.126.camel@localhost.localdomain> <1138370609.5609.79.camel@jacklab.metanet> <1138373960.4214.139.camel@localhost.localdomain> <1138374607.5609.107.camel@jacklab.metanet> <1138375706.4214.141.camel@localhost.localdomain> Message-ID: <20060127162951.GA16302@hockin.org> On Fri, Jan 27, 2006 at 10:28:26AM -0500, Paul Davis wrote: > > > fer cryin out loud, will you guys *look* at the screenshot! > > > it already has JACK working! > > > > Hmm, must have something on my eyes, see only screenshots with dssi-vst > > wrapping eXT. OK, dssi-vst working as a Jackclient... but where for hell > > is the screenshot of a native build of a jackified eXT? Can you post the > > exact url? > > *blush* > > my mistake. i don't use dssi-vst, so i did not realize that the presence > of xt2 qjackctl's connections was created that way. > > many apologies for being so rude. in another thread, Jorgen said that the input/output part of eXT on Linux will be Open Source, so the JACK wizards can JACKify it as soon as it is released. As for VST only, eek. From mista.tapas at gmx.net Fri Jan 27 12:38:16 2006 From: mista.tapas at gmx.net (Florian Schmidt) Date: Fri Jan 27 12:38:29 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <20060127162951.GA16302@hockin.org> References: <1138366440.4214.126.camel@localhost.localdomain> <1138370609.5609.79.camel@jacklab.metanet> <1138373960.4214.139.camel@localhost.localdomain> <1138374607.5609.107.camel@jacklab.metanet> <1138375706.4214.141.camel@localhost.localdomain> <20060127162951.GA16302@hockin.org> Message-ID: <20060127183816.5d530b6f@mango.fruits.de> On Fri, 27 Jan 2006 08:29:51 -0800 thockin@hockin.org wrote: > in another thread, Jorgen said that the input/output part of eXT on Linux > will be Open Source, so the JACK wizards can JACKify it as soon as it is > released. Why would anyone do this? To generate more revenue for the author? This is not really how open source works. Well, people might do this to help out their fellow users, but for me above would leave a bitter taste. Flo -- Palimm Palimm! http://tapas.affenbande.org From thockin at hockin.org Fri Jan 27 13:02:06 2006 From: thockin at hockin.org (thockin@hockin.org) Date: Fri Jan 27 12:57:20 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <20060127183816.5d530b6f@mango.fruits.de> References: <1138366440.4214.126.camel@localhost.localdomain> <1138370609.5609.79.camel@jacklab.metanet> <1138373960.4214.139.camel@localhost.localdomain> <1138374607.5609.107.camel@jacklab.metanet> <1138375706.4214.141.camel@localhost.localdomain> <20060127162951.GA16302@hockin.org> <20060127183816.5d530b6f@mango.fruits.de> Message-ID: <20060127180206.GA21796@hockin.org> On Fri, Jan 27, 2006 at 06:38:16PM +0100, Florian Schmidt wrote: > On Fri, 27 Jan 2006 08:29:51 -0800 > thockin@hockin.org wrote: > > > in another thread, Jorgen said that the input/output part of eXT on Linux > > will be Open Source, so the JACK wizards can JACKify it as soon as it is > > released. > > Why would anyone do this? To generate more revenue for the author? This > is not really how open source works. > > Well, people might do this to help out their fellow users, but for me > above would leave a bitter taste. I would do it so that I have a potentially viable alternative to the current state of affairs, which is that I boot windows to do music. eXT is a decent program. The reason we don't get commercial apps on Linux is because no one buys them. Linux folks want everything free. I am as big a believer in Open Source as anyone else here. But I am also a pragmatist, and until such time as a viable free alternative exists, I have to use commercial apps. Given that, would I rather use and support a commercial app that runs on Windows only or one that runs on Linux, too? If you can't cope with the idea that someone makes a living doing software, don't buy eXT, don't help Jorgen, and just ignore it. I, for one, will do anything I can to help him make Linux into a competitive migration path for Windows users. Now, the problem is plugins - VST only? eek. Tim From rlrevell at joe-job.com Fri Jan 27 13:37:03 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Jan 27 13:37:30 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: References: <1138366440.4214.126.camel@localhost.localdomain> <1138370609.5609.79.camel@jacklab.metanet> Message-ID: <1138387023.3131.10.camel@mindpipe> On Fri, 2006-01-27 at 14:42 +0000, James McDermott wrote: > the midi/audio driver part of xt2 is open source, so anyone can add > jack support for it (knowing c/c++ and jack that is). xt currently > works with OSS only. Works great on kernel 2.6. I get very low > latencies with it over here. AAARRRRRHRRRGGGGGHHHHHHH From rlrevell at joe-job.com Fri Jan 27 13:39:36 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Jan 27 13:39:42 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <1138373831.5609.96.camel@jacklab.metanet> References: <1138366440.4214.126.camel@localhost.localdomain> <1138370609.5609.79.camel@jacklab.metanet> <200601271413.58688.cannam@all-day-breakfast.com> <1138373831.5609.96.camel@jacklab.metanet> Message-ID: <1138387176.3131.13.camel@mindpipe> On Fri, 2006-01-27 at 15:57 +0100, Michael Bohle wrote: > But anyway, VST on Linux is dead now, beause most of the user are not > able to compile it for themself. Wrong. You just need to write a wrapper that handles the compiling. Look how many people use the Nvidia driver, where the licensing also requires it to be compiled during the install process. Lee From rlrevell at joe-job.com Fri Jan 27 13:42:43 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Jan 27 13:42:50 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <20060127162951.GA16302@hockin.org> References: <1138366440.4214.126.camel@localhost.localdomain> <1138370609.5609.79.camel@jacklab.metanet> <1138373960.4214.139.camel@localhost.localdomain> <1138374607.5609.107.camel@jacklab.metanet> <1138375706.4214.141.camel@localhost.localdomain> <20060127162951.GA16302@hockin.org> Message-ID: <1138387363.3131.17.camel@mindpipe> On Fri, 2006-01-27 at 08:29 -0800, thockin@hockin.org wrote: > in another thread, Jorgen said that the input/output part of eXT on > Linux will be Open Source, so the JACK wizards can JACKify it as soon > as it is released. It's frustrating that most audio application writers STILL consider OSS a sane default, it just waste's everyone's time (see also Skype). OSS has been deprecated for years... Lee From chris.cannam at ferventsoftware.com Fri Jan 27 14:21:11 2006 From: chris.cannam at ferventsoftware.com (Chris Cannam) Date: Fri Jan 27 14:23:55 2006 Subject: [linux-audio-dev] xt2 coming to linux Message-ID: <178703520-1138389817-cardhu_blackberry.rim.net-2612-@engine03.bwc.produk.on.blackberry> Lee Revell writes: > On Fri, 2006-01-27 at 15:57 +0100, Michael Bohle wrote: > > But anyway, VST on Linux is dead now, beause > > most of the user are not > > able to compile it for themself. > > Wrong. You just need to write a wrapper that > handles the compiling. Won't help if the code is to be part of a GPL'd application. Also, I think (?) you have to register to download the VSTSDK. Chris From rlrevell at joe-job.com Fri Jan 27 14:37:55 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Jan 27 14:38:01 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <178703520-1138389817-cardhu_blackberry.rim.net-2612-@engine03.bwc.produk.on.blackberry> References: <178703520-1138389817-cardhu_blackberry.rim.net-2612-@engine03.bwc.produk.on.blackberry> Message-ID: <1138390676.3131.32.camel@mindpipe> On Fri, 2006-01-27 at 19:21 +0000, Chris Cannam wrote: > Lee Revell writes: > > On Fri, 2006-01-27 at 15:57 +0100, Michael Bohle wrote: > > > But anyway, VST on Linux is dead now, beause > > > most of the user are not > > > able to compile it for themself. > > > > Wrong. You just need to write a wrapper that > > handles the compiling. > > Won't help if the code is to be part of a GPL'd > application. > The Linux kernel is a GPL'ed application yet Nvidia gets away with linking into it. It's widely acknowledged to be illegal, but as the linking is done by the end user, it's the user who violates the GPL, not Nvidia. > Also, I think (?) you have to register to download the > VSTSDK. > > > Chris > From musical_snake at gmx.de Fri Jan 27 14:36:57 2006 From: musical_snake at gmx.de (Ralf Beck) Date: Fri Jan 27 14:38:29 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <178703520-1138389817-cardhu_blackberry.rim.net-2612-@engine03.bwc.produk.on.blackberry> References: <178703520-1138389817-cardhu_blackberry.rim.net-2612-@engine03.bwc.produk.on.blackberry> Message-ID: <43DA7659.3010709@gmx.de> You can always write a non-GPL VST host and connect it to a GPLed app using a socket, fifo .. whatever else, without breaking any license. That GPLed app can be a jack client, of course. From richard.spindler at gmail.com Fri Jan 27 14:43:52 2006 From: richard.spindler at gmail.com (Richard Spindler) Date: Fri Jan 27 14:43:56 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <1138387363.3131.17.camel@mindpipe> References: <1138366440.4214.126.camel@localhost.localdomain> <1138370609.5609.79.camel@jacklab.metanet> <1138373960.4214.139.camel@localhost.localdomain> <1138374607.5609.107.camel@jacklab.metanet> <1138375706.4214.141.camel@localhost.localdomain> <20060127162951.GA16302@hockin.org> <1138387363.3131.17.camel@mindpipe> Message-ID: <4af8d6ff0601271143i1d8287bdm@mail.gmail.com> 2006/1/27, Lee Revell : > It's frustrating that most audio application writers STILL consider OSS > a sane default, it just waste's everyone's time (see also Skype). OSS > has been deprecated for years... Well, honestly I have to admit that I'm guilty of that too. why? Because of portaudio, it's propably on of the most convinient ways to use an audio API. And unfortunatly it only provides OSS in Version 18, which is what I use. I took a peek into v19, that has ALSA Support, but it became just too complex. The only alternative would be jack, but since I'm only doing simple applications, I don't need to run jack, and I do not expect my users to do so either. Writing against the native ALSA API is a pain, because it requires much more low level stuff, that I don't really care for. And on top of that it'd also require me to setup my own thread for the callback mechanism. I guess I'm just to lazy. ;) -Richard From rlrevell at joe-job.com Fri Jan 27 15:02:14 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Jan 27 15:02:29 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <4af8d6ff0601271143i1d8287bdm@mail.gmail.com> References: <1138366440.4214.126.camel@localhost.localdomain> <1138370609.5609.79.camel@jacklab.metanet> <1138373960.4214.139.camel@localhost.localdomain> <1138374607.5609.107.camel@jacklab.metanet> <1138375706.4214.141.camel@localhost.localdomain> <20060127162951.GA16302@hockin.org> <1138387363.3131.17.camel@mindpipe> <4af8d6ff0601271143i1d8287bdm@mail.gmail.com> Message-ID: <1138392135.3131.35.camel@mindpipe> On Fri, 2006-01-27 at 20:43 +0100, Richard Spindler wrote: > 2006/1/27, Lee Revell : > > It's frustrating that most audio application writers STILL consider OSS > > a sane default, it just waste's everyone's time (see also Skype). OSS > > has been deprecated for years... > > Well, honestly I have to admit that I'm guilty of that too. why? > > Because of portaudio, it's propably on of the most convinient ways > to use an audio API. And unfortunatly it only provides OSS in Version > 18, which is what I use. I took a peek into v19, that has ALSA Support, > but it became just too complex. > Um, I thought the whole point of portaudio is you don't write your application to the OSS or ALSA API, you write to the PortAudio API and don't have to worry about the low level sound system? > The only alternative would be jack, but since I'm only doing simple > applications, I don't need to run jack, and I do not expect my users to do > so either. > > Writing against the native ALSA API is a pain, because it requires much > more low level stuff, that I don't really care for. And on top of that it'd also > require me to setup my own thread for the callback mechanism. > ALSA supports standard read/write access just like OSS. > I guess I'm just to lazy. ;) > > -Richard > From mle+la at mega-nerd.com Fri Jan 27 15:05:10 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Fri Jan 27 15:05:37 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <1138390676.3131.32.camel@mindpipe> References: <178703520-1138389817-cardhu_blackberry.rim.net-2612-@engine03.bwc.produk.on.blackberry> <1138390676.3131.32.camel@mindpipe> Message-ID: <20060128070510.65f67596.mle+la@mega-nerd.com> Lee Revell wrote: > The Linux kernel is a GPL'ed application yet Nvidia gets away with > linking into it. It's widely acknowledged to be illegal, but as the > linking is done by the end user, it's the user who violates the GPL, not > Nvidia. The end user would only be violating the GPL if they distributed the kernel with the Nvidia kernel. The GPL bestows more freedom to the user than it does to the distributor of GPL software. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Allaah has forbidden the believers to take the kaafireen (disbelievers) as friends, and He has issued a stern warning against doing that." -- http://islamqa.com/index.php?ln=eng&ds=qa&lv=browse&QR=59879&dgn=4 From richard.spindler at gmail.com Fri Jan 27 15:09:54 2006 From: richard.spindler at gmail.com (Richard Spindler) Date: Fri Jan 27 15:09:58 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <1138392135.3131.35.camel@mindpipe> References: <1138366440.4214.126.camel@localhost.localdomain> <1138370609.5609.79.camel@jacklab.metanet> <1138373960.4214.139.camel@localhost.localdomain> <1138374607.5609.107.camel@jacklab.metanet> <1138375706.4214.141.camel@localhost.localdomain> <20060127162951.GA16302@hockin.org> <1138387363.3131.17.camel@mindpipe> <4af8d6ff0601271143i1d8287bdm@mail.gmail.com> <1138392135.3131.35.camel@mindpipe> Message-ID: <4af8d6ff0601271209q69f1e980y@mail.gmail.com> 2006/1/27, Lee Revell : > Um, I thought the whole point of portaudio is you don't write your > application to the OSS or ALSA API, you write to the PortAudio API and > don't have to worry about the low level sound system? Well, but there IS no ALSA backend in Portaudio v18 -Richard From paul at linuxaudiosystems.com Fri Jan 27 16:11:09 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Jan 27 16:08:14 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <4af8d6ff0601271143i1d8287bdm@mail.gmail.com> References: <1138366440.4214.126.camel@localhost.localdomain> <1138370609.5609.79.camel@jacklab.metanet> <1138373960.4214.139.camel@localhost.localdomain> <1138374607.5609.107.camel@jacklab.metanet> <1138375706.4214.141.camel@localhost.localdomain> <20060127162951.GA16302@hockin.org> <1138387363.3131.17.camel@mindpipe> <4af8d6ff0601271143i1d8287bdm@mail.gmail.com> Message-ID: <1138396269.4214.162.camel@localhost.localdomain> On Fri, 2006-01-27 at 20:43 +0100, Richard Spindler wrote: > Writing against the native ALSA API is a pain, because it requires much > more low level stuff, that I don't really care for. And on top of that it'd also > require me to setup my own thread for the callback mechanism. i thought this too until i actually tried to write a minimal OSS- equivalent ALSA app. the number of calls vs. OSS is almost exactly the same, the only difference is the length of the function names (snd_pcm_read() vs. read()). there are certain basic things that any app using a HAL has to control, and the way ALSA and OSS do it doesn't change that very much at all. --p From mista.tapas at gmx.net Fri Jan 27 16:29:43 2006 From: mista.tapas at gmx.net (Florian Schmidt) Date: Fri Jan 27 16:29:49 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <20060127180206.GA21796@hockin.org> References: <1138366440.4214.126.camel@localhost.localdomain> <1138370609.5609.79.camel@jacklab.metanet> <1138373960.4214.139.camel@localhost.localdomain> <1138374607.5609.107.camel@jacklab.metanet> <1138375706.4214.141.camel@localhost.localdomain> <20060127162951.GA16302@hockin.org> <20060127183816.5d530b6f@mango.fruits.de> <20060127180206.GA21796@hockin.org> Message-ID: <20060127222943.6d806f2e@mango.fruits.de> On Fri, 27 Jan 2006 10:02:06 -0800 thockin@hockin.org wrote: > I would do it so that I have a potentially viable alternative to the > current state of affairs, which is that I boot windows to do music. > > eXT is a decent program. The reason we don't get commercial apps on Linux > is because no one buys them. Linux folks want everything free. > > I am as big a believer in Open Source as anyone else here. But I am also > a pragmatist, and until such time as a viable free alternative exists, I > have to use commercial apps. Given that, would I rather use and support a > commercial app that runs on Windows only or one that runs on Linux, too? > > If you can't cope with the idea that someone makes a living doing > software, don't buy eXT, don't help Jorgen, and just ignore it. I, for > one, will do anything I can to help him make Linux into a competitive > migration path for Windows users. Oh i can live perfectly well with the idea of people making a living doing linux software. I myself code linux apps for money. But i have a problem with opening parts of it as open source in the hope that users fill in the blanks. Users that have to pay for the software in the first place. Well you might argue that you can get the open source part free. Yeah, but it's useless without the pay package. But this is just my personal opinion. Besides. Depending on the app design adding jack support is dead simple. Have fun, Flo -- Palimm Palimm! http://tapas.affenbande.org From ix at replic.net Fri Jan 27 17:57:08 2006 From: ix at replic.net (cdr) Date: Fri Jan 27 17:57:20 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <200601271513.50815.cannam@all-day-breakfast.com> References: <1138366440.4214.126.camel@localhost.localdomain> <200601271413.58688.cannam@all-day-breakfast.com> <1138373831.5609.96.camel@jacklab.metanet> <200601271513.50815.cannam@all-day-breakfast.com> Message-ID: <20060127225708.GC20856@replic.net> > Fixes, including build fixes, are always welcome. So are specific examples of > VST features that would be useful. Some VST features don't map well onto > DSSI at all (e.g. I haven't yet thought of a good way of handling VST chunks: > any ideas welcome) you mean the chunks of binary data that were permitted since the parameter structure in VST is so limited that it cant contain anything beside a float bound between 0.0 and 1.0? id hope one would expose that via OSC instead, so that it can be changed somewhere besides the plugin GUI, and since its protocol should allow all the things that couldnt be squeezed into a VST param: filenames, integers, patchnames etc... From chris.cannam at ferventsoftware.com Fri Jan 27 18:04:21 2006 From: chris.cannam at ferventsoftware.com (Chris Cannam) Date: Fri Jan 27 18:07:08 2006 Subject: [linux-audio-dev] xt2 coming to linux Message-ID: <1519814472-1138403207-cardhu_blackberry.rim.net-23694-@engine34.bwc.produk.on.blackberry> Lee Revell: > > Won't help if the code is to be part of a GPL'd > > application. > > The Linux kernel is a GPL'ed application yet Nvidia > gets away with linking into it. Quite different. Anyone can distribute the kernel without caring about the existence of the nVidia drivers. But if an application includes the VSTSDK, it presumably isn't complete without it. Chris From rlrevell at joe-job.com Fri Jan 27 18:21:40 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Jan 27 18:21:46 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <1519814472-1138403207-cardhu_blackberry.rim.net-23694-@engine34.bwc.produk.on.blackberry> References: <1519814472-1138403207-cardhu_blackberry.rim.net-23694-@engine34.bwc.produk.on.blackberry> Message-ID: <1138404101.3131.58.camel@mindpipe> On Fri, 2006-01-27 at 23:04 +0000, Chris Cannam wrote: > Lee Revell: > > > Won't help if the code is to be part of a GPL'd > > > application. > > > > The Linux kernel is a GPL'ed application yet Nvidia > > gets away with linking into it. > > Quite different. Anyone can distribute the kernel > without caring about the existence of the nVidia > drivers. But if an application includes the VSTSDK, it > presumably isn't complete without it. > Maybe the application just has hooks for the VST SDK, and a network installer downloads and compiles it on the users machine? I guess Steinberg might consider this a form of distribution. Lee From paul at linuxaudiosystems.com Fri Jan 27 19:04:57 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Jan 27 19:02:02 2006 Subject: [linux-audio-dev] xt2 coming to linux In-Reply-To: <1138404101.3131.58.camel@mindpipe> References: <1519814472-1138403207-cardhu_blackberry.rim.net-23694-@engine34.bwc.produk.on.blackberry> <1138404101.3131.58.camel@mindpipe> Message-ID: <1138406697.14476.10.camel@localhost.localdomain> On Fri, 2006-01-27 at 18:21 -0500, Lee Revell wrote: > On Fri, 2006-01-27 at 23:04 +0000, Chris Cannam wrote: > > Lee Revell: > > > > Won't help if the code is to be part of a GPL'd > > > > application. > > > > > > The Linux kernel is a GPL'ed application yet Nvidia > > > gets away with linking into it. > > > > Quite different. Anyone can distribute the kernel > > without caring about the existence of the nVidia > > drivers. But if an application includes the VSTSDK, it > > presumably isn't complete without it. > > > > Maybe the application just has hooks for the VST SDK, and a network > installer downloads and compiles it on the users machine? I guess > Steinberg might consider this a form of distribution. given that even human downloading requires email requests for help to be sent to the vst-plugins list, it seems unlikely that a network installer is going to be feasible. steinberg's ability to maintain a viable, consistent download point is laughable. --p From kjetil at ccrma.stanford.edu Sat Jan 28 00:45:35 2006 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Sat Jan 28 00:45:42 2006 Subject: [linux-audio-dev] Ladspa GUIs (Was Re: [linux-audio-user] Acid type program Message-ID: Reuben Martin: >> (Why hasn't anyone made a ladspa plugin with a GUI by the way? Its >> really simple just spawning of a gui process program.) >> > >Because you have no way of knowing if the platform you are running it > No no, you misunderstand. I said "spawning of a gui process" (I should rather have said "spawning off a gui process", but I didn't. :-) ). Well, I guess the question was more retorical. I personally think reason is that linux programmers aren't that much into bells and whistles as windows programmers. >on will have support for the toolkit needed by the GUI. It would be >nice to append the LADSPA spec to allow for a simple markup language >to describe the GUI, and then depend on the host to render that markup >language into a GUI. It would make it toolkit independent. No, that would not be nice at all. Far too complicated for the hosts, and guis would be different from host to host, and limited by the markup language What would be nice was if we used a common gui-designer like qdesigner or glade, so that someone could make an automatic gui-spawner library that used the xml-files from qdesigner or glade to make guis. That way, anyone could make/edit gui's quite easely. The idea was proposed some years ago, but no one has picked it up. Its not much work to do, but I guess no one has got the time. It must be a community project as well, because it would be useless if no one bothered to make guis for the various plug-ins or the hosts didn't support it. (well, the host-problem could be fixed automatically by making a wrapper ladspa plugin, but its not the ideal solution) From S.W.Harris at ecs.soton.ac.uk Sat Jan 28 05:03:15 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Jan 28 05:03:28 2006 Subject: [linux-audio-dev] Ladspa GUIs (Was Re: [linux-audio-user] Acid type program In-Reply-To: References: Message-ID: <20060128100315.GA7055@login.ecs.soton.ac.uk> On Fri, Jan 27, 2006 at 09:45:35 -0800, Kjetil S. Matheussen wrote: > > Reuben Martin: > > >>(Why hasn't anyone made a ladspa plugin with a GUI by the way? Its > >>really simple just spawning of a gui process program.) They have, it can be done via the DSSI API. > >Because you have no way of knowing if the platform you are running it > > No no, you misunderstand. I said "spawning of a gui process" (I should > rather have said "spawning off a gui process", but I didn't. :-) ). > Well, I guess the question was more retorical. I personally think reason > is that linux programmers aren't that much into bells and whistles as > windows programmers. That is certainly true. > >on will have support for the toolkit needed by the GUI. It would be > >nice to append the LADSPA spec to allow for a simple markup language > >to describe the GUI, and then depend on the host to render that markup > >language into a GUI. It would make it toolkit independent. > > No, that would not be nice at all. Far too complicated for the hosts, and > guis would be different from host to host, and limited by the markup > language > > What would be nice was if we used a common gui-designer like qdesigner > or glade, so that someone could make an automatic gui-spawner library > that used the xml-files from qdesigner or glade to make guis. That way, ... I did consider that quite hard, but its really hard to come up with a 90% solution that is even vaguely practical, and doesn't limit implementation choices too much. The DSSI solution is quite neat because using only glade (or the Qt equivalent), an OSC library and a tiny bit of glue code you can build a GUI. For the kind of simple UIs youre talking about the glue code could be autogenerated. Also, the impact on the host is minimal. - Steve From luisgarrido at users.sourceforge.net Sat Jan 28 13:14:59 2006 From: luisgarrido at users.sourceforge.net (Luis Garrido) Date: Sat Jan 28 13:15:03 2006 Subject: [linux-audio-dev] Ladspa GUIs (Was Re: [linux-audio-user] Acid type program In-Reply-To: <20060128100315.GA7055@login.ecs.soton.ac.uk> References: <20060128100315.GA7055@login.ecs.soton.ac.uk> Message-ID: I have a LADSPA/DSSI GUI builder going on at http://flam.sourceforge.net/ which is conceived around qt designer. It is far for complete and I don't think I can dedicate substantial time to it until the summer. I am also concerned about the need to migrate to QT4. The only fully functional part I have managed to finish is flamwizard, a program that displays a list of the installed LADSPA plugins and generates a skeleton ui file ready to be edited in qt designer. Comments and contributions very welcome. Cheers, Luis On 1/28/06, Steve Harris wrote: > On Fri, Jan 27, 2006 at 09:45:35 -0800, Kjetil S. Matheussen wrote: > > > > Reuben Martin: > > > > >>(Why hasn't anyone made a ladspa plugin with a GUI by the way? Its > > >>really simple just spawning of a gui process program.) > > They have, it can be done via the DSSI API. > From capocasa at gmx.net Sat Jan 28 16:58:27 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Sat Jan 28 16:55:44 2006 Subject: [linux-audio-dev] Re: C++ Keyboard Event Handling In-Reply-To: References: Message-ID: I believe I have found the solution here in the form of libgii which wraps raw keyboard input into a nice, modular and extensible abstraction library. Thanks for everyone who participated, I gained much valuable information from the thread which culminated in finding the right library! Carlo From rlrevell at joe-job.com Sun Jan 29 01:05:12 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sun Jan 29 01:05:17 2006 Subject: [linux-audio-dev] LADSPA AC3 encoder? Message-ID: <1138514712.2799.77.camel@mindpipe> Question for the DSP gurus: How hard would it be to implement an AC3 encoder as a LADSPA plugin that could be used in an ALSA config to encode stereo and 5.1 sources on the fly? Many Windows drivers seem to contain one, and it would be a nice response to the naysayers on LKML who doubt the power of ALSA. It appears that a simple AC3 encoder is ~1500 lines of code: http://www.koders.com/c/fid04210C5E2BC83FC0BA5E0A2A1C37D52503E31EFD.aspx http://www.telos.de/Surround_Sound_Formats.360.0.html#1051 FWIW, when emu10k1/2 based cards first came out Creative claimed the DSP was powerful enough to do AC3 encoding on the fly, but, they never shipped an implementation - their drivers did it in software. One of their engineers said the DSP wasn't suited for the frequency domain processing required to encode AC3. Lee From S.W.Harris at ecs.soton.ac.uk Sun Jan 29 06:14:58 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sun Jan 29 06:15:25 2006 Subject: [linux-audio-dev] LADSPA AC3 encoder? In-Reply-To: <1138514712.2799.77.camel@mindpipe> References: <1138514712.2799.77.camel@mindpipe> Message-ID: <20060129111458.GA18583@login.ecs.soton.ac.uk> On Sun, Jan 29, 2006 at 01:05:12 -0500, Lee Revell wrote: > Question for the DSP gurus: > > How hard would it be to implement an AC3 encoder as a LADSPA plugin that > could be used in an ALSA config to encode stereo and 5.1 sources on the > fly? Many Windows drivers seem to contain one, and it would be a nice > response to the naysayers on LKML who doubt the power of ALSA. You can't do it as a LADSPA plugin as the output format is binary, and theres a reencoding stage. It could be done as an ALSA lib plugin though I suspect. - Steve From jesse at essej.net Sun Jan 29 23:14:01 2006 From: jesse at essej.net (Jesse Chappell) Date: Sun Jan 29 23:14:09 2006 Subject: [linux-audio-dev] LADSPA AC3 encoder? In-Reply-To: <1138514712.2799.77.camel@mindpipe> References: <1138514712.2799.77.camel@mindpipe> Message-ID: On 1/29/06, Lee Revell wrote: > Question for the DSP gurus: > > How hard would it be to implement an AC3 encoder as a LADSPA plugin that > could be used in an ALSA config to encode stereo and 5.1 sources on the > fly? Many Windows drivers seem to contain one, and it would be a nice > response to the naysayers on LKML who doubt the power of ALSA. Have you seen my ac3jack? It needs some work, but can act as a bridge between jack and alsa (indirectly now, directly soon) and uses the ac3 encoder from ffmpeg. http://essej.net/ac3jack If pushed, I will fix it up as planned.... jlc From rlrevell at joe-job.com Sun Jan 29 23:38:20 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sun Jan 29 23:38:26 2006 Subject: [linux-audio-dev] LADSPA AC3 encoder? In-Reply-To: References: <1138514712.2799.77.camel@mindpipe> Message-ID: <1138595901.2799.133.camel@mindpipe> On Sun, 2006-01-29 at 23:14 -0500, Jesse Chappell wrote: > On 1/29/06, Lee Revell wrote: > > Question for the DSP gurus: > > > > How hard would it be to implement an AC3 encoder as a LADSPA plugin that > > could be used in an ALSA config to encode stereo and 5.1 sources on the > > fly? Many Windows drivers seem to contain one, and it would be a nice > > response to the naysayers on LKML who doubt the power of ALSA. > > Have you seen my ac3jack? It needs some work, but can act as a bridge > between jack and alsa (indirectly now, directly soon) and uses the ac3 > encoder from ffmpeg. > http://essej.net/ac3jack > > If pushed, I will fix it up as planned.... Yes, I did. I was thinking it would be nice to be able to offer this as an alsa-lib plugin. Lee From sbenno at gardena.net Mon Jan 30 05:29:20 2006 From: sbenno at gardena.net (Benno Senoner) Date: Mon Jan 30 05:18:05 2006 Subject: [linux-audio-dev] LAD site, linuxdj.com needs a new home Message-ID: <43DDEA80.40907@gardena.net> Hi LADers, During the last months the LAD website ( http://www.linuxdj.com/audio/lad ) was hosted on the lionstracs.com server. Domenico from Lionstracs told me that he does not want do host the LAD site anymore since it consumes so much bandwidth, 200 GB in January, see here. http://www.linuxdj.com/webstat1/ its probably due to the audio/video material from the conferences (100MB a pop). Anyone willing to host the site ? As I did in the last years, I'll pay the for the linuxdj.com domain fees. cheers, Benno From tiwai at suse.de Mon Jan 30 05:27:40 2006 From: tiwai at suse.de (Takashi Iwai) Date: Mon Jan 30 05:27:51 2006 Subject: [linux-audio-dev] Re: LADSPA AC3 encoder? In-Reply-To: <1138514712.2799.77.camel@mindpipe> References: <1138514712.2799.77.camel@mindpipe> Message-ID: At Sun, 29 Jan 2006 01:05:12 -0500, Lee Revell wrote: > > Question for the DSP gurus: > > How hard would it be to implement an AC3 encoder as a LADSPA plugin that > could be used in an ALSA config to encode stereo and 5.1 sources on the > fly? Many Windows drivers seem to contain one, and it would be a nice > response to the naysayers on LKML who doubt the power of ALSA. > > It appears that a simple AC3 encoder is ~1500 lines of code: > > http://www.koders.com/c/fid04210C5E2BC83FC0BA5E0A2A1C37D52503E31EFD.aspx > > http://www.telos.de/Surround_Sound_Formats.360.0.html#1051 Technically it wouldn't be hard to write an ac3 encoder. Actually I wrote once a simple encoder by cutting down from the ffmpeg code. However, the question is rather a legal one. It's very unlikely that you can use it free (at least for distros). BTW, the naysayers can always say no. You could implement it in the kernel space, too ;) Takashi From ix at replic.net Mon Jan 30 06:13:26 2006 From: ix at replic.net (cdr) Date: Mon Jan 30 06:13:41 2006 Subject: [linux-audio-dev] open standards for file formats Message-ID: <20060130111326.GA21697@replic.net> i know design by committee can be horrible but these situations usually utilize vastly similar yet incompatible formats, so its sort of biting off something small, i hope.. :) (1) Peak Files some of my favorite wav files have 10 metafiles each. peaks generated for peak, spark, wavelab, soundforge, cubase, ableton live, samplitude, rezound, sweep, ardour, plus a dir for "Apple Loops" data etc. it would be great if each time an audio file enters a new app, the user wasnt greeted with a 30 second burst of disk activity as peak files were generated yet again..what exactly is needed? here are some thoughts - average amplitude per time-slice to generate the waveform overview * what granularity is useful? peak files seem to run a few % of filesize.. - spectral centroid for comparisonics/freesound style colorization - annotations (OPML etc) - timing (tempo, cue points, beat markers) rather than invent some new arbitrary plaintext (or XML) format, i'm interested in using OSC (as described at http://www.cnmat.berkeley.edu/OpenSoundControl/OSC-spec-examples.html ) to encapsulate this data, at which point this is simply an exercise in selecting a schema/namespace... beside faster load-times (eg one could pregenerate this data before a performance or composition session via a recursive shell command and 'sox'), a commonly understood format would enable easier sharing of CC-licensed material among a variety of users and apps without useful metadata being 'lost in translation'. additionally web and other interfaces could be developed using the metadata hints (see archive.org, NI's KORE) (2) Instruments compatibility and reuse of sample-based instruments between chionic, specimen, DSSI samplers, PD samplers, LinuxSampler, and seperation between editor and engine allowing more highly specialized apps - the 'nix way. - get rid of arbitrary region / bank / instrument boundaries which seem derived from MIDI (the amount of times you see 1-16 and 0-127 in modern software instruments is appalling) - sample regions pointing to audio files or groups - grouping (nesting / tags) - volume / filter / lfo stuff once again i am thinking OSC could be suited to this.. (3) 'project' components monolithic binary files still seem to remain the norm, eliminating all hope of reuse without tedious exporting of settings or components, things like: - pointers to regions (audio files, control streams, other projects) - note and controller-data streams - instrument / filter settings ive thought about this a bit and am leaning towards using a directory on disk, with a format for each of the above, which would enable revision tracking via SVN or darcs.. note/control data will likely be OSC (and MIDI encapsulated in OSC where necessary), instrument/filter settings would be closely aligned with what is fed to LADSPA/DSSI modules, and the pointer 'glue' file linking others and assigning filter and routing data to tracks, channels, regions..\\\ From paul at linuxaudiosystems.com Mon Jan 30 09:05:54 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Jan 30 09:02:56 2006 Subject: [linux-audio-dev] open standards for file formats In-Reply-To: <20060130111326.GA21697@replic.net> References: <20060130111326.GA21697@replic.net> Message-ID: <1138629954.18906.32.camel@localhost.localdomain> On Mon, 2006-01-30 at 11:13 +0000, cdr wrote: > i know design by committee can be horrible but these situations usually utilize vastly similar yet incompatible formats, so its sort of biting off something small, i hope.. :) > > (1) Peak Files > some of my favorite wav files have 10 metafiles each. peaks generated for peak, spark, wavelab, soundforge, cubase, ableton live, samplitude, rezound, sweep, ardour, plus a dir for "Apple Loops" data etc. > > it would be great if each time an audio file enters a new app, the user wasnt greeted with a 30 second burst of disk activity as peak files were generated yet again..what exactly is needed? here are some thoughts > > - average amplitude per time-slice to generate the waveform overview > * what granularity is useful? peak files seem to run a few % of filesize.. > - spectral centroid for comparisonics/freesound style colorization > - annotations (OPML etc) > - timing (tempo, cue points, beat markers) > > rather than invent some new arbitrary plaintext (or XML) format, i'm interested in using OSC (as described at http://www.cnmat.berkeley.edu/OpenSoundControl/OSC-spec-examples.html ) to encapsulate this data, at which point this is simply an exercise in selecting a schema/namespace... > > beside faster load-times (eg one could pregenerate this data before a performance or composition session via a recursive shell command and 'sox'), a commonly understood format would enable easier sharing of CC-licensed material among a variety of users and apps without useful metadata being 'lost in translation'. additionally web and other interfaces could be developed using the metadata hints (see archive.org, NI's KORE) i think that this is a rather mistaken goal. peak files and metadata are not equivalent except in the broadest sense. annotations, timing information are all totally different beasts from peak files. freq domain data is similar, for the most important reason: there is no single format that will work well. ardour's current kludge (a single peak file resolution) is likely to vanish at some point, to be replaced by multiple peak files at different resolutions. spectral data is the same thing: you need to know the window size at the very least, and this can vary depending on what the user is doing. note also that comparisonics is still covered by a patent that i expect would be vigorously defended. --p From paul at linuxaudiosystems.com Mon Jan 30 09:10:17 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Jan 30 09:07:20 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] LAD site, linuxdj.com needs a new home In-Reply-To: <43DDEA80.40907@gardena.net> References: <43DDEA80.40907@gardena.net> Message-ID: <1138630218.18906.35.camel@localhost.localdomain> On Mon, 2006-01-30 at 11:29 +0100, Benno Senoner wrote: > Hi LADers, > > During the last months the LAD website ( > http://www.linuxdj.com/audio/lad ) was hosted on the lionstracs.com server. > > Domenico from Lionstracs told me that he does not want do host the LAD > site anymore since it consumes so much bandwidth, > > 200 GB in January, see here. > http://www.linuxdj.com/webstat1/ > > its probably due to the audio/video material from the conferences > (100MB a pop). > > Anyone willing to host the site ? As I did in the last years, I'll pay > the for the linuxdj.com domain fees. i have the space and capacity to host this at dreamhost under my account. start the ball rolling. btw, i happen to think that the current website is ugly and a mess. it would nice if some people could spare several hours and clean it up to make a really useful resource for people interested in linux audio development. --p From voidcreature at paradise.net.nz Mon Jan 30 09:07:32 2006 From: voidcreature at paradise.net.nz (voidcreature@paradise.net.nz) Date: Mon Jan 30 09:08:34 2006 Subject: [linux-audio-dev] dmix and jack Message-ID: <200601310307.33010.voidcreature@paradise.net.nz> Has anyone managed to successfully get jackd talking to dmix? My dmix setup works fix (i run VoIP stuff, artsd, and other assorted junk through it daily). jackd works great when connect to hw:0,0 or to plughw:0,0 (with the warning), but if I point it at my dmix'd "default" it sits there with 100% CPU usage, and doesn't otherwise operate. Does anyone have this combination of jack and dmix working? (i'm running alsa 1.0.11rc3 on 2.6.15.1, i've tried alsa 1.0.10 and jack 0.100.0 too) >jackd -v -d alsa -d default -r 48000 -S -n 8 -p 1024 -P jackd 0.100.7 Copyright 2001-2005 Paul Davis and others. jackd comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details JACK compiled with System V SHM support. server `default' registered loading driver .. registered builtin port type 32 bit float mono audio new client: alsa_pcm, id = 1 type 1 @ 0x8056a48 fd = -1 apparent rate = 48000 creating alsa driver ... default|-|1024|8|48000|0|0|nomon|swmeter|-|16bit configuring for 48000Hz, period = 1024 frames, buffer = 8 periods You appear to be using the ALSA software "plug" layer, probably a result of using the "default" ALSA device. This is less efficient than it could be. Consider using a hardware device instead rather than using the plug layer. Usually the name of the hardware device that corresponds to the first soun nperiods = 8 for playback new buffer size 1024 registered port alsa_pcm:playback_1, offset = 0 registered port alsa_pcm:playback_2, offset = 0 ++ jack_rechain_graph(): client alsa_pcm: internal client, execution_order=0. -- jack_rechain_graph() 7129 waiting for signals load = 1.1672 max usecs: 498.000, spare = 20835.000 load = 1.3102 max usecs: 310.000, spare = 21023.000 load = 1.3793 max usecs: 309.000, spare = 21024.000 load = 1.4162 max usecs: 310.000, spare = 21023.000 .... etc .... From seablaede at gmail.com Mon Jan 30 09:54:47 2006 From: seablaede at gmail.com (Thomas Vecchione) Date: Mon Jan 30 09:52:53 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] LAD site, linuxdj.com needs a new home In-Reply-To: <1138630218.18906.35.camel@localhost.localdomain> References: <43DDEA80.40907@gardena.net> <1138630218.18906.35.camel@localhost.localdomain> Message-ID: <43DE28B7.1030808@gmail.com> Heh And here I had just offered the same thing;) Paul's hosting would probably be better, but at least you got a backup if needed;) I agree on the comments on the current status of the site. I have been considering setting up a LAU wiki on my site since I got it started, but have been worried it is already pretty well covered by others. However I definitly think a Wiki type setup would be important as Linux Audio changes so much due to it being open source, a combination of a Wiki and archive system would allow I think the most flexibility, or even a Wiki that is organized in versioning information. Just my opinion though, like I offered on the SOS forums Ill make the same offer here and if there is enough interest(Feel free to reply off-list) Ill set it up. Seablade From ico.bukvic at gmail.com Mon Jan 30 10:57:48 2006 From: ico.bukvic at gmail.com (Ivica Ico Bukvic) Date: Mon Jan 30 10:57:55 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] LAD site, linuxdj.com needs a new home In-Reply-To: <1138630218.18906.35.camel@localhost.localdomain> Message-ID: <001301c625b5$eb3dec10$3402a8c0@64BitBadass> Hi, I am pretty sure that we could get it hosted over here in my department. We have servers with generous bandwidth and space. Best wishes, Ivica Ico Bukvic, D.M.A. Composition Virginia Tech Dept. of Music Blacksburg, VA 24061-0240 ico@vt.edu http://meowing.ccm.uc.edu/~ico/ > -----Original Message----- > From: linux-audio-dev-bounces@music.columbia.edu [mailto:linux-audio-dev- > bounces@music.columbia.edu] On Behalf Of Paul Davis > Sent: Monday, January 30, 2006 9:10 AM > To: A list for linux audio users > Cc: The Linux Audio Developers' Mailing List > Subject: [linux-audio-dev] Re: [linux-audio-user] LAD site,linuxdj.com > needs a new home > > On Mon, 2006-01-30 at 11:29 +0100, Benno Senoner wrote: > > Hi LADers, > > > > During the last months the LAD website ( > > http://www.linuxdj.com/audio/lad ) was hosted on the lionstracs.com > server. > > > > Domenico from Lionstracs told me that he does not want do host the LAD > > site anymore since it consumes so much bandwidth, > > > > 200 GB in January, see here. > > http://www.linuxdj.com/webstat1/ > > > > its probably due to the audio/video material from the conferences > > (100MB a pop). > > > > Anyone willing to host the site ? As I did in the last years, I'll pay > > the for the linuxdj.com domain fees. > > i have the space and capacity to host this at dreamhost under my > account. start the ball rolling. > > btw, i happen to think that the current website is ugly and a mess. it > would nice if some people could spare several hours and clean it up to > make a really useful resource for people interested in linux audio > development. > > --p From itemstatechanged at yahoo.de Mon Jan 30 10:59:27 2006 From: itemstatechanged at yahoo.de (Item State) Date: Mon Jan 30 10:59:51 2006 Subject: [linux-audio-dev] Re: open standards for file formats In-Reply-To: <20060130140303.248B5411ACF@music.columbia.edu> Message-ID: <20060130155927.38751.qmail@web26801.mail.ukl.yahoo.com> hello, yes, peak/overview files and metadata is two different things. metadata should be stored in a open and extensible format such as XML. the problem with peak files is, different programmes rely on different resolution and representation. to give an example, in eisenkraut i use four peak files in four decimation scales ; only the highest resolution (1:256 (?)) is saved permanently, the others are created on the fly. since i want to support floating point files, i decided to store peak waveform in float32 format, which is rather big ; other sound editors will decide to not do this. also i store both peak and RMS information, others wish to store only peak, or peak and spectral focus or whatever. so unless two programmes are rather similiar, i wouldn't be too optimistic about using a uniform peak display. also i wouldn't deal with commercial software, honestly. if two software companies, say bias (for peak) and emagic/apple (for logic) are too dumb to agree on one format, i see no point why open source software should go and beg those companies to share their format. rather, if there are a few de facto standard open source softwares, it would make sense that they define a standard that they share. for eisenkraut i use normal AIFF files als overviews, i think that's pretty straight format, and since most programmes will store some form of PCM data, it shouldn't be too difficult to sync two -- if they work in a similar resolution and representation. there are some standards already, like SDIF for spectral information for example. best, -sciss- ____________________________________________________ Do you Yahoo!? Never miss an Instant Message - Yahoo! Messenger for SMS http://au.mobile.yahoo.com/mweb/index.html From sbenno at gardena.net Mon Jan 30 13:01:48 2006 From: sbenno at gardena.net (Benno Senoner) Date: Mon Jan 30 12:50:37 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] LAD site, linuxdj.com needs a new home In-Reply-To: <1138630218.18906.35.camel@localhost.localdomain> References: <43DDEA80.40907@gardena.net> <1138630218.18906.35.camel@localhost.localdomain> Message-ID: <43DE548C.40703@gardena.net> Hi all, if you agree that Paul Davis will host the site, I'll mail him the FTP password so he can do a recursive ftp. Domenico from Lionstracs would like to move the site in the next days so it would be handy if the contents could be fetched soon. please let me know. cheers, Benno Paul Davis wrote: >On Mon, 2006-01-30 at 11:29 +0100, Benno Senoner wrote: > > >>Hi LADers, >> >>During the last months the LAD website ( >>http://www.linuxdj.com/audio/lad ) was hosted on the lionstracs.com server. >> >>Domenico from Lionstracs told me that he does not want do host the LAD >>site anymore since it consumes so much bandwidth, >> >>200 GB in January, see here. >>http://www.linuxdj.com/webstat1/ >> >>its probably due to the audio/video material from the conferences >>(100MB a pop). >> >>Anyone willing to host the site ? As I did in the last years, I'll pay >>the for the linuxdj.com domain fees. >> >> > >i have the space and capacity to host this at dreamhost under my >account. start the ball rolling. > >btw, i happen to think that the current website is ugly and a mess. it >would nice if some people could spare several hours and clean it up to >make a really useful resource for people interested in linux audio >development. > >--p > > > > > From capocasa at gmx.net Mon Jan 30 12:57:14 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Mon Jan 30 12:56:02 2006 Subject: [linux-audio-dev] portmidi app i/o ports Message-ID: Hi, I would like to know whether it is possible for portmidi based applications to have their own sequencer i/o ports to connect to. Thanks, Carlo From yomguy at altern.org Mon Jan 30 14:29:05 2006 From: yomguy at altern.org (Guillaume Pellerin) Date: Mon Jan 30 14:29:12 2006 Subject: [linux-audio-dev] RME DIGI9652 with AEB8-I and AEB8-O In-Reply-To: <20060130111326.GA21697@replic.net> References: <20060130111326.GA21697@replic.net> Message-ID: <43DE6901.1060507@altern.org> Hi all ! I have installed a RME DIGI9652 on a Debian Sarge and it seems to work great with Ardour ! However my two expansion boards AEB8-I [1] and AEB8-O [2] plugged respectively on the "CD IN" input and "ADAT 1" output of the main board - as it is mentionned in the documentation - don't get any signal, even when I change existing interrupts in kmix, gamix, etc.. I would then ask to anybody who knows the chipset/driver if there are special routing interrupts to be switched with alsactl or something... Thanks a lot for your help and useful work ! p--g ` Parisson, Paris From yomguy at altern.org Mon Jan 30 14:57:00 2006 From: yomguy at altern.org (Guillaume Pellerin) Date: Mon Jan 30 14:57:08 2006 Subject: [linux-audio-dev] RME DIGI9652 with AEB8-I and AEB8-O Message-ID: <43DE6F8C.7050109@altern.org> Hi all ! I have installed a RME DIGI9652 on a Debian Sarge and it seems to work great with Ardour ! However my two expansion boards AEB8-I [1] and AEB8-O [2] plugged respectively on the "CD IN" input and "ADAT 1" output of the main board - as it is mentionned in the documentation - don't get any signal, even when I change existing interrupts in kmix, gamix, etc.. I would then ask to anybody who knows the chipset/driver if there are special routing interrupts to be switched with alsactl or something... Thanks a lot for your help and useful work ! p--g ` Parisson, Paris (sorry for the wrong 1st Re: mail) From James at superbug.co.uk Mon Jan 30 15:05:42 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Mon Jan 30 15:05:45 2006 Subject: [linux-audio-dev] dmix and jack In-Reply-To: <200601310307.33010.voidcreature@paradise.net.nz> References: <200601310307.33010.voidcreature@paradise.net.nz> Message-ID: <43DE7196.7090508@superbug.co.uk> voidcreature@paradise.net.nz wrote: > Has anyone managed to successfully get jackd talking to dmix? > > My dmix setup works fix (i run VoIP stuff, artsd, and other assorted junk > through it daily). > > jackd works great when connect to hw:0,0 or to plughw:0,0 (with the warning), > but if I point it at my dmix'd "default" it sits there with 100% CPU usage, > and doesn't otherwise operate. > > Does anyone have this combination of jack and dmix working? > It is due to the fact that the alsa programming in jackd has been implemented wrongly. The poll revents are not handled correctly. This results is OK operation when using hw:0,0, but likely to fail for more exotic alsa configurations like dmix. James From rlrevell at joe-job.com Mon Jan 30 15:10:17 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Jan 30 15:10:23 2006 Subject: [linux-audio-dev] dmix and jack In-Reply-To: <43DE7196.7090508@superbug.co.uk> References: <200601310307.33010.voidcreature@paradise.net.nz> <43DE7196.7090508@superbug.co.uk> Message-ID: <1138651818.16102.20.camel@mindpipe> On Mon, 2006-01-30 at 20:05 +0000, James Courtier-Dutton wrote: > voidcreature@paradise.net.nz wrote: > > Has anyone managed to successfully get jackd talking to dmix? > > > > My dmix setup works fix (i run VoIP stuff, artsd, and other assorted junk > > through it daily). > > > > jackd works great when connect to hw:0,0 or to plughw:0,0 (with the warning), > > but if I point it at my dmix'd "default" it sits there with 100% CPU usage, > > and doesn't otherwise operate. > > > > Does anyone have this combination of jack and dmix working? > > > > It is due to the fact that the alsa programming in jackd has been > implemented wrongly. The poll revents are not handled correctly. > This results is OK operation when using hw:0,0, but likely to fail for > more exotic alsa configurations like dmix. > Does this also explain why JACK does not work with the ALSA PCM multi plugin, unless ALSA is patched? Lee From rlrevell at joe-job.com Mon Jan 30 15:10:59 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Jan 30 15:11:16 2006 Subject: [linux-audio-dev] dmix and jack In-Reply-To: <43DE7196.7090508@superbug.co.uk> References: <200601310307.33010.voidcreature@paradise.net.nz> <43DE7196.7090508@superbug.co.uk> Message-ID: <1138651860.16102.22.camel@mindpipe> On Mon, 2006-01-30 at 20:05 +0000, James Courtier-Dutton wrote: > It is due to the fact that the alsa programming in jackd has been > implemented wrongly. The poll revents are not handled correctly. > This results is OK operation when using hw:0,0, but likely to fail for > more exotic alsa configurations like dmix. MUSTFIX for JACK 1.0? From paul at linuxaudiosystems.com Mon Jan 30 15:14:31 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Jan 30 15:13:07 2006 Subject: [linux-audio-dev] dmix and jack In-Reply-To: <43DE7196.7090508@superbug.co.uk> References: <200601310307.33010.voidcreature@paradise.net.nz> <43DE7196.7090508@superbug.co.uk> Message-ID: <1138652071.18906.69.camel@localhost.localdomain> On Mon, 2006-01-30 at 20:05 +0000, James Courtier-Dutton wrote: > voidcreature@paradise.net.nz wrote: > > Has anyone managed to successfully get jackd talking to dmix? > > > > My dmix setup works fix (i run VoIP stuff, artsd, and other assorted junk > > through it daily). > > > > jackd works great when connect to hw:0,0 or to plughw:0,0 (with the warning), > > but if I point it at my dmix'd "default" it sits there with 100% CPU usage, > > and doesn't otherwise operate. > > > > Does anyone have this combination of jack and dmix working? > > > > It is due to the fact that the alsa programming in jackd has been > implemented wrongly. The poll revents are not handled correctly. > This results is OK operation when using hw:0,0, but likely to fail for > more exotic alsa configurations like dmix. i will happily take a patch for this. or is it just the MMAP_COMPLEX patch and nothing more? --p From rlrevell at joe-job.com Mon Jan 30 15:27:24 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Jan 30 15:27:31 2006 Subject: [linux-audio-dev] dmix and jack In-Reply-To: <1138652071.18906.69.camel@localhost.localdomain> References: <200601310307.33010.voidcreature@paradise.net.nz> <43DE7196.7090508@superbug.co.uk> <1138652071.18906.69.camel@localhost.localdomain> Message-ID: <1138652844.16102.26.camel@mindpipe> On Mon, 2006-01-30 at 15:14 -0500, Paul Davis wrote: > On Mon, 2006-01-30 at 20:05 +0000, James Courtier-Dutton wrote: > > voidcreature@paradise.net.nz wrote: > > > Has anyone managed to successfully get jackd talking to dmix? > > > > > > My dmix setup works fix (i run VoIP stuff, artsd, and other assorted junk > > > through it daily). > > > > > > jackd works great when connect to hw:0,0 or to plughw:0,0 (with the warning), > > > but if I point it at my dmix'd "default" it sits there with 100% CPU usage, > > > and doesn't otherwise operate. > > > > > > Does anyone have this combination of jack and dmix working? > > > > > > > It is due to the fact that the alsa programming in jackd has been > > implemented wrongly. The poll revents are not handled correctly. > > This results is OK operation when using hw:0,0, but likely to fail for > > more exotic alsa configurations like dmix. > > i will happily take a patch for this. or is it just the MMAP_COMPLEX > patch and nothing more? No, this is a separate issue (ALSA still must be patched to work with JACK + MMAP_COMPLEX). The ALSA developers won't take the patch, they say it's actually JACK that's wrong, but I haven't seen a patch, nor do I know exactly what the problem is. Lee From fons.adriaensen at skynet.be Mon Jan 30 16:08:58 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Mon Jan 30 16:02:38 2006 Subject: [linux-audio-dev] dmix and jack In-Reply-To: <43DE7196.7090508@superbug.co.uk> References: <200601310307.33010.voidcreature@paradise.net.nz> <43DE7196.7090508@superbug.co.uk> Message-ID: <20060130210858.GA5277@linux-1> On Mon, Jan 30, 2006 at 08:05:42PM +0000, James Courtier-Dutton wrote: > It is due to the fact that the alsa programming in jackd has been > implemented wrongly. The poll revents are not handled correctly. > This results is OK operation when using hw:0,0, but likely to fail for > more exotic alsa configurations like dmix. Could you explain this in a bit more detail ? -- FA From James at superbug.co.uk Mon Jan 30 16:05:11 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Mon Jan 30 16:05:17 2006 Subject: [linux-audio-dev] dmix and jack In-Reply-To: <1138652071.18906.69.camel@localhost.localdomain> References: <200601310307.33010.voidcreature@paradise.net.nz> <43DE7196.7090508@superbug.co.uk> <1138652071.18906.69.camel@localhost.localdomain> Message-ID: <43DE7F87.6070405@superbug.co.uk> Paul Davis wrote: > On Mon, 2006-01-30 at 20:05 +0000, James Courtier-Dutton wrote: >> voidcreature@paradise.net.nz wrote: >>> Has anyone managed to successfully get jackd talking to dmix? >>> >>> My dmix setup works fix (i run VoIP stuff, artsd, and other assorted junk >>> through it daily). >>> >>> jackd works great when connect to hw:0,0 or to plughw:0,0 (with the warning), >>> but if I point it at my dmix'd "default" it sits there with 100% CPU usage, >>> and doesn't otherwise operate. >>> >>> Does anyone have this combination of jack and dmix working? >>> >> It is due to the fact that the alsa programming in jackd has been >> implemented wrongly. The poll revents are not handled correctly. >> This results is OK operation when using hw:0,0, but likely to fail for >> more exotic alsa configurations like dmix. > > i will happily take a patch for this. or is it just the MMAP_COMPLEX > patch and nothing more? > > --p > Paul, If I get a moment, I will try to get a patch together for jackd this weekend. It is just a matter of adding a few lines of code, so hopefully won't take long. If you want to make a head start, you need to add snd_pcm_poll_descriptors_revents() calls. I attach some GPL code from another project that should illustrate the method to use. James -------------- next part -------------- A non-text attachment was scrubbed... Name: start_alsa.c Type: text/x-csrc Size: 18822 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060130/32f7d094/start_alsa-0001.bin From tito at rumford.de Mon Jan 30 17:32:24 2006 From: tito at rumford.de (Wolfgang Woehl) Date: Mon Jan 30 17:33:01 2006 Subject: [linux-audio-dev] RME DIGI9652 with AEB8-I and AEB8-O In-Reply-To: <43DE6901.1060507@altern.org> References: <20060130111326.GA21697@replic.net> <43DE6901.1060507@altern.org> Message-ID: <200601302332.24751.tito@rumford.de> Guillaume Pellerin : > Hi all ! > > I have installed a RME DIGI9652 on a Debian Sarge and it > seems to work great with Ardour ! However my two expansion > boards AEB8-I [1] and AEB8-O [2] plugged respectively on > the "CD IN" input and "ADAT 1" output of the main board - "CD IN" should be connected to the output of a cd drive. > as it is mentionned in the documentation - don't get any > signal, even when I change existing interrupts in kmix, > gamix, etc.. I would then ask to anybody who knows the > chipset/driver if there are special routing interrupts to > be switched with alsactl or something... Maybe it's the clocking, you want to connect the AEB's to the DIGI9652's word clock connectors and master clock from there. I think. There is no such thing as "changing interrupts" in kmix and the like. -- Wolfgang From yomguy at altern.org Mon Jan 30 22:39:54 2006 From: yomguy at altern.org (Guillaume Pellerin) Date: Mon Jan 30 22:39:53 2006 Subject: [linux-audio-dev] RME DIGI9652 with AEB8-I and AEB8-O In-Reply-To: <200601302332.24751.tito@rumford.de> References: <20060130111326.GA21697@replic.net> <43DE6901.1060507@altern.org> <200601302332.24751.tito@rumford.de> Message-ID: <43DEDC0A.2070004@altern.org> Wolfgang Woehl a ?crit : > Guillaume Pellerin : > >>Hi all ! >> >>I have installed a RME DIGI9652 on a Debian Sarge and it >>seems to work great with Ardour ! However my two expansion >>boards AEB8-I [1] and AEB8-O [2] plugged respectively on >>the "CD IN" input and "ADAT 1" output of the main board - > > > "CD IN" should be connected to the output of a cd drive. > I know it's strange ! But it was working like that on other (windows') machines with full 8 tracks in duplex... > >>as it is mentionned in the documentation - don't get any >>signal, even when I change existing interrupts in kmix, >>gamix, etc.. I would then ask to anybody who knows the >>chipset/driver if there are special routing interrupts to >>be switched with alsactl or something... > > > Maybe it's the clocking, you want to connect the AEB's to the > DIGI9652's word clock connectors and master clock from there. > I think. > There is no such thing as "changing interrupts" in kmix and > the like. > Ok ! So I'll try to fix some word clock problems somewhere... Thanks ! p--g ` [1] http://www.rme-audio.com/english/aeb/aeb48i.htm [2] http://www.rme-audio.com/english/aeb/aeb48o.htm From terakuma at imbris.net Tue Jan 31 05:57:34 2006 From: terakuma at imbris.net (Maluvia) Date: Tue Jan 31 05:55:26 2006 Subject: [linux-audio-dev] Re:LAD site, linuxdj.com needs a new home In-Reply-To: <20060130192918.99B4B41CD2F@music.columbia.edu> References: <20060130192918.99B4B41CD2F@music.columbia.edu> Message-ID: <200601310257340660.0037EABD@mail.imbris.net> On 1/30/06 Paul Davis wrote: >i have the space and capacity to host this at dreamhost under my >account. start the ball rolling. I think this would be the best solution - it will keep Paul with us for a long time to come. :) >btw, i happen to think that the current website is ugly and a mess. it >would nice if some people could spare several hours and clean it up to >make a really useful resource for people interested in linux audio >development. Agreed. -Maluvia From mlang at delysid.org Tue Jan 31 06:10:55 2006 From: mlang at delysid.org (mlang) Date: Tue Jan 31 06:53:48 2006 Subject: [linux-audio-dev] Launching DSSI GUIs via OSC? Message-ID: <87lkww3b5s.fsf@x2.delysid.org> Hi. Is there anything planned for the DSSI standard which would allow DSSI hosts to launch GUIs just by sending a OSC message to some kind of GUI launcher? I am asking because I'd like to write a whysynth frontend in SuperCollider Language. That should be all doable, since the whole GUI->DSP->GUI process happens over OSC. Now there is only the session initiation left. I know its pretty trivial to write a wrapper WhySynth_osc which just sends off its argv to SCLang via OSC, but this feels kind of clumsy to me. In fact, for what I'd like to do, it would be quite pretty if jack-dssi-host just had an additional command-line argument which would tell its startGUI routine not to call exec, rather send the 4 strings to the specified osc url. $ jack-dssi-host -o osc.udp://localhost:57110/dssRequestedI/ whysynth.so How does this sound to you, worth a patch? Or should this really be done with wrappers, ugly as they may be? -- CYa, Mario From fbar at footils.org Tue Jan 31 06:59:49 2006 From: fbar at footils.org (Frank Barknecht) Date: Tue Jan 31 07:00:02 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] LAD site, linuxdj.com needs a new home In-Reply-To: <43DE28B7.1030808@gmail.com> References: <43DDEA80.40907@gardena.net> <1138630218.18906.35.camel@localhost.localdomain> <43DE28B7.1030808@gmail.com> Message-ID: <20060131115949.GD2053@fliwatut.scifi> Hallo, Thomas Vecchione hat gesagt: // Thomas Vecchione wrote: > Heh And here I had just offered the same thing;) Paul's hosting would > probably be better, but at least you got a backup if needed;) > > I agree on the comments on the current status of the site. I have been > considering setting up a LAU wiki on my site since I got it started, but > have been worried it is already pretty well covered by others. However > I definitly think a Wiki type setup would be important as Linux Audio > changes so much due to it being open source, a combination of a Wiki and > archive system would allow I think the most flexibility, or even a Wiki > that is organized in versioning information. A Wiki would be great also to do the yearly organizing of shared travelling to the Linux Audio Conference. In the last year my Wiki was used for this, which is is no problem for me, but of course a dedicated LAD/U wiki would be the nicer solution. Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From hans at fugal.net Tue Jan 31 09:13:49 2006 From: hans at fugal.net (Hans Fugal) Date: Tue Jan 31 09:14:04 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] LAD site, linuxdj.com needs a new home In-Reply-To: <20060131115949.GD2053@fliwatut.scifi> References: <43DDEA80.40907@gardena.net> <1138630218.18906.35.camel@localhost.localdomain> <43DE28B7.1030808@gmail.com> <20060131115949.GD2053@fliwatut.scifi> Message-ID: <20060131141349.GA2364@falcon.fugal.net> There is an existing wiki you are free to use at http://fugal.net:2500 I don't have the bandwidth or disk space to host multimedia there, however. I know the URL is kind of awkward, and I'm planning to set it up to proxy through apache real soon now, at which point it could be lawiki.fugal.net or something like that (or any other domain name someone wants to set up to point to me). On Tue, 31 Jan 2006 at 12:59 +0100, Frank Barknecht wrote: > Hallo, > Thomas Vecchione hat gesagt: // Thomas Vecchione wrote: > > > Heh And here I had just offered the same thing;) Paul's hosting would > > probably be better, but at least you got a backup if needed;) > > > > I agree on the comments on the current status of the site. I have been > > considering setting up a LAU wiki on my site since I got it started, but > > have been worried it is already pretty well covered by others. However > > I definitly think a Wiki type setup would be important as Linux Audio > > changes so much due to it being open source, a combination of a Wiki and > > archive system would allow I think the most flexibility, or even a Wiki > > that is organized in versioning information. > > A Wiki would be great also to do the yearly organizing of shared > travelling to the Linux Audio Conference. In the last year my Wiki was > used for this, which is is no problem for me, but of course a > dedicated LAD/U wiki would be the nicer solution. > > Ciao > -- > Frank Barknecht _ ______footils.org_ __goto10.org__ > -- Hans Fugal ; http://hans.fugal.net There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- Johann Sebastian Bach -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060131/72ef3870/attachment.bin From seablaede at gmail.com Tue Jan 31 10:32:30 2006 From: seablaede at gmail.com (Thomas Vecchione) Date: Tue Jan 31 10:30:47 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] LAD site, linuxdj.com needs a new home In-Reply-To: <20060131141349.GA2364@falcon.fugal.net> References: <43DDEA80.40907@gardena.net> <1138630218.18906.35.camel@localhost.localdomain> <43DE28B7.1030808@gmail.com> <20060131115949.GD2053@fliwatut.scifi> <20060131141349.GA2364@falcon.fugal.net> Message-ID: <43DF830E.6020509@gmail.com> Well I dont think I have the time to keep up a magazine myself at the moment, which is another reason why I was looking at a wiki, so that others could also join in to help as needed. Not real sure what the best way to handle editing permissions is, either to keep it a true wiki and let anyone edit it, I obviously have some reservations about, or to possibly send out an account info to this and the LAU list or something along those lines? Or just to keep the account info myself and allow others to email me for permission, which unfortunatly has the side effect of making it that much more inconvienient, both for me and for the ones wanting to edit. Currently I have 3 domains, 2 pointers and a full one, and a fair amount of space and bandwidth at my site, never complain about other possibilities, but I dont think at least at first anything would be a problem. I dont think I have a problem with running a version of Mambo or Joomla?(From the developers of Mambo?) if there is desire for others that wish to put interviews and such on there if there is interest in that as well, again though I just dont have time myself to do upkeep on anything ala serious magazine level. Thomas Vecchione From seablaede at gmail.com Tue Jan 31 10:44:06 2006 From: seablaede at gmail.com (Thomas Vecchione) Date: Tue Jan 31 10:42:06 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] LAD site, linuxdj.com needs a new home In-Reply-To: <20060131141349.GA2364@falcon.fugal.net> References: <43DDEA80.40907@gardena.net> <1138630218.18906.35.camel@localhost.localdomain> <43DE28B7.1030808@gmail.com> <20060131115949.GD2053@fliwatut.scifi> <20060131141349.GA2364@falcon.fugal.net> Message-ID: <43DF85C6.6030901@gmail.com> Oh yea I should mention, for those interested my site is hosted on Powweb if you need to know some of the stats on it, it has about 10 Gigs of transfer a day and 12 Gigs of storage alltogether, so storage for multimedia(At least in the uncompressed or lossless forms) would still be limited a little but could hold up some at least. If things get popular enough as a method of giving back to the open source community I wouldnt be completly against setting up a seperrate Powweb account for a linux audio site. Being kinda poor it aint much but at least its something I could do. Seablade