From njh at ecs.soton.ac.uk Wed Aug 2 10:51:58 2006 From: njh at ecs.soton.ac.uk (Nicholas J Humfrey) Date: Wed Aug 2 10:52:29 2006 Subject: [linux-audio-dev] Help needed: mpg123 lives! Message-ID: <406BE807-F16F-441E-846A-8F7545CE63A2@ecs.soton.ac.uk> Hi, Thomas Orgis and myself have been doing some work on mpg123 and have started a website and Subversion repository: http://mpg123.orgis.org/ We have been rolling various patches into the new official code-base. We have gained permission from Michael Hipp and all the contributors to mpg123 to make all of the code LGPL licensed. New features: - autoconf/automake based build system - support for more output methods (liboa, JACK, SDL, PortAudio, CoreAudio) - more assembler optimizations (MMX, AltiVec, ...) - new equalizer code - experimental gapless playback We are working towards a 0.60 stable version. After that version we will be looking at more major changes to the code structure. I have been trying to add ALSA 0.9/1.0 API support - but have been having a few problems - is anyone able to help out? Thanks, nick. From clemens at ladisch.de Wed Aug 2 12:57:13 2006 From: clemens at ladisch.de (Clemens Ladisch) Date: Wed Aug 2 12:58:08 2006 Subject: [linux-audio-dev] Help needed: mpg123 lives! In-Reply-To: <406BE807-F16F-441E-846A-8F7545CE63A2@ecs.soton.ac.uk> References: <406BE807-F16F-441E-846A-8F7545CE63A2@ecs.soton.ac.uk> Message-ID: <20060802165713.GB16353@turing.informatik.uni-halle.de> Nicholas J Humfrey wrote: > I have been trying to add ALSA 0.9/1.0 API support - but have been > having a few problems - is anyone able to help out? Yes. Regards, Clemens From jonobacon at gmail.com Sun Aug 6 20:12:54 2006 From: jonobacon at gmail.com (Jono Bacon) Date: Sun Aug 6 20:13:01 2006 Subject: [linux-audio-dev] Are people still writing LADSPA plug-ins? Message-ID: <1c3fe48e0608061712q74e53cb5o85171b0e4fa3c087@mail.gmail.com> Hi all, I don't mean this to be a pointed question, but from looking at the swh, TAP and CMT plug-in sites, there doesn't seem to be many recent updates of LADSPA plug-ins, and I have not seen many people releasing and announcing new plug-ins. Are people writing new plug-ins, and are existing plug-ins getting refined and released? It would awesome if there was a central site, akin to Firefox's Extension Room site, for the different plug-ins that are available. Jono From loki.davison at gmail.com Sun Aug 6 21:51:06 2006 From: loki.davison at gmail.com (Loki Davison) Date: Sun Aug 6 21:51:14 2006 Subject: [linux-audio-dev] Re: Are people still writing LADSPA plug-ins? In-Reply-To: <1c3fe48e0608061712q74e53cb5o85171b0e4fa3c087@mail.gmail.com> References: <1c3fe48e0608061712q74e53cb5o85171b0e4fa3c087@mail.gmail.com> Message-ID: On 8/7/06, Jono Bacon wrote: > Hi all, > > I don't mean this to be a pointed question, but from looking at the > swh, TAP and CMT plug-in sites, there doesn't seem to be many recent > updates of LADSPA plug-ins, and I have not seen many people releasing > and announcing new plug-ins. Are people writing new plug-ins, and are > existing plug-ins getting refined and released? > > It would awesome if there was a central site, akin to Firefox's > Extension Room site, for the different plug-ins that are available. > > Jono > LV2 is going to be the new plugin standard so mostly no. A few LV2 plugins are in the works and DSSI ones are being released regularly. It depends if you want improvements to any of these. For many of them what is there to improve? Though a few in Omins could use a little work... ;) Loki From tim at quitte.de Tue Aug 8 04:39:45 2006 From: tim at quitte.de (Tim Goetze) Date: Tue Aug 8 04:43:32 2006 Subject: [linux-audio-dev] Are people still writing LADSPA plug-ins? In-Reply-To: <1c3fe48e0608061712q74e53cb5o85171b0e4fa3c087@mail.gmail.com> References: <1c3fe48e0608061712q74e53cb5o85171b0e4fa3c087@mail.gmail.com> Message-ID: [Jono Bacon] [...] > and announcing new plug-ins. Are people writing new plug-ins, and are > existing plug-ins getting refined and released? Yes and yes. Slowly but surely. http://quitte.de/dsp/caps.html Cheers, Tim From jonobacon at gmail.com Tue Aug 8 05:15:28 2006 From: jonobacon at gmail.com (Jono Bacon) Date: Tue Aug 8 05:15:41 2006 Subject: [linux-audio-dev] Are people still writing LADSPA plug-ins? In-Reply-To: References: <1c3fe48e0608061712q74e53cb5o85171b0e4fa3c087@mail.gmail.com> Message-ID: <1c3fe48e0608080215j627b1f98sfe449efb1361d2d6@mail.gmail.com> Hi all, Thanks for the responses. It seems that the public face of LADSPA is maybe a little different to the reality - I remember first reading about LADSPA and thinking that there was not all that much going on with it, but I am pleased to see people are working on plugins. I think it could be useful to improve the face of LADSPA and spread the word of LV2. Would any LADSPA plug-in authors be interested in writing blogs about their work with LADSPA? If this was the case, maybe there could be a Planet LADSPA that would bring together such bog entries? Planets have been really useful in spreading the word about certain technologies, and they are a great way to get more people reading your blog. I don't know how many times I have asked a question on my blog and got 15 responses as it is on Planet GNOME, Planet Advocacy and a few others. Maybe then we would have more and more people writing plugins. :) Thoughts? Jono From S.W.Harris at ecs.soton.ac.uk Tue Aug 8 07:29:47 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue Aug 8 07:30:12 2006 Subject: [linux-audio-dev] Are people still writing LADSPA plug-ins? In-Reply-To: <1c3fe48e0608080215j627b1f98sfe449efb1361d2d6@mail.gmail.com> References: <1c3fe48e0608061712q74e53cb5o85171b0e4fa3c087@mail.gmail.com> <1c3fe48e0608080215j627b1f98sfe449efb1361d2d6@mail.gmail.com> Message-ID: <20060808112947.GB11688@login.ecs.soton.ac.uk> It might be better to have a planet for linux audio in general, Dave Phillip's blog is allready in my RSS reader. LV2 is in the last 10% stage, I meant to mail out an update after the ast batch of work Dave Robillard and I did, but I think I forgot, and I can't remember what we did now... There are now 3 hosts (2 built on libslv2, and 1 independent), and many plugins that more-or-less work, the plugins dont work on Mac OSX (at least I couldn't get them to work), but mostly do on linux. - Steve On Tue, Aug 08, 2006 at 10:15:28 +0100, Jono Bacon wrote: > Hi all, > > Thanks for the responses. It seems that the public face of LADSPA is > maybe a little different to the reality - I remember first reading > about LADSPA and thinking that there was not all that much going on > with it, but I am pleased to see people are working on plugins. > > I think it could be useful to improve the face of LADSPA and spread > the word of LV2. Would any LADSPA plug-in authors be interested in > writing blogs about their work with LADSPA? If this was the case, > maybe there could be a Planet LADSPA that would bring together such > bog entries? > > Planets have been really useful in spreading the word about certain > technologies, and they are a great way to get more people reading your > blog. I don't know how many times I have asked a question on my blog > and got 15 responses as it is on Planet GNOME, Planet Advocacy and a > few others. Maybe then we would have more and more people writing > plugins. :) > > Thoughts? > > Jono From S.W.Harris at ecs.soton.ac.uk Wed Aug 9 05:07:30 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Aug 9 05:08:03 2006 Subject: [linux-audio-dev] LV2 draft spec update Message-ID: <20060809090730.GC13660@login.ecs.soton.ac.uk> http://lv2plug.in/spec/ Some more work has been done recently, but I think I forgot to tell this mailing list. The most notable change is the inclusion of a port hint to indiciate that connections to that port are optional. This has never been a part of LADSPA, though it was discussed. It's included because it makes it possible to have plugin that can use certain port type extension, but dont require them. Eg. a plugin that can use MIDI data, but doesn't require it. If the plugin marks the MIDI port as lv2:optionalConnection then hosts can tell by inspection that it can still load and use the plugin, even if it doesn't support/want to use the MIDI extension. The LV2 spec is approaching finalisation now. We have two independent host impletmentions, and several that share some code, there are lots of plugins, some using extensions and some using vanialla LV2. If people want to comment opn the late drafts now would be a good time, as I imagine that the final spec will look a lot like whats there unless people find problems. - Steve From jono at jonobacon.org Wed Aug 9 06:10:07 2006 From: jono at jonobacon.org (Jono Bacon) Date: Wed Aug 9 06:10:20 2006 Subject: [linux-audio-dev] LV2 draft spec update In-Reply-To: <20060809090730.GC13660@login.ecs.soton.ac.uk> References: <20060809090730.GC13660@login.ecs.soton.ac.uk> Message-ID: <1c3fe48e0608090310p1c8eb1afn410fd88d1660cef2@mail.gmail.com> On 8/9/06, Steve Harris wrote: > The LV2 spec is approaching finalisation now. We have two independent host > impletmentions, and several that share some code, there are lots of > plugins, some using extensions and some using vanialla LV2. If people want > to comment opn the late drafts now would be a good time, as I imagine that > the final spec will look a lot like whats there unless people find > problems. Is there a way to categorise LV2 plug-ins? The problem with LADSPA is that there is one huge list and it should really be divided into sections. Maybe have the equivilent of a .desktop file for each plug-in? Jono From lars.luthman at gmail.com Wed Aug 9 06:13:58 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Wed Aug 9 06:13:48 2006 Subject: [linux-audio-dev] LV2 draft spec update In-Reply-To: <1c3fe48e0608090310p1c8eb1afn410fd88d1660cef2@mail.gmail.com> References: <20060809090730.GC13660@login.ecs.soton.ac.uk> <1c3fe48e0608090310p1c8eb1afn410fd88d1660cef2@mail.gmail.com> Message-ID: <1155118438.13823.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> On Wed, 2006-08-09 at 11:10 +0100, Jono Bacon wrote: > On 8/9/06, Steve Harris wrote: > > The LV2 spec is approaching finalisation now. We have two independent host > > impletmentions, and several that share some code, there are lots of > > plugins, some using extensions and some using vanialla LV2. If people want > > to comment opn the late drafts now would be a good time, as I imagine that > > the final spec will look a lot like whats there unless people find > > problems. > > Is there a way to categorise LV2 plug-ins? The problem with LADSPA is > that there is one huge list and it should really be divided into > sections. Maybe have the equivilent of a .desktop file for each > plug-in? Look at the "RDF schema" at the URL Steve Harris posted, there is categorisation in it. -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E 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/20060809/e094a09b/attachment.bin From jono at jonobacon.org Wed Aug 9 06:21:56 2006 From: jono at jonobacon.org (Jono Bacon) Date: Wed Aug 9 06:22:05 2006 Subject: [linux-audio-dev] LV2 draft spec update In-Reply-To: <1155118438.13823.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> References: <20060809090730.GC13660@login.ecs.soton.ac.uk> <1c3fe48e0608090310p1c8eb1afn410fd88d1660cef2@mail.gmail.com> <1155118438.13823.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> Message-ID: <1c3fe48e0608090321p16144c24s73130c8d9998e80f@mail.gmail.com> On 8/9/06, Lars Luthman wrote: > Look at the "RDF schema" at the URL Steve Harris posted, there is > categorisation in it. Awesome!! :) Jono From S.W.Harris at ecs.soton.ac.uk Wed Aug 9 06:32:53 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Aug 9 06:33:29 2006 Subject: [linux-audio-dev] LV2 draft spec update In-Reply-To: <1c3fe48e0608090310p1c8eb1afn410fd88d1660cef2@mail.gmail.com> References: <20060809090730.GC13660@login.ecs.soton.ac.uk> <1c3fe48e0608090310p1c8eb1afn410fd88d1660cef2@mail.gmail.com> Message-ID: <20060809103253.GA18606@login.ecs.soton.ac.uk> On Wed, Aug 09, 2006 at 11:10:07AM +0100, Jono Bacon wrote: > On 8/9/06, Steve Harris wrote: > >The LV2 spec is approaching finalisation now. We have two independent host > >impletmentions, and several that share some code, there are lots of > >plugins, some using extensions and some using vanialla LV2. If people want > >to comment opn the late drafts now would be a good time, as I imagine that > >the final spec will look a lot like whats there unless people find > >problems. > > Is there a way to categorise LV2 plug-ins? The problem with LADSPA is > that there is one huge list and it should really be divided into > sections. Maybe have the equivilent of a .desktop file for each > plug-in? Yes, but that feature was also in a LADSPA extension called LRDF, some hosts make use of use it, eg. jack-rack. If you look in /usr/share/ladspa/rdf/ and /usr/local/share/ladspa/rdf/ you should see the category data. - Steve From a at gaydenko.com Wed Aug 9 12:13:47 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Wed Aug 9 12:14:37 2006 Subject: [linux-audio-dev] [AN] QLoud-0.1 - measuring loudspeaker response Message-ID: <200608092013.48068@goldspace.net> Hi! I have wrote this app for own audio-DIY use. Probably, somebody else will find the app useful too. I'll be happy in such case :-) Source: http://gaydenko.com/qloud/qloud-0.1.tar.bz2 Screenshot (180KB): http://gaydenko.com/qloud/shot01.png ===== README ====== QLoud is a tool to measure a loudspeaker frequency response. Writing this app is inspired by excellent applications written by Fons Adriaensen: http://users.skynet.be/solaris/linuxaudio/ Theoretical background belongs to Angelo Farina: http://pcfarina.eng.unipr.it/ In particular, this method was used: http://pcfarina.eng.unipr.it/Public/Papers/134-AES00.PDF Few hints: - move mouse above "?" sign at plot window and wait, - to delete measurement, use context menu on mesurements table, - to see what the app do, just connect app's JACK ports and try, - to see what your sound card do, use loopback for line in/out, - using "very smooth" fractional octave smoothing is hungry for CPU. So be patient when select more rather 1/3 octave smoothing (1/3 octave and less smoothing is rather interactive). Feedback: Please, add "QLoud" to your message subject. My email is: a@gaydenko.com ===== INSTALL ===== Requirements: - QT4 ( http://trolltech.com/ ), I use 4.1.4 version, - Qwt ( http://qwt.sourceforge.net/ ) from current CVS tree (probably, last official CVS qwt5 snapshot will work too), - JACK ( http://jackaudio.org/ ), - sndfile ( http://www.mega-nerd.com/libsndfile/ ), - fftw ( http://www.fftw.org/ ). Installation: - look in src/src.pro to modify include dirs if you want, - run qmake make 'qloud' excecutable will be in 'bin' directory. From ico.bukvic at gmail.com Wed Aug 9 12:57:24 2006 From: ico.bukvic at gmail.com (Ivica Ico Bukvic) Date: Wed Aug 9 12:57:39 2006 Subject: [linux-audio-dev] LV2 draft spec update In-Reply-To: <20060809090730.GC13660@login.ecs.soton.ac.uk> Message-ID: <002101c6bbd4$e389d640$3402a8c0@64BitBadass> > The LV2 spec is approaching finalisation now. We have two independent host > impletmentions, and several that share some code, there are lots of > plugins, some using extensions and some using vanialla LV2. If people want > to comment opn the late drafts now would be a good time, as I imagine that > the final spec will look a lot like whats there unless people find > problems. Excellent work! FWIW, I think it would be really nice if we got LV2 also as a member of the consortium. Best wishes, Ico From S.W.Harris at ecs.soton.ac.uk Wed Aug 9 16:27:42 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Aug 9 16:28:23 2006 Subject: [linux-audio-dev] LV2 draft spec update In-Reply-To: <002101c6bbd4$e389d640$3402a8c0@64BitBadass> References: <20060809090730.GC13660@login.ecs.soton.ac.uk> <002101c6bbd4$e389d640$3402a8c0@64BitBadass> Message-ID: <20060809202742.GC6672@login.ecs.soton.ac.uk> On Wed, Aug 09, 2006 at 12:57:24 -0400, Ivica Ico Bukvic wrote: > > The LV2 spec is approaching finalisation now. We have two independent host > > impletmentions, and several that share some code, there are lots of > > plugins, some using extensions and some using vanialla LV2. If people want > > to comment opn the late drafts now would be a good time, as I imagine that > > the final spec will look a lot like whats there unless people find > > problems. > > Excellent work! > > FWIW, I think it would be really nice if we got LV2 also as a member of the > consortium. Sure, no problem. It's not relly a project in the normal sense, but I guess it makes sense. - Steve From jdboyd at jdboyd.net Wed Aug 9 19:20:54 2006 From: jdboyd at jdboyd.net (Joshua Boyd) Date: Wed Aug 9 19:35:53 2006 Subject: [linux-audio-dev] 2.6.15.7-rt Message-ID: <20060809232054.GD22705@jdboyd> I just upgraded my LFS 6.1 system from 2.6.12 (with preempt, but not the -rt patch) to 2.6.15-rt (enabling high resolution timers and PREEMPT_RT along the way), and now my audio driver is dropping interrupts every few seconds, something it wasn't doing before. I haven't configured rtlimits since the program runs as root anyway, and I'd like it to be free to hog quite a lot if need be. In my application (which runs in SCHED_FIFO), the audio thread runs at -10, while the video thread runs at -19. I don't know if that is best, I just wanted them to be higher than the other threads. Also, outside forces, like a ssh connection, or a USB dongle connection cause the program to drop audio madly. Is there some code I need to be adding to force such system tasks down rather than just elevating my own application? -- Joshua D. Boyd jdboyd@jdboyd.net http://www.jdboyd.net/ http://www.joshuaboyd.org/ From ico.bukvic at gmail.com Thu Aug 10 12:47:11 2006 From: ico.bukvic at gmail.com (Ivica Ico Bukvic) Date: Thu Aug 10 12:47:25 2006 Subject: [linux-audio-dev] LV2 and Linuxaudio.org In-Reply-To: <20060810103041.GB20471@login.ecs.soton.ac.uk> Message-ID: <001501c6bc9c$a1aa2400$3402a8c0@64BitBadass> To all involved in the LV2 project, I would greatly appreciate your feedback regarding LV2 project becoming a member of Linuxaudio.org. Provided that you decide this is a step they wish to take, it would be a good idea to nominate someone as the representative of the project within the consortium. Please advise. Best wishes, Ivica Ico Bukvic, D.M.A. Linuxaudio.org Director Virginia Tech Department of Music - 0240 Blacksburg, VA 24061 (540) 231-7047 (540) 231-5034 (fax) ico@vt.edu http://www.music.vt.edu/people/faculty/bukvic From t_w_ at freenet.de Fri Aug 11 11:09:59 2006 From: t_w_ at freenet.de (Thorsten Wilms) Date: Fri Aug 11 11:10:05 2006 Subject: [linux-audio-dev] LV2 and Linuxaudio.org In-Reply-To: <001501c6bc9c$a1aa2400$3402a8c0@64BitBadass> References: <20060810103041.GB20471@login.ecs.soton.ac.uk> <001501c6bc9c$a1aa2400$3402a8c0@64BitBadass> Message-ID: <20060811150959.GA7334@charly.SWORD> On Thu, Aug 10, 2006 at 12:47:11PM -0400, Ivica Ico Bukvic wrote: > To all involved in the LV2 project, I would greatly appreciate your feedback > regarding LV2 project becoming a member of Linuxaudio.org. Provided that you > decide this is a step they wish to take, it would be a good idea to nominate > someone as the representative of the project within the consortium. 50% of the core team do not even think there is a project (just a spec), wonder what the point of the consortium is and don't like anything that smells even remotely of business. So I would say no, no membership. Unless 1 of the 2 speak up. Sorry :) -- Thorsten Wilms From ico.bukvic at gmail.com Fri Aug 11 11:58:13 2006 From: ico.bukvic at gmail.com (Ivica Ico Bukvic) Date: Fri Aug 11 11:58:22 2006 Subject: [linux-audio-dev] LV2 and Linuxaudio.org In-Reply-To: <20060811150959.GA7334@charly.SWORD> Message-ID: <002801c6bd5e$f3de5e90$3402a8c0@64BitBadass> Well, the very fact that there is a spec which is to be promoted and encouraged in order to foster wider adoption sounds like a "project" to me. Wouldn't it be nice if this spec actually was adopted by commercial companies as well (you personally may or may not care about this, but I would bet hat a good number of others may, and the consortium certainly does)? This is as far as the "business" aspect goes. The consortium is not here to police individual projects or to tell them what to do or not do. Rather, the consortium's mission is to encourage their growth, mutual cooperation, and ultimately consolidation of linux audio resources to ultimately make audio on linux "just work(tm?)." And if this is what most of us believe in, then having LV2 a part of the consortium is certainly a good idea. Ico > -----Original Message----- > From: linux-audio-dev-bounces@music.columbia.edu [mailto:linux-audio-dev- > bounces@music.columbia.edu] On Behalf Of Thorsten Wilms > Sent: Friday, August 11, 2006 11:10 AM > To: linux-audio-dev@music.columbia.edu > Subject: Re: [linux-audio-dev] LV2 and Linuxaudio.org > > On Thu, Aug 10, 2006 at 12:47:11PM -0400, Ivica Ico Bukvic wrote: > > To all involved in the LV2 project, I would greatly appreciate your > feedback > > regarding LV2 project becoming a member of Linuxaudio.org. Provided that > you > > decide this is a step they wish to take, it would be a good idea to > nominate > > someone as the representative of the project within the consortium. > > 50% of the core team do not even think there is a project (just a spec), > wonder what the point of the consortium is and don't like anything that > smells even remotely of business. > > So I would say no, no membership. Unless 1 of the 2 speak up. > Sorry :) > > > -- > Thorsten Wilms From paulgfx at yahoo.com Sat Aug 12 09:25:30 2006 From: paulgfx at yahoo.com (Paul) Date: Sat Aug 12 09:25:35 2006 Subject: [linux-audio-dev] New version of extreme-time stretching (with real-time support) Message-ID: <20060812132530.9092.qmail@web52210.mail.yahoo.com> Hi. I released a new version of PaulStretch, a high quality extreme time-stretching software. You can see more about it at (screenshots and examples): http://hypermammut.sourceforge.net/paulstretch/ and download it(for linux and windows) from http://sourceforge.net/projects/hypermammut News: - support for realtime stretching (as a player) - ogg vorbis support for input - improved the stretching algorithm and now it can do unlimited stretching - other Paul __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mobarre at gmail.com Sat Aug 12 09:42:50 2006 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Sat Aug 12 09:42:54 2006 Subject: [linux-audio-dev] New version of extreme-time stretching (with real-time support) In-Reply-To: <20060812132530.9092.qmail@web52210.mail.yahoo.com> References: <20060812132530.9092.qmail@web52210.mail.yahoo.com> Message-ID: <3c808a150608120642g158ff2c7i922f554f54f5e9df@mail.gmail.com> On 8/12/06, Paul wrote: > Hi. > I released a new version of PaulStretch, a high > quality extreme time-stretching software. > You can see more about it at (screenshots and > examples): > http://hypermammut.sourceforge.net/paulstretch/ > and download it(for linux and windows) from > http://sourceforge.net/projects/hypermammut > > News: > - support for realtime stretching (as a player) > - ogg vorbis support for input > - improved the stretching algorithm and now it can > do unlimited stretching > - other > > Paul > The samples sound so good ! I love it :-D -- Marc-Olivier Barre. From radarsat1 at gmail.com Sat Aug 12 13:18:17 2006 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Sat Aug 12 13:18:21 2006 Subject: [linux-audio-dev] New version of extreme-time stretching (with real-time support) In-Reply-To: <3c808a150608120642g158ff2c7i922f554f54f5e9df@mail.gmail.com> References: <20060812132530.9092.qmail@web52210.mail.yahoo.com> <3c808a150608120642g158ff2c7i922f554f54f5e9df@mail.gmail.com> Message-ID: <9b3e2dc20608121018o439e423bwfa17cd17801c9f48@mail.gmail.com> > The samples sound so good ! I love it :-D That's really quite amazing! I've written a timestretching program before, using simple fft-based phase adjustment, and although it sounded good, there were always some artifacts. I can't believe the quality of this one. Steve From a at gaydenko.com Sat Aug 12 13:40:29 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Sat Aug 12 13:41:03 2006 Subject: [linux-audio-dev] is JACK server (not) running? Message-ID: <200608122140.29309@goldspace.net> Hi! What is quickest way to determine is JACK server running or not? Just jack_client_open() call with JackNullOption takes about 5 sec when the server is not running. Andrew From jack.oquin at gmail.com Sat Aug 12 14:41:32 2006 From: jack.oquin at gmail.com (Jack O'Quin) Date: Sat Aug 12 14:41:36 2006 Subject: [linux-audio-dev] is JACK server (not) running? In-Reply-To: <200608122140.29309@goldspace.net> References: <200608122140.29309@goldspace.net> Message-ID: On 8/12/06, Andrew Gaydenko wrote: > Hi! > > What is quickest way to determine is JACK server running or not? > Just jack_client_open() call with JackNullOption takes about 5 sec > when the server is not running. You are telling JACK to actually start a new server. If you just want to check whether one is already running, use the JackNoStartServer option. Not sure how long that will take, but it should be a lot faster. -- joq From a at gaydenko.com Sat Aug 12 14:50:27 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Sat Aug 12 14:50:57 2006 Subject: [linux-audio-dev] is JACK server (not) running? In-Reply-To: References: <200608122140.29309@goldspace.net> Message-ID: <200608122250.27805@goldspace.net> Jack, Aha, I see. Now I get call return immediately. Thanks! Andrew ======= On Saturday 12 August 2006 22:41, Jack O'Quin wrote: ======= On 8/12/06, Andrew Gaydenko wrote: > Hi! > > What is quickest way to determine is JACK server running or not? > Just jack_client_open() call with JackNullOption takes about 5 sec > when the server is not running. You are telling JACK to actually start a new server. If you just want to check whether one is already running, use the JackNoStartServer option. Not sure how long that will take, but it should be a lot faster. From drobilla at connect.carleton.ca Sat Aug 12 14:51:55 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Aug 12 14:51:59 2006 Subject: [linux-audio-dev] LV2 and Linuxaudio.org In-Reply-To: <20060811150959.GA7334@charly.SWORD> References: <20060810103041.GB20471@login.ecs.soton.ac.uk> <001501c6bc9c$a1aa2400$3402a8c0@64BitBadass> <20060811150959.GA7334@charly.SWORD> Message-ID: <1155408715.3419.3.camel@localhost.localdomain> On Fri, 2006-08-11 at 17:09 +0200, Thorsten Wilms wrote: > On Thu, Aug 10, 2006 at 12:47:11PM -0400, Ivica Ico Bukvic wrote: > > To all involved in the LV2 project, I would greatly appreciate your feedback > > regarding LV2 project becoming a member of Linuxaudio.org. Provided that you > > decide this is a step they wish to take, it would be a good idea to nominate > > someone as the representative of the project within the consortium. > > 50% of the core team do not even think there is a project (just a spec), > wonder what the point of the consortium is and don't like anything that > smells even remotely of business. If I want my opinions expressed on the mailing list I will do so (without painting myself with your stereotype brushes and false accusations), thanks. -DR- From a at gaydenko.com Sat Aug 12 17:43:00 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Sat Aug 12 17:43:36 2006 Subject: [linux-audio-dev] [ANN] QLoud updated up v.0.6 Message-ID: <200608130143.00779@goldspace.net> QLoud is a tool to measure loudspeaker frequency response. Find it here: http://gaydenko.com/qloud/ Changes: - IR (Impulse Response) power plotting is added (with an appropriate screeshot), - few minor issues are fixed. Direct screenshot links: - main window with few SPL plots: http://gaydenko.com/qloud/screenshots/short01.png - IR-power plot: http://gaydenko.com/qloud/screenshots/short02.png Andrew From patrickkidd.lists at gmail.com Sat Aug 12 23:11:41 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Sat Aug 12 23:11:47 2006 Subject: [linux-audio-dev] [ANN] QLoud updated up v.0.6 In-Reply-To: <200608130143.00779@goldspace.net> References: <200608130143.00779@goldspace.net> Message-ID: <664bf2b80608122011j6b377ceeoce5ea198edcff922@mail.gmail.com> the screenshot links are broken On 8/12/06, Andrew Gaydenko wrote: > QLoud is a tool to measure loudspeaker frequency response. Find it here: > > http://gaydenko.com/qloud/ > > Changes: > > - IR (Impulse Response) power plotting is added (with an appropriate screeshot), > - few minor issues are fixed. > > Direct screenshot links: > > - main window with few SPL plots: http://gaydenko.com/qloud/screenshots/short01.png > - IR-power plot: http://gaydenko.com/qloud/screenshots/short02.png > > > Andrew > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From nettings at folkwang-hochschule.de Sun Aug 13 04:32:54 2006 From: nettings at folkwang-hochschule.de (Joern Nettingsmeier) Date: Sun Aug 13 04:33:10 2006 Subject: [linux-audio-dev] [admin] spam handling on the linux-audio-* lists Message-ID: <44DEE3B6.90301@folkwang-hochschule.de> hi everyone! just fyi, the amount of spam in the moderation queues has risen to such an extent that the server admin, douglas repetto of columbia university, has implemented an auto-clear function for the queues. that means: if your message is not forwarded to the list, it will be dead, gone and forgotten. this happens either if you are using a non-subscribed address to post (regardless of whether you are subscribed with another account, even if it's in the same domain, i.e. if j@example.com is legitimate, j@dork.example.com will bounce), or if mailman determines you are posting html. due to a misunderstanding, this auto-nuking has been active on linux-audio-announce as well for the past couple of days. so if you tried to get an announcement out, please resend - the old one went straight to the bit bucket. regards, j?rn -- 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 dominique.michel at citycable.ch Sun Aug 13 06:46:35 2006 From: dominique.michel at citycable.ch (Dominique Michel) Date: Sun Aug 13 06:46:48 2006 Subject: [linux-audio-dev] 2.6.15.7-rt In-Reply-To: <20060809232054.GD22705@jdboyd> References: <20060809232054.GD22705@jdboyd> Message-ID: <20060813124635.45f3b792@localhost> Le Wed, 9 Aug 2006 19:20:54 -0400, Joshua Boyd a ?crit : > I just upgraded my LFS 6.1 system from 2.6.12 (with preempt, but not the > -rt patch) to 2.6.15-rt (enabling high resolution timers and PREEMPT_RT > along the way), and now my audio driver is dropping interrupts every few > seconds, something it wasn't doing before. > > I haven't configured rtlimits since the program runs as root anyway, and > I'd like it to be free to hog quite a lot if need be. > > In my application (which runs in SCHED_FIFO), the audio thread runs at > -10, while the video thread runs at -19. I don't know if that is best, > I just wanted them to be higher than the other threads. > > Also, outside forces, like a ssh connection, or a USB dongle connection > cause the program to drop audio madly. Is there some code I need to be > adding to force such system tasks down rather than just elevating my own > application? > A rt kernel will be of almost no use if you don't fix the priorities. You can use PAM-rlimits or the realtime-lsm module for that, and you have to be in the audio group. The audio group will have a higher priority and this is the right way to do that. You can take a lock at http://demudi.agnula.org/wiki/Low-latencyKernelBuildingHowto#Realtimescheduling PAM-rlimits is the new way of doing that, but if you want an very low latency for intensive audio work as synthesis or filter, the realtime.lsm will be better. A very important issue with a rt kernel is at you must not have shared IRQ with a such kernel. You can check it with # cat /proc/interrupts It is specially important for the sound and the video card. http://ardour.org/system_requirements If you are new with rt-kernel, I would recommend you to install an audio distribution as Demudi, planet CCRMA, jacklab, musix, or the gentoo audio pro overlay. They all have that rt stuff trimmed for you. With usb audio card, the IRQ period of the USB bus is 1 msec. That mean at you must use something as 48KHz 3 periods with jack (That will be a multiple of that irq period) in order to get a low latency with such sound cards. And you MUST NOT be root in all cases with a rt-kernel. From a at gaydenko.com Sun Aug 13 07:09:52 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Sun Aug 13 07:10:26 2006 Subject: [linux-audio-dev] [ANN] QLoud updated up v.0.6 In-Reply-To: <664bf2b80608122011j6b377ceeoce5ea198edcff922@mail.gmail.com> References: <200608130143.00779@goldspace.net> <664bf2b80608122011j6b377ceeoce5ea198edcff922@mail.gmail.com> Message-ID: <200608131509.52409@goldspace.net> Sorry, my ugly English is a reason :-) Must be: - main window with few SPL plots: http://gaydenko.com/qloud/screenshots/shot01.png - IR-power plot: http://gaydenko.com/qloud/screenshots/shot02.png Andrew ======= On Sunday 13 August 2006 07:11, Patrick Stinson wrote: ======= the screenshot links are broken On 8/12/06, Andrew Gaydenko wrote: > QLoud is a tool to measure loudspeaker frequency response. Find it here: > > http://gaydenko.com/qloud/ > > Changes: > > - IR (Impulse Response) power plotting is added (with an appropriate screeshot), > - few minor issues are fixed. > > Direct screenshot links: > > - main window with few SPL plots: http://gaydenko.com/qloud/screenshots/short01.png > - IR-power plot: http://gaydenko.com/qloud/screenshots/short02.png > > > Andrew > From mista.tapas at gmx.net Sun Aug 13 07:51:50 2006 From: mista.tapas at gmx.net (Florian Paul Schmidt) Date: Sun Aug 13 07:52:09 2006 Subject: [linux-audio-dev] 2.6.15.7-rt In-Reply-To: <20060813124635.45f3b792@localhost> References: <20060809232054.GD22705@jdboyd> <20060813124635.45f3b792@localhost> Message-ID: <20060813135150.649e4294@mango.fruits> On Sun, 13 Aug 2006 12:46:35 +0200 Dominique Michel wrote: > A rt kernel will be of almost no use if you don't fix the priorities. > You can use PAM-rlimits or the realtime-lsm module for that, and you > have to be in the audio group. > > The audio group will have a higher priority and this is the right way > to do that. > > You can take a lock at > http://demudi.agnula.org/wiki/Low-latencyKernelBuildingHowto#Realtimescheduling > > PAM-rlimits is the new way of doing that, but if you want an very > low latency for intensive audio work as synthesis or filter, the > realtime.lsm will be better. There's no difference wrt to achievable latencies regarding lsm and pam. Both are just ways to grant non root users SCHED_FIFO priorities for their tasks. > A very important issue with a rt kernel is at you must not have shared > IRQ with a such kernel. You can check it with > # cat /proc/interrupts > It is specially important for the sound and the video card. > http://ardour.org/system_requirements This is also not true stated like that. It is very well possible to have shared IRQ's in a -rt system. Usually one doesn't want to have one's soundcard IRQ shared though, because then the other device driver [and irq handler] runs at the same prio potentially causing delays for out soundcard. > > If you are new with rt-kernel, I would recommend you to install an > audio distribution as Demudi, planet CCRMA, jacklab, musix, or the > gentoo audio pro overlay. They all have that rt stuff trimmed for you. > > With usb audio card, the IRQ period of the USB bus is 1 msec. That > mean at you must use something as 48KHz 3 periods with jack (That will > be a multiple of that irq period) in order to get a low > latency with such sound cards. > And you MUST NOT be root in all cases with a rt-kernel. This is also not true. Of course it is possible to run your stuff as root with a -rt kernel. This also saves you the hassle of setting up either the realtime lsm or pam. But it is not recommended as running user stuff as root is often a security risk. Flo -- Palimm Palimm! http://tapas.affenbande.org From dominique.michel at citycable.ch Sun Aug 13 09:07:04 2006 From: dominique.michel at citycable.ch (Dominique Michel) Date: Sun Aug 13 09:07:15 2006 Subject: [linux-audio-dev] 2.6.15.7-rt In-Reply-To: <20060813135150.649e4294@mango.fruits> References: <20060809232054.GD22705@jdboyd> <20060813124635.45f3b792@localhost> <20060813135150.649e4294@mango.fruits> Message-ID: <20060813150704.7456324d@localhost> Le Sun, 13 Aug 2006 13:51:50 +0200, Florian Paul Schmidt a ?crit : > On Sun, 13 Aug 2006 12:46:35 +0200 > Dominique Michel wrote: > > > A rt kernel will be of almost no use if you don't fix the priorities. > > You can use PAM-rlimits or the realtime-lsm module for that, and you > > have to be in the audio group. > > > > The audio group will have a higher priority and this is the right way > > to do that. > > > > You can take a lock at > > http://demudi.agnula.org/wiki/Low-latencyKernelBuildingHowto#Realtimescheduling > > > > PAM-rlimits is the new way of doing that, but if you want an very > > low latency for intensive audio work as synthesis or filter, the > > realtime.lsm will be better. > > There's no difference wrt to achievable latencies regarding lsm and pam. > Both are just ways to grant non root users SCHED_FIFO priorities for > their tasks. > From http://www.jacklab.net/phpBB2/viewtopic.php?t=103 : "Model 1: " Want to start a synth from time to time" SUSE Standard kernel with PAM from Rui (also available in the jacklab repository) Model 2 "Want to work with MusE or Rosegarden from time to time" JAD kernel and PAM (Because the SUSE Standard Kernel have no midi RT tick for sequencers) Model 3 " I want make some fat production / live performing with many native FX and soundgenerators with less then 10ms audiolatency" JAD Kernel and RT-LSM (WARNING: RT-LSM can maybe crash your system)" It is other websites that say exactly the same. I have done some test too. The result was a better (lower) latency with the rt-lsm. The difference was not big, but it was a difference, and it was a few xruns with PAM-rlimits already with 20% processor use when it was no xrun with the rt-lsm, the same jackd setting and the same running programs and processor use. Another issue is at I was a few times in trouble with the PAM-rlimits feature that kill any application that is doing a very high processor use. So, I definitely prefer the realtime-lsm. > > A very important issue with a rt kernel is at you must not have shared > > IRQ with a such kernel. You can check it with > > # cat /proc/interrupts > > It is specially important for the sound and the video card. > > http://ardour.org/system_requirements > > This is also not true stated like that. It is very well possible to have > shared IRQ's in a -rt system. Usually one doesn't want to have one's > soundcard IRQ shared though, because then the other device driver [and > irq handler] runs at the same prio potentially causing delays for out > soundcard. > If I share the same hardware IRQ with my soud card and another hardware, my whole system just hang from time to time, and that both with the PIC and with the APIC irq interface. The same append with the video card. And that with Demudi, gentoo with my own rt-kernel or with the audio pro rt-kernel, and before with Suse and a rt-kernel. I have to go in the Bios to reassign the IRQ and/or move the cards from slot to slot in order to solve this. > > > > If you are new with rt-kernel, I would recommend you to install an > > audio distribution as Demudi, planet CCRMA, jacklab, musix, or the > > gentoo audio pro overlay. They all have that rt stuff trimmed for you. > > > > With usb audio card, the IRQ period of the USB bus is 1 msec. That > > mean at you must use something as 48KHz 3 periods with jack (That will > > be a multiple of that irq period) in order to get a low > > latency with such sound cards. > > > And you MUST NOT be root in all cases with a rt-kernel. > > This is also not true. Of course it is possible to run your stuff as > root with a -rt kernel. This also saves you the hassle of setting up > either the realtime lsm or pam. It is why I recommend the use of an audio distribution for a new user of a rt kernel. > But it is not recommended as running > user stuff as root is often a security risk. And programs as bristol will just hang the whole system when running as root or suid root with a rt-kernel. It is one of the advantage of a rt-kernel: you can run jack with rt priority as normal user (in the audio group), and it is the right way to use such a kernel. Cheers, Dominique > > Flo > From t_w_ at freenet.de Mon Aug 14 05:26:53 2006 From: t_w_ at freenet.de (t_w_@freenet.de) Date: Mon Aug 14 05:27:16 2006 Subject: [linux-audio-dev] LV2 and Linuxaudio.org Message-ID: On Sat Aug 12 2006 - 21:51:55 EEST, Dave Robillard wrote: >> On Fri, 2006-08-11 at 17:09 +0200, Thorsten Wilms wrote: >> 50% of the core team do not even think there is a project (just a spec), >> wonder what the point of the consortium is and don't like anything that >> smells even remotely of business. > If I want my opinions expressed on the mailing list I will do so > (without painting myself with your stereotype brushes and false > accusations), thanks. Well, it bothered me you didn't even reply with a simple "not interested". Wanted to provide some hooks for Ico to say something about what the consortium is and isn't about. I'm sorry for trying to provoke you to step forward by use of attempted humour by exaggeration (somehow i thought nobody would take a something starting with "50% of the core team" dead serious). I don't see where stereotypes come into play (to me, you're a type of his own :p Nothing of this was meant as accusation. -- Thorsten Wilms "Jetzt Handykosten senken mit klarmobil - 14 Ct./Min.! Hier klicken" http://www.klarmobil.de/index.html?pid=73025 From S.W.Harris at ecs.soton.ac.uk Mon Aug 14 09:37:44 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Mon Aug 14 09:38:07 2006 Subject: [linux-audio-dev] LV2 and Linuxaudio.org In-Reply-To: <001501c6bc9c$a1aa2400$3402a8c0@64BitBadass> References: <20060810103041.GB20471@login.ecs.soton.ac.uk> <001501c6bc9c$a1aa2400$3402a8c0@64BitBadass> Message-ID: <20060814133744.GB10081@login.ecs.soton.ac.uk> On Thu, Aug 10, 2006 at 12:47:11 -0400, Ivica Ico Bukvic wrote: > To all involved in the LV2 project, I would greatly appreciate your feedback > regarding LV2 project becoming a member of Linuxaudio.org. Provided that you > decide this is a step they wish to take, it would be a good idea to nominate > someone as the representative of the project within the consortium. FWIW, I think it would be a good idea. However, it's not clear that there exists an LV2 "thing" to be a member of anything. Perhaps the LV2 specifcation site (http://lv2plug.in/) could be a member? If there was a consensus that it was a good idea, I'd be happy to state that. Or something. Also, there could actually be a LV2 project, mailing list etc. created, theres a DAV repository at lv2plug.in, and people hack on the contents, so it does kinda make sense. - Steve From t_w_ at freenet.de Mon Aug 14 13:09:59 2006 From: t_w_ at freenet.de (t_w_@freenet.de) Date: Mon Aug 14 13:10:08 2006 Subject: [linux-audio-dev] LV2 and Linuxaudio.org Message-ID: Gesendet: Mo 14 Aug 2006 15:38:29 CEST Von: "Steve Harris" > FWIW, I think it would be a good idea. However, it's not clear that there > exists an LV2 "thing" to be a member of anything. I'm only responsible for the website and logo but also think it's a good idea. At least I don't see how it could hurt ;) > Perhaps the LV2 specifcation site (http://lv2plug.in/) could be a member? > If there was a consensus that it was a good idea, I'd be happy to state > that. Or something. > > Also, there could actually be a LV2 project, mailing list etc. created, > theres a DAV repository at lv2plug.in, and people hack on the contents, so > it does kinda make sense. Sounds good. I would like to nominate Steve Harris as representative :) -- Thorsten Wilms From mista.tapas at gmx.net Tue Aug 15 04:02:25 2006 From: mista.tapas at gmx.net (Florian Paul Schmidt) Date: Tue Aug 15 04:02:41 2006 Subject: [linux-audio-dev] 2.6.15.7-rt In-Reply-To: <20060813150704.7456324d@localhost> References: <20060809232054.GD22705@jdboyd> <20060813124635.45f3b792@localhost> <20060813135150.649e4294@mango.fruits> <20060813150704.7456324d@localhost> Message-ID: <20060815100225.56f44abf@mango.fruits> On Sun, 13 Aug 2006 15:07:04 +0200 Dominique Michel wrote: > From http://www.jacklab.net/phpBB2/viewtopic.php?t=103 : > "Model 1: " Want to start a synth from time to time" > SUSE Standard kernel with PAM from Rui (also available in the jacklab > repository) > > Model 2 "Want to work with MusE or Rosegarden from time to time" > JAD kernel and PAM (Because the SUSE Standard Kernel have no midi RT > tick for sequencers) > > Model 3 " I want make some fat production / live performing with many > native FX and soundgenerators with less then 10ms audiolatency" JAD > Kernel and RT-LSM (WARNING: RT-LSM can maybe crash your system)" > > It is other websites that say exactly the same. Many websites saying the same thing doesn't nessecarily make this true. Of course there are some subtle differences between rlimits and the realtime lsm: - rlimits allow specifying a maximum priority which uers processes are allowed to aquire - rt lsm otoh gives the user the ability to use any rt priority [or none at all] - rlimits allow specifying a maximum memory size for mlocking. - rt lsm otoh again gives the user the ability to use any amount [or none at all] - rlimits allow specifying a maximum niceness which user processes are allowes to aquire - rt lsm otoh ... [well you get the picture] The point being that rlimits allow for finer control of what a user process is allowed to do. So depending on how you have rlimits configured, you might get differing results from a rt lsm installation. So let me rephrase my statement: Given that you have setup rlimtis and rt lsm in equivalent ways, there must be no measurable difference in achievable latencies. If you do measure differences, some other factor of your setup differs, too. Like i said: To my knowledge rt lsm and rlimits are just two different ways to achieve the same thing: Giving user processes rt scheduling, mlocking and negative niceness. As my experience with rlimtis is limited, i still have one more question regarding the funcitonality of rlimits. It once was discussed on the mailing lists to include cpu usage throtteling for user processes (i.e. max. 90% cpu usage, so that runaway processes cannot fully lock the box). Has this been implemented? > Another issue is at I was a few times in trouble with the PAM-rlimits > feature that kill any application that is doing a very high processor > use. So, I definitely prefer the realtime-lsm. I don't know that rlimits kill processes on high cpu load. Never heard of this feature. Flo -- Palimm Palimm! http://tapas.affenbande.org From mista.tapas at gmx.net Tue Aug 15 04:32:52 2006 From: mista.tapas at gmx.net (Florian Paul Schmidt) Date: Tue Aug 15 04:33:02 2006 Subject: [linux-audio-dev] 2.6.15.7-rt In-Reply-To: <20060815100225.56f44abf@mango.fruits> References: <20060809232054.GD22705@jdboyd> <20060813124635.45f3b792@localhost> <20060813135150.649e4294@mango.fruits> <20060813150704.7456324d@localhost> <20060815100225.56f44abf@mango.fruits> Message-ID: <20060815103252.497c8f92@mango.fruits> On Tue, 15 Aug 2006 10:02:25 +0200 Florian Paul Schmidt wrote: > Given that you have setup rlimtis and rt lsm in equivalent ways, there > must be no measurable difference in achievable latencies. If you do > measure differences, some other factor of your setup differs, too. Let me add: If you actually have setup rt lsm and rlimits in an equivalent way and the rest of the system is the same, too, and you still measure a difference, then you have found a bug in the kernel. Please report it to lkml. Flo -- Palimm Palimm! http://tapas.affenbande.org From langagemachine at gmail.com Tue Aug 15 04:37:35 2006 From: langagemachine at gmail.com (_ langagemachine) Date: Tue Aug 15 04:37:43 2006 Subject: [linux-audio-dev] Which sequencer framework for a simple MIDI drum looper ? Message-ID: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> Hello. I write hoping that some nice LADs might enlighten me ? I've been feeling a recent itch to write a simple step-sequencer, which outputs MIDI messages to the ALSA seq ; it is intended to drive a drum machine. My ideal app is provided with a graphical UI which includes HUGE buttons (to give you an idea, the GUI in FL Studio comes to mind). It may seem silly at this point, but I could not find an existing app which exactly suits me. But anyway, I think it will be a piece of fun trying to write something myself... I shamefully admit being no good at C/C++ programming, but I could write some GUI code in Python/Java, which would communicate with the sequencer engine, over OSC for example. Regarding said sequencing engine, I have found 3 possibilities so far : - Chuck http://chuck.cs.princeton.edu/ - Midishare (can be driven in Java, Lisp, ...) *provided that I can get it to compile on my Gentoo box ... http://midishare.sourceforge.net/ - Milk (Python MIDI engine for ALSA) http://www.quitte.de/milk.html: The former two seem slightly more complete ; in particular, I very much liked Breakage, which uses Chuck : http://www.blackholeprojector.com/ (Actually, this app would have been a very good fit, but it is Windows/Mac only :-o) I'll finally make my point : which framework would - in your experience - be the most practical to use ? Or the most interesting to learn ? Many thanks for your attention. NB : I am aware that Hydrogen is one fine app ;-), and probably a step sequencer can be written as a Pd patch in seconds, but that is not what I am after at the moment ; I insist on the user interacting with big, Playschool-like BLOCKS :-) From pshirkey at boosthardware.com Tue Aug 15 05:00:58 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Tue Aug 15 05:01:44 2006 Subject: [linux-audio-dev] Which sequencer framework for a simple MIDI drum looper ? In-Reply-To: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> References: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> Message-ID: <44E18D4A.6020004@boosthardware.com> _ langagemachine wrote: > Hello. > > The former two seem slightly more complete ; in particular, I very > much liked Breakage, which uses Chuck : > http://www.blackholeprojector.com/ > (Actually, this app would have been a very good fit, but it is > Windows/Mac only :-o) > Why not port it to linux? -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://lau.linuxaudio.org - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From Jan.Weil at web.de Tue Aug 15 05:08:10 2006 From: Jan.Weil at web.de (Jan Weil) Date: Tue Aug 15 05:08:17 2006 Subject: [linux-audio-dev] Which sequencer framework for a simple MIDI drum looper ? In-Reply-To: <44E18D4A.6020004@boosthardware.com> References: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> <44E18D4A.6020004@boosthardware.com> Message-ID: <1155632890.4490.1.camel@localhost.localdomain> On Tue, 2006-08-15 at 16:00 +0700, Patrick Shirkey wrote: > _ langagemachine wrote: > > Hello. > > > > > The former two seem slightly more complete ; in particular, I very > > much liked Breakage, which uses Chuck : > > http://www.blackholeprojector.com/ > > (Actually, this app would have been a very good fit, but it is > > Windows/Mac only :-o) > > > > Why not port it to linux? > "What platforms does Breakage run on? Mac OS X, Windows and Linux." ??? From jstutters at jeremah.co.uk Tue Aug 15 05:11:24 2006 From: jstutters at jeremah.co.uk (Jonny Stutters) Date: Tue Aug 15 05:11:34 2006 Subject: [linux-audio-dev] Which sequencer framework for a simple MIDI drum looper ? In-Reply-To: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> References: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> Message-ID: <44E18FBC.8070709@jeremah.co.uk> _ langagemachine wrote: > The former two seem slightly more complete ; in particular, I very > much liked Breakage, which uses Chuck : > http://www.blackholeprojector.com/ > (Actually, this app would have been a very good fit, but it is > Windows/Mac only :-o) Actually, if you look at the FAQ on the Breakage site it claims to run on Linux as well. It's Java so I guess if you download the "ChucK-less" version from their site and acquire ChucK for yourself that should do it. -- Jonny Music - http://jeremah.co.uk News - http://voxpolis.com From langagemachine at gmail.com Tue Aug 15 06:04:03 2006 From: langagemachine at gmail.com (_ langagemachine) Date: Tue Aug 15 06:04:10 2006 Subject: [linux-audio-dev] Which sequencer framework for a simple MIDI drum looper ? In-Reply-To: <44E18FBC.8070709@jeremah.co.uk> References: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> <44E18FBC.8070709@jeremah.co.uk> Message-ID: <49f299470608150304w73b73cffg817a1d494572b64c@mail.gmail.com> Oh, you are right : there are 3 downloads : Mac, Windows and ChucK-less. I have downloaded the ChucK-less version, and it launches ChucK and Jack alright; i only had to create symlink ln -s /usr/bin/chuck ./chuck 2006/8/15, Jonny Stutters : > _ langagemachine wrote: > > The former two seem slightly more complete ; in particular, I very > > much liked Breakage, which uses Chuck : > > http://www.blackholeprojector.com/ > > (Actually, this app would have been a very good fit, but it is > > Windows/Mac only :-o) > > Actually, if you look at the FAQ on the Breakage site it claims to run > on Linux as well. It's Java so I guess if you download the "ChucK-less" > version from their site and acquire ChucK for yourself that should do it. > > -- > Jonny > > Music - http://jeremah.co.uk > News - http://voxpolis.com > From langagemachine at gmail.com Tue Aug 15 06:08:59 2006 From: langagemachine at gmail.com (_ langagemachine) Date: Tue Aug 15 06:09:37 2006 Subject: [linux-audio-dev] Which sequencer framework for a simple MIDI drum looper ? In-Reply-To: <44E18FBC.8070709@jeremah.co.uk> References: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> <44E18FBC.8070709@jeremah.co.uk> Message-ID: <49f299470608150308w29aa2d88k414312aaf239695a@mail.gmail.com> Sorry, posted sent itself :-o Oh, you are right : there are 3 downloads : Mac, Windows and ChucK-less. I have downloaded the ChucK-less version, and it launches ChucK and Jack alright; i only had to create symlink ln -s /usr/bin/chuck to ./chuck The Java part is free but not open-source, though. Thanks for making me notice ; I have some material to play around with :-) Is there activity around midishare ? The forum does not seem to have been too busy recently. 2006/8/15, Jonny Stutters : > _ langagemachine wrote: > > The former two seem slightly more complete ; in particular, I very > > much liked Breakage, which uses Chuck : > > http://www.blackholeprojector.com/ > > (Actually, this app would have been a very good fit, but it is > > Windows/Mac only :-o) > > Actually, if you look at the FAQ on the Breakage site it claims to run > on Linux as well. It's Java so I guess if you download the "ChucK-less" > version from their site and acquire ChucK for yourself that should do it. > > -- > Jonny > > Music - http://jeremah.co.uk > News - http://voxpolis.com > From fbar at footils.org Tue Aug 15 06:27:15 2006 From: fbar at footils.org (Frank Barknecht) Date: Tue Aug 15 06:27:51 2006 Subject: [linux-audio-dev] Which sequencer framework for a simple MIDI drum looper ? In-Reply-To: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> References: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> Message-ID: <20060815102714.GF4992@fliwatut.scifi> Hallo, _ langagemachine hat gesagt: // _ langagemachine wrote: > NB : I am aware that Hydrogen is one fine app ;-), and probably a step > sequencer can be written as a Pd patch in seconds, but that is not > what I am after at the moment ; I insist on the user interacting with > big, Playschool-like BLOCKS :-) You can make these kind of blocks with Pd as well: http://footils.org/images/sequence.png Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From langagemachine at gmail.com Tue Aug 15 06:52:32 2006 From: langagemachine at gmail.com (_ langagemachine) Date: Tue Aug 15 06:52:46 2006 Subject: [linux-audio-dev] Which sequencer framework for a simple MIDI drum looper ? In-Reply-To: <20060815102714.GF4992@fliwatut.scifi> References: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> <20060815102714.GF4992@fliwatut.scifi> Message-ID: <49f299470608150352i56d0aabfx625e917c3449a2d5@mail.gmail.com> Waoo, I didn' t know that. Thanks Frank. 2006/8/15, Frank Barknecht : > Hallo, > _ langagemachine hat gesagt: // _ langagemachine wrote: > > > NB : I am aware that Hydrogen is one fine app ;-), and probably a step > > sequencer can be written as a Pd patch in seconds, but that is not > > what I am after at the moment ; I insist on the user interacting with > > big, Playschool-like BLOCKS :-) > > You can make these kind of blocks with Pd as well: > http://footils.org/images/sequence.png > > Ciao > -- > Frank Barknecht _ ______footils.org_ __goto10.org__ > From lars.luthman at gmail.com Tue Aug 15 07:07:23 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Tue Aug 15 07:07:01 2006 Subject: [linux-audio-dev] Which sequencer framework for a simple MIDI drum looper ? In-Reply-To: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> References: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> Message-ID: <1155640043.21965.12.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> On Tue, 2006-08-15 at 10:37 +0200, _ langagemachine wrote: > Hello. > > I write hoping that some nice LADs might enlighten me ? > > I've been feeling a recent itch to write a simple step-sequencer, > which outputs MIDI messages to the ALSA seq ; it is intended to drive > a drum machine. My ideal app is provided with a graphical UI which > includes HUGE buttons (to give you an idea, the GUI in FL Studio comes > to mind). > > It may seem silly at this point, but I could not find an existing app > which exactly suits me. > But anyway, I think it will be a piece of fun trying to write > something myself... > > I shamefully admit being no good at C/C++ programming, but I could > write some GUI code in Python/Java, which would communicate with the > sequencer engine, over OSC for example. There are Python bindings for the Dino library. It's not released yet though and it uses JACK, not ALSA-seq, so it's probably not what you want. -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E 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/20060815/5de3e6c4/attachment.bin From langagemachine at gmail.com Tue Aug 15 07:50:10 2006 From: langagemachine at gmail.com (_ langagemachine) Date: Tue Aug 15 07:50:20 2006 Subject: [linux-audio-dev] Which sequencer framework for a simple MIDI drum looper ? In-Reply-To: <1155640043.21965.12.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> References: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> <1155640043.21965.12.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> Message-ID: <49f299470608150450w2b6f0b1cud1ae3c4a002c9cce@mail.gmail.com> That is interesting anyway ; please do let us know when it comes out ;-) 2006/8/15, Lars Luthman : > On Tue, 2006-08-15 at 10:37 +0200, _ langagemachine wrote: > > Hello. > > > > I write hoping that some nice LADs might enlighten me ? > > > > I've been feeling a recent itch to write a simple step-sequencer, > > which outputs MIDI messages to the ALSA seq ; it is intended to drive > > a drum machine. My ideal app is provided with a graphical UI which > > includes HUGE buttons (to give you an idea, the GUI in FL Studio comes > > to mind). > > > > It may seem silly at this point, but I could not find an existing app > > which exactly suits me. > > But anyway, I think it will be a piece of fun trying to write > > something myself... > > > > I shamefully admit being no good at C/C++ programming, but I could > > write some GUI code in Python/Java, which would communicate with the > > sequencer engine, over OSC for example. > > There are Python bindings for the Dino library. It's not released yet > though and it uses JACK, not ALSA-seq, so it's probably not what you > want. > > -- > Lars Luthman - please encrypt any email sent to me if possible > PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E > Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E > > > From conrad.berhoerster at gmx.de Tue Aug 15 09:30:47 2006 From: conrad.berhoerster at gmx.de (conrad =?iso-8859-1?q?berh=F6rster?=) Date: Tue Aug 15 09:32:49 2006 Subject: [linux-audio-dev] scaling jackinput to dbSPL Message-ID: <200608151530.48412.conrad.berhoerster@gmx.de> Hello all, Does anybody know, how i can scale the incoming jack signals to dbSPL, which is in the range of 0 to 120. An is it possible to calculate from dbFS (which is used in normal soundapp in range -inf to 12db) into dbSPL. thanks c~ From smcameron at yahoo.com Tue Aug 15 09:43:02 2006 From: smcameron at yahoo.com (Stephen Cameron) Date: Tue Aug 15 09:43:09 2006 Subject: [linux-audio-dev] Which sequencer framework for a simple MIDI drum looper ? In-Reply-To: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> Message-ID: <20060815134302.63564.qmail@web33009.mail.mud.yahoo.com> --- _ langagemachine wrote: > Hello. > > I write hoping that some nice LADs might enlighten me ? > > I've been feeling a recent itch to write a simple step-sequencer, > which outputs MIDI messages to the ALSA seq ; it is intended to drive > a drum machine. My ideal app is provided with a graphical UI which > includes HUGE buttons (to give you an idea, the GUI in FL Studio comes > to mind). > > It may seem silly at this point, but I could not find an existing app > which exactly suits me. > But anyway, I think it will be a piece of fun trying to write > something myself... > You might take a look at gneutronica, the result of me scratching a similar itch. http://gneutronica.sourceforge.net It's surely not exactly what you're after, but if you had in mind C, gnome based UI, alsa sequencer interface (though, maybe a somewhat naive implementation, as I was just learning all that stuff as I went) it might be something worth looking at as an example, and there might even be some code you could grab from it. It doesn't talk to JACK... someday I might get around to figurnig out how to do that, but it's not in there now. > I shamefully admit being no good at C/C++ programming, but I could > write some GUI code in Python/Java, which would communicate with the > sequencer engine, over OSC for example. Oh, well... maybe gneutronica's not what you're looking for then. -- steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From dominique.michel at citycable.ch Tue Aug 15 09:59:45 2006 From: dominique.michel at citycable.ch (Dominique Michel) Date: Tue Aug 15 09:59:54 2006 Subject: [linux-audio-dev] scaling jackinput to dbSPL In-Reply-To: <200608151530.48412.conrad.berhoerster@gmx.de> References: <200608151530.48412.conrad.berhoerster@gmx.de> Message-ID: <20060815155945.117d419d@localhost> Le Tue, 15 Aug 2006 15:30:47 +0200, conrad berh?rster a ?crit : > Hello all, > > Does anybody know, how i can scale the incoming jack signals to dbSPL, > which is in the range of 0 to 120. An is it possible to calculate from dbFS > (which is used in normal soundapp in range -inf to 12db) into dbSPL. > > thanks c~ Look here: http://en.wikipedia.org/wiki/Sound_pressure http://en.wikipedia.org/wiki/DBFS http://en.wikipedia.org/wiki/Decibel The dbFS is an abbreviation for decibel amplitude levels in digital systems which have a maximum available level (like PCM encoding). 0 dBFS is assigned to the maximum possible level. The dbSPL correspond to the physical sound pressure level you have in a given area. It can be in a range of whatever you want or can archive. It will depend on many factors and you have to measure it. And more, it will be true only at the location you have done the measurement. It you want to archive a constant sound level in a great area, you have to use multiple speakers and amplifiers, and setup the volume level in each amplifier with measurement of the sound level in different points of the area. Cheers, Dominique From jayv at synth.net Tue Aug 15 10:03:15 2006 From: jayv at synth.net (Jay Vaughan) Date: Tue Aug 15 10:03:30 2006 Subject: [linux-audio-dev] Which sequencer framework for a simple MIDI drum looper ? In-Reply-To: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> References: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> Message-ID: >- Midishare (can be driven in Java, Lisp, ...) *provided that I can >get it to compile on my Gentoo box ... >http://midishare.sourceforge.net/ I work with MidiShare quite a bit, and I have to say that if you get it going on your system, it really is one of the nicest, best-performing MIDI API's around .. of course the fact that it comes with a Sequencer lib that supports up to 256 tracks is a bonus too .. ;) That said, it may not be quite "ALSA mainstream" enough of an API to warrant usage, but if you have control over your system and get MidiShare.o built and in use, you've got a damn fine MIDI API, oft-overlooked .. -- ; Jay Vaughan From S.W.Harris at ecs.soton.ac.uk Tue Aug 15 10:09:11 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue Aug 15 10:09:38 2006 Subject: [linux-audio-dev] scaling jackinput to dbSPL In-Reply-To: <200608151530.48412.conrad.berhoerster@gmx.de> References: <200608151530.48412.conrad.berhoerster@gmx.de> Message-ID: <20060815140911.GA7596@login.ecs.soton.ac.uk> On Tue, Aug 15, 2006 at 03:30:47 +0200, conrad berh?rster wrote: > Hello all, > > Does anybody know, how i can scale the incoming jack signals to dbSPL, > which is in the range of 0 to 120. An is it possible to calculate from dbFS > (which is used in normal soundapp in range -inf to 12db) into dbSPL. dB SPL is a measurement of physical sound energy, so in general software was no control over it. It depends on the efficientcy of your monitors, gain of your amps, desk etc. The only way you can relate dB SPL to dB FS is by calibrating your particular setup using a sound level meter. There's a SMPTE standard for the relationship between dB SPL and dBu or dBv (I forget which), which gets you half way there, but noone uses it anyway. I had my home system calibrated to SMPTE for a while, and it was just anoying. Bob Katz advocates the "K-system" calibration, which is different again, and also not very common. http://www.digido.com/portal/pmodule_id=11/pmdmode=fullscreen/pageadder_page_id=59 - Steve From dmills_00 at yahoo.co.uk Tue Aug 15 10:25:06 2006 From: dmills_00 at yahoo.co.uk (Dan Mills) Date: Tue Aug 15 10:25:22 2006 Subject: [linux-audio-dev] scaling jackinput to dbSPL In-Reply-To: <200608151530.48412.conrad.berhoerster@gmx.de> Message-ID: <20060815142506.51780.qmail@web27914.mail.ukl.yahoo.com> --- conrad berh?rster wrote: > Hello all, > > Does anybody know, how i can scale the incoming jack > signals to dbSPL, > which is in the range of 0 to 120. An is it possible > to calculate from dbFS > (which is used in normal soundapp in range -inf to > 12db) into dbSPL. > > thanks c~ Look up what voltage corresponds to 0dbFS, then given a known sensitivity figure for the microphone and a known gain for the preamp do the math. For example if 0dbFS is specified as corresponding to +22dbu (actually a voltage reference BTW), and you establish that 100dbSPL gives an output of say -50dbu from the mic, then if your preamp has a gain of say 50db, the math looks like this: 100dbSPL = -50dbu at mic, so 0dbSPL = -150dbu at mic (burried in the nose floor in all probability), the preamp has 50db gain so the output will be -100dbu at 0dbSPL. At 120dbSPL (assuming a well behaved mic and preamp), you will have +20dbu, now the Full sacle value is specified as +22dbu, so a 20dbu input will read -2dbFS , therefore in this example SPL = 122 + DBFS (always negative). This calibration obviously needs to be made for each microphone/preamp/card combination if you want decent accuracy. In practice, I would try to set up for the top of my measurement range to be about 10db or so below 0dbFS as you typically want RMS measurements and 0dbFS is a peak value and a very unforgiving place. Some of the better card manufacturers specify things like 0dbu output for -20dbFS which is obviously saying that 0DBFS = +20dbu Regards, Dan. ___________________________________________________________ The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html From conrad.berhoerster at gmx.de Tue Aug 15 11:27:59 2006 From: conrad.berhoerster at gmx.de (conrad =?iso-8859-1?q?berh=F6rster?=) Date: Tue Aug 15 11:29:45 2006 Subject: [linux-audio-dev] scaling jackinput to dbSPL In-Reply-To: <20060815140911.GA7596@login.ecs.soton.ac.uk> References: <200608151530.48412.conrad.berhoerster@gmx.de> <20060815140911.GA7596@login.ecs.soton.ac.uk> Message-ID: <200608151728.01940.conrad.berhoerster@gmx.de> Whoow , that was fast.... maybe i was a little bit misunderstandable. when i wrote about jack, i meant the jackserver. i write an app, which has an microphon input. now i will take this microphon signal and show it as a gain meter. this is no magic and everything works. if i understand all of you right, the pressure on the microphon is something greater 0. and normally it is lower 2, right? first question: is this the same pressure which is measured in the literature in pascal (pa) if so, its easy to calculate out_value = 20.00*(Math.log(in_value/0.00002)/Math.log(10.00)); I know, i need to calibrate the room at the end. But in the moment, my question is simply to get a signal and show the loundness in dbSPL. Can i use the formula above or not? thanks c~ Am Dienstag 15 August 2006 16:09 schrieb Steve Harris: > On Tue, Aug 15, 2006 at 03:30:47 +0200, conrad berh?rster wrote: > > Hello all, > > > > Does anybody know, how i can scale the incoming jack signals to dbSPL, > > which is in the range of 0 to 120. An is it possible to calculate from > > dbFS (which is used in normal soundapp in range -inf to 12db) into > > dbSPL. > > dB SPL is a measurement of physical sound energy, so in general software > was no control over it. It depends on the efficientcy of your monitors, > gain of your amps, desk etc. > > The only way you can relate dB SPL to dB FS is by calibrating your > particular setup using a sound level meter. There's a SMPTE standard for > the relationship between dB SPL and dBu or dBv (I forget which), which > gets you half way there, but noone uses it anyway. I had my home system > calibrated to SMPTE for a while, and it was just anoying. > From dmills_00 at yahoo.co.uk Tue Aug 15 11:51:38 2006 From: dmills_00 at yahoo.co.uk (Dan Mills) Date: Tue Aug 15 11:51:50 2006 Subject: [linux-audio-dev] scaling jackinput to dbSPL In-Reply-To: <200608151728.01940.conrad.berhoerster@gmx.de> Message-ID: <20060815155138.16971.qmail@web27908.mail.ukl.yahoo.com> --- conrad berh?rster wrote: > Whoow , that was fast.... > maybe i was a little bit misunderstandable. > > when i wrote about jack, i meant the jackserver. i > write an app, which has an > microphon input. now i will take this microphon > signal and show it as a gain > meter. this is no magic and everything works. > > if i understand all of you right, the pressure on > the microphon is something > greater 0. and normally it is lower 2, right? > first question: is this the same pressure which is > measured in the literature > in pascal (pa) > if so, its easy to calculate > out_value = > 20.00*(Math.log(in_value/0.00002)/Math.log(10.00)); Its not a case of calibrating the room, its basically a case of needing to know what sample value 20uPa equates to. This is dependent on the microphone, preamp and sound card in use, or for the output case, the soundcard, power amp gain and speaker sensitivity (plus room effects). You need to ensure that 120dbSPL at the transducer does not clip either hhe mic, preamp or soundcard and then find out what sample value this gives with your hardware. Calibrate that point as 120dbSPL, then as long as all your hardware is linear the rest of the thing will just work. Regards, Dan. ___________________________________________________________ The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html From rlrevell at joe-job.com Tue Aug 15 12:01:11 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Tue Aug 15 12:12:45 2006 Subject: [linux-audio-dev] scaling jackinput to dbSPL In-Reply-To: <20060815155138.16971.qmail@web27908.mail.ukl.yahoo.com> References: <20060815155138.16971.qmail@web27908.mail.ukl.yahoo.com> Message-ID: <1155657672.19474.125.camel@mindpipe> On Tue, 2006-08-15 at 16:51 +0100, Dan Mills wrote: > This is dependent on the microphone, preamp and sound > card in use, or for the output case, the soundcard, > power amp gain and speaker sensitivity (plus room > effects). > > You need to ensure that 120dbSPL at the transducer > does not clip either hhe mic, preamp or soundcard and > then find out what sample value this gives with your > hardware. Calibrate that point as 120dbSPL, then as > long as all your hardware is linear the rest of the > thing will just work. FWIW, there is some work going on in ALSA to make the drivers use dB units for the mixer, rather than arbitrary scales. But of course this will only work for devices for which the developers have the full hardware specs. Lee From dominique.michel at citycable.ch Tue Aug 15 12:22:48 2006 From: dominique.michel at citycable.ch (Dominique Michel) Date: Tue Aug 15 12:23:06 2006 Subject: [linux-audio-dev] scaling jackinput to dbSPL In-Reply-To: <1155657672.19474.125.camel@mindpipe> References: <20060815155138.16971.qmail@web27908.mail.ukl.yahoo.com> <1155657672.19474.125.camel@mindpipe> Message-ID: <20060815182248.4909de09@localhost> Le Tue, 15 Aug 2006 12:01:11 -0400, Lee Revell a ?crit : > On Tue, 2006-08-15 at 16:51 +0100, Dan Mills wrote: > > This is dependent on the microphone, preamp and sound > > card in use, or for the output case, the soundcard, > > power amp gain and speaker sensitivity (plus room > > effects). > > > > You need to ensure that 120dbSPL at the transducer > > does not clip either hhe mic, preamp or soundcard and > > then find out what sample value this gives with your > > hardware. Calibrate that point as 120dbSPL, then as > > long as all your hardware is linear the rest of the > > thing will just work. > > FWIW, there is some work going on in ALSA to make the drivers use dB > units for the mixer, rather than arbitrary scales. But of course this > will only work for devices for which the developers have the full > hardware specs. > > Lee > It is a good news. With jack, mixers as jackeq or jackmix are already using db scales. Dominique From patrickkidd.lists at gmail.com Tue Aug 15 13:01:06 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Tue Aug 15 13:01:31 2006 Subject: [linux-audio-dev] Which sequencer framework for a simple MIDI drum looper ? In-Reply-To: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> References: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> Message-ID: <664bf2b80608151001x651b4aefr30ed9aeca1c42c08@mail.gmail.com> I wrote a bunch of control-rate (midi) sequencer code in python that sends messages via OSC to supercollider. I even incorporated it into a QObject so you can just slap it into your PyQt4 UI, as I did mine. PyQt4 is great... check out scosc and scsynth http://www.patrickkidd.com/ lemmie know if you need any help. On 8/15/06, _ langagemachine wrote: > Hello. > > I write hoping that some nice LADs might enlighten me ? > > I've been feeling a recent itch to write a simple step-sequencer, > which outputs MIDI messages to the ALSA seq ; it is intended to drive > a drum machine. My ideal app is provided with a graphical UI which > includes HUGE buttons (to give you an idea, the GUI in FL Studio comes > to mind). > > It may seem silly at this point, but I could not find an existing app > which exactly suits me. > But anyway, I think it will be a piece of fun trying to write > something myself... > > I shamefully admit being no good at C/C++ programming, but I could > write some GUI code in Python/Java, which would communicate with the > sequencer engine, over OSC for example. > > Regarding said sequencing engine, I have found 3 possibilities so far : > > - Chuck > http://chuck.cs.princeton.edu/ > > - Midishare (can be driven in Java, Lisp, ...) *provided that I can > get it to compile on my Gentoo box ... > http://midishare.sourceforge.net/ > > - Milk (Python MIDI engine for ALSA) > http://www.quitte.de/milk.html: > > The former two seem slightly more complete ; in particular, I very > much liked Breakage, which uses Chuck : > http://www.blackholeprojector.com/ > (Actually, this app would have been a very good fit, but it is > Windows/Mac only :-o) > > > I'll finally make my point : which framework would - in your > experience - be the most practical to use ? Or the most interesting to > learn ? > > Many thanks for your attention. > > NB : I am aware that Hydrogen is one fine app ;-), and probably a step > sequencer can be written as a Pd patch in seconds, but that is not > what I am after at the moment ; I insist on the user interacting with > big, Playschool-like BLOCKS :-) > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From dmills_00 at yahoo.co.uk Tue Aug 15 13:03:17 2006 From: dmills_00 at yahoo.co.uk (Dan Mills) Date: Tue Aug 15 13:03:25 2006 Subject: [linux-audio-dev] scaling jackinput to dbSPL In-Reply-To: <20060815182248.4909de09@localhost> Message-ID: <20060815170317.76417.qmail@web27912.mail.ukl.yahoo.com> --- Dominique Michel wrote: > With jack, mixers as jackeq or jackmix are already > using db scales. Yeeees, but they deal with gain which is unitless in the DB system. What is being discussed is how to reference things to external signal levels (measured in volts, SPL or whatever), this requires a mapping from dbFS to the external signal level and that is heavily hardware dependent. Regards, Dan. ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html From dominique.michel at citycable.ch Tue Aug 15 13:37:11 2006 From: dominique.michel at citycable.ch (Dominique Michel) Date: Tue Aug 15 13:37:26 2006 Subject: [linux-audio-dev] scaling jackinput to dbSPL In-Reply-To: <20060815170317.76417.qmail@web27912.mail.ukl.yahoo.com> References: <20060815182248.4909de09@localhost> <20060815170317.76417.qmail@web27912.mail.ukl.yahoo.com> Message-ID: <20060815193711.32000bb3@localhost> Le Tue, 15 Aug 2006 18:03:17 +0100 (BST), Dan Mills a ?crit : > > --- Dominique Michel > wrote: > > > With jack, mixers as jackeq or jackmix are already > > using db scales. > > Yeeees, but they deal with gain which is unitless in > the DB system. > The db system always use a reference and a db of any kind have no unit. dbFS use as reference the maximum possible digital signal and the other term will be too a possible digital signal. dbSPL use as reference a given sound pressure, but the other term will be too a sound pressure, so the result in both cases is unitless. sound_pressure/sound_pressure give the rate between the 2 sound_pressure, and a rate have no unit, and that even after the multiplication by 10 or 20 log base 10. Only the knowledge of the reference give you the knowledge of the unit (as well as the math). The db inside jack are dbFS with a maximum possible signal of 0 db. Now, both jacqeq and jackmix give you a maximum conrol level at +6dB. It mean at +6dB in those EQ is equal to 0dbFS in jack. > What is being discussed is how to reference things to > external signal levels (measured in volts, SPL or > whatever), this requires a mapping from dbFS to the > external signal level and that is heavily hardware > dependent. > > Regards, Dan. I know that. I said in a precedent message at he must measure the sound level in a given point of the local to know the relation between the dbSPL at that point and the dbFS in the box. Best, Dominique From paul at linuxaudiosystems.com Tue Aug 15 14:03:34 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Tue Aug 15 14:04:00 2006 Subject: [linux-audio-dev] scaling jackinput to dbSPL In-Reply-To: <20060815193711.32000bb3@localhost> References: <20060815182248.4909de09@localhost> <20060815170317.76417.qmail@web27912.mail.ukl.yahoo.com> <20060815193711.32000bb3@localhost> Message-ID: <1155665014.9445.22.camel@localhost.localdomain> > The db inside jack are dbFS with a maximum possible signal of 0 db. > Now, both jacqeq and jackmix give you a maximum conrol level at +6dB. > It mean at +6dB in those EQ is equal to 0dbFS in jack. there are no dB units inside of JACK. some JACK applications use dBFS, that much is true. however, it is not true that because the allow a gain level of +6dB (or any value for that matter) that +6dB in that app equals 0dBFS. this is because JACK's floating point sample format allows values above 0dBFS, even though when such a value is passed to DAC, it will be clipped and caused distortion or worse. within JACK, 0dBFS corresponds to a sample value of +/1.0, and will emerge from the other side of your DAC with the maximum voltage level that the DAC can emit. values above 0 dBFS are legal within JACK, but should probably never be routed to a physical output port. --p From dominique.michel at citycable.ch Tue Aug 15 14:43:49 2006 From: dominique.michel at citycable.ch (Dominique Michel) Date: Tue Aug 15 14:43:57 2006 Subject: [linux-audio-dev] scaling jackinput to dbSPL In-Reply-To: <1155665014.9445.22.camel@localhost.localdomain> References: <20060815182248.4909de09@localhost> <20060815170317.76417.qmail@web27912.mail.ukl.yahoo.com> <20060815193711.32000bb3@localhost> <1155665014.9445.22.camel@localhost.localdomain> Message-ID: <20060815204349.2523c3e4@localhost> Le Tue, 15 Aug 2006 14:03:34 -0400, Paul Davis a ?crit : > > The db inside jack are dbFS with a maximum possible signal of 0 db. > > Now, both jacqeq and jackmix give you a maximum conrol level at +6dB. > > It mean at +6dB in those EQ is equal to 0dbFS in jack. > > there are no dB units inside of JACK. some JACK applications use dBFS, > that much is true. however, it is not true that because the allow a gain > level of +6dB (or any value for that matter) that +6dB in that app > equals 0dBFS. this is because JACK's floating point sample format allows > values above 0dBFS, even though when such a value is passed to DAC, it > will be clipped and caused distortion or worse. > > within JACK, 0dBFS corresponds to a sample value of +/1.0, and will > emerge from the other side of your DAC with the maximum voltage level > that the DAC can emit. values above 0 dBFS are legal within JACK, but > should probably never be routed to a physical output port. > > --p > > Thank you for this explanation. Dominique From James at superbug.co.uk Tue Aug 15 19:35:46 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Tue Aug 15 19:37:09 2006 Subject: [linux-audio-dev] scaling jackinput to dbSPL In-Reply-To: <20060815182248.4909de09@localhost> References: <20060815155138.16971.qmail@web27908.mail.ukl.yahoo.com> <1155657672.19474.125.camel@mindpipe> <20060815182248.4909de09@localhost> Message-ID: <44E25A52.9030401@superbug.co.uk> Dominique Michel wrote: > Le Tue, 15 Aug 2006 12:01:11 -0400, > Lee Revell a ?crit : > >> On Tue, 2006-08-15 at 16:51 +0100, Dan Mills wrote: >>> This is dependent on the microphone, preamp and sound >>> card in use, or for the output case, the soundcard, >>> power amp gain and speaker sensitivity (plus room >>> effects). >>> >>> You need to ensure that 120dbSPL at the transducer >>> does not clip either hhe mic, preamp or soundcard and >>> then find out what sample value this gives with your >>> hardware. Calibrate that point as 120dbSPL, then as >>> long as all your hardware is linear the rest of the >>> thing will just work. >> FWIW, there is some work going on in ALSA to make the drivers use dB >> units for the mixer, rather than arbitrary scales. But of course this >> will only work for devices for which the developers have the full >> hardware specs. >> >> Lee >> > It is a good news. > > With jack, mixers as jackeq or jackmix are already using db scales. > > Dominique ALSA is starting to support "dB Gain" indications for mixer controls. It currently supports Creative Audigy cards and USB sound cards. Support for other sound cards will follow in time. So, at least people will know where the 0dB gain point is for the mic and line in. James From langagemachine at gmail.com Wed Aug 16 04:32:25 2006 From: langagemachine at gmail.com (_ langagemachine) Date: Wed Aug 16 04:32:36 2006 Subject: [linux-audio-dev] Which sequencer framework for a simple MIDI drum looper ? In-Reply-To: References: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> Message-ID: <49f299470608160132l2209e747n73a11bf5b2c52b06@mail.gmail.com> Yes, a lot of research has obviously been put into this library ; the fact that it has plenty of language bindings (java, lisp, python) is attractive also. Plus, the JMusic project provides classes for manipulating musical data, and an interface to Midishare... I will make some tries at it on a CCRMA box, I think. Thanks for your feedback :-) On a more general keynote, is it not paradoxical that when a piece of software becomes mature enough, it tends to fade out of the general attention ? 2006/8/15, Jay Vaughan : > I work with MidiShare quite a bit, and I have to say that if you get > it going on your system, it really is one of the nicest, > best-performing MIDI API's around .. of course the fact that it comes > with a Sequencer lib that supports up to 256 tracks is a bonus too .. > ;) > > That said, it may not be quite "ALSA mainstream" enough of an API to > warrant usage, but if you have control over your system and get > MidiShare.o built and in use, you've got a damn fine MIDI API, > oft-overlooked .. > > -- > > ; > > Jay Vaughan > > From langagemachine at gmail.com Wed Aug 16 04:36:35 2006 From: langagemachine at gmail.com (_ langagemachine) Date: Wed Aug 16 04:36:41 2006 Subject: [linux-audio-dev] Which sequencer framework for a simple MIDI drum looper ? In-Reply-To: <664bf2b80608151001x651b4aefr30ed9aeca1c42c08@mail.gmail.com> References: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> <664bf2b80608151001x651b4aefr30ed9aeca1c42c08@mail.gmail.com> Message-ID: <49f299470608160136r5d7a14a8me47f5f5c71931085@mail.gmail.com> Thank you ; I visited your site, and found many things of interest, including the pksampler ;-) Will have a closer look at this, definitely. 2006/8/15, Patrick Stinson : > I wrote a bunch of control-rate (midi) sequencer code in python that > sends messages via OSC to supercollider. I even incorporated it into a > QObject so you can just slap it into your PyQt4 UI, as I did mine. > PyQt4 is great... > > check out scosc and scsynth > > http://www.patrickkidd.com/ > > lemmie know if you need any help. > > On 8/15/06, _ langagemachine wrote: > > Hello. > > > > I write hoping that some nice LADs might enlighten me ? > > > > I've been feeling a recent itch to write a simple step-sequencer, > > which outputs MIDI messages to the ALSA seq ; it is intended to drive > > a drum machine. My ideal app is provided with a graphical UI which > > includes HUGE buttons (to give you an idea, the GUI in FL Studio comes > > to mind). > > > > It may seem silly at this point, but I could not find an existing app > > which exactly suits me. > > But anyway, I think it will be a piece of fun trying to write > > something myself... > > > > I shamefully admit being no good at C/C++ programming, but I could > > write some GUI code in Python/Java, which would communicate with the > > sequencer engine, over OSC for example. > > > > Regarding said sequencing engine, I have found 3 possibilities so far : > > > > - Chuck > > http://chuck.cs.princeton.edu/ > > > > - Midishare (can be driven in Java, Lisp, ...) *provided that I can > > get it to compile on my Gentoo box ... > > http://midishare.sourceforge.net/ > > > > - Milk (Python MIDI engine for ALSA) > > http://www.quitte.de/milk.html: > > > > The former two seem slightly more complete ; in particular, I very > > much liked Breakage, which uses Chuck : > > http://www.blackholeprojector.com/ > > (Actually, this app would have been a very good fit, but it is > > Windows/Mac only :-o) > > > > > > I'll finally make my point : which framework would - in your > > experience - be the most practical to use ? Or the most interesting to > > learn ? > > > > Many thanks for your attention. > > > > NB : I am aware that Hydrogen is one fine app ;-), and probably a step > > sequencer can be written as a Pd patch in seconds, but that is not > > what I am after at the moment ; I insist on the user interacting with > > big, Playschool-like BLOCKS :-) > > > > > -- > Patrick Kidd Stinson > http://www.patrickkidd.com/ > http://pkaudio.sourceforge.net/ > http://pksampler.sourceforge.net/ > From langagemachine at gmail.com Wed Aug 16 04:57:56 2006 From: langagemachine at gmail.com (_ langagemachine) Date: Wed Aug 16 04:58:03 2006 Subject: [linux-audio-dev] Which sequencer framework for a simple MIDI drum looper ? In-Reply-To: <20060815134302.63564.qmail@web33009.mail.mud.yahoo.com> References: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> <20060815134302.63564.qmail@web33009.mail.mud.yahoo.com> Message-ID: <49f299470608160157n7adc92cap22b68e6976a0d8aa@mail.gmail.com> Thanks for suggesting Gneutronica :-) It provides useful answers to some of my needs. If I had to make one main adjustment to my personal preferences, it would be in the way that the pattern is visually rendered : while your way of indicating note velocity (according to its vertical position on a grid) makes it efficient and precise to set, I find it is not easy to visualize the whole rhythm pattern at a glance. Not so easy as colouring the block in a progressive shade of black&white would make it, IMHO. Well, maybe one gets used to it after working on the editor ... I will install Gneutronica and make a more insightful feedback :-) 2006/8/15, Stephen Cameron : > --- _ langagemachine wrote: > > > Hello. > > > > I write hoping that some nice LADs might enlighten me ? > > > > I've been feeling a recent itch to write a simple step-sequencer, > > which outputs MIDI messages to the ALSA seq ; it is intended to drive > > a drum machine. My ideal app is provided with a graphical UI which > > includes HUGE buttons (to give you an idea, the GUI in FL Studio comes > > to mind). > > > > It may seem silly at this point, but I could not find an existing app > > which exactly suits me. > > But anyway, I think it will be a piece of fun trying to write > > something myself... > > > > > You might take a look at gneutronica, the result of me > scratching a similar itch. > > http://gneutronica.sourceforge.net > > It's surely not exactly what you're after, but > if you had in mind C, gnome based UI, alsa sequencer > interface (though, maybe a somewhat naive implementation, > as I was just learning all that stuff as I went) it might > be something worth looking at as an example, and there > might even be some code you could grab from it. It doesn't > talk to JACK... someday I might get around to figurnig out > how to do that, but it's not in there now. > > > I shamefully admit being no good at C/C++ programming, but I could > > write some GUI code in Python/Java, which would communicate with the > > sequencer engine, over OSC for example. > > Oh, well... maybe gneutronica's not what you're looking for then. > > -- steve > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > From david at olofson.net Wed Aug 16 06:30:47 2006 From: david at olofson.net (David Olofson) Date: Wed Aug 16 06:32:22 2006 Subject: [linux-audio-dev] Which sequencer framework for a simple MIDI drum looper ? In-Reply-To: <49f299470608160132l2209e747n73a11bf5b2c52b06@mail.gmail.com> References: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> <49f299470608160132l2209e747n73a11bf5b2c52b06@mail.gmail.com> Message-ID: <200608161230.47351.david@olofson.net> On Wednesday 16 August 2006 10:32, _ langagemachine wrote: [...] > On a more general keynote, is it not paradoxical that when a piece > of software becomes mature enough, it tends to fade out of the > general attention ? Are you sure that's actually what happens, in the general case? A project in development generates a lot of noise for obvious reasons; user questions, bug reports, feature sugestions etc. Potential and actual users are attracted by this noise, maybe hoping for a much better solution than what they've been using before. Lots of attention there, but what is the ratio between interested bystanders and actual users/testers, actually? :-) When a project matures, most of that noise goes away. Stuff works as intended, documentation is in a usable state and potential users can try the software out on their own. Active users focus on the job at hand rather than the tools they're using, and if the tools work as expected, everyone is happy - and quiet. So, even if there is generally less noise around mature projects, the software can still have a large active user base. If there are no problems, users generally won't say much. Also, considering the number of dependencies the average application has these days, only the highest profile libraries, if any, are mentioned for marketing reasons. How many applications have badges and stuff for every single library or technology they depend on? One would think that "integration technologies" should always be advertised all over the place, so you know whether or not the application will work in your setup, but I guess developers in general aren't all that much into marketing... :-) //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 Wed Aug 16 06:45:22 2006 From: jayv at synth.net (Jay Vaughan) Date: Wed Aug 16 06:45:56 2006 Subject: MidiShare (was Re: [linux-audio-dev] Which sequencer framework for a simple MIDI drum looper ?) In-Reply-To: <49f299470608160132l2209e747n73a11bf5b2c52b06@mail.gmail.com> References: <49f299470608150137p7f27ae15s7f43a38b0e028363@mail.gmail.com> <49f299470608160132l2209e747n73a11bf5b2c52b06@mail.gmail.com> Message-ID: At 10:32 +0200 16/8/06, _ langagemachine wrote: >Yes, a lot of research has obviously been put into this library ; the >fact that it has plenty of language bindings (java, lisp, python) is >attractive also. Plus, the JMusic project provides classes for >manipulating musical data, and an interface to Midishare... > MidiShare is quite mature. >I will make some tries at it on a CCRMA box, I think. Thats great - I'd really like to hear how you get along with it .. >On a more general keynote, is it not paradoxical that when a piece of >software becomes mature enough, it tends to fade out of the general >attention ? Sure. The "Not Invented Here" syndrome plays a big part in that, I think .. people don't want to admit that, a lot of times, software doesn't actually need a re-write. ;) That said, I'm almost ready to release MidiShare for the GP2X hand-held gaming console, which will be a very nice platform indeed to hack MIDI applications on .. I'm sure it won't be long until the two platforms make a fair bit of noise. :) -- ; Jay Vaughan From gewang at CS.Princeton.EDU Wed Aug 16 10:41:50 2006 From: gewang at CS.Princeton.EDU (Ge Wang) Date: Wed Aug 16 10:42:10 2006 Subject: [linux-audio-dev] all your face are belong to audicle (source released!) Message-ID: <5381B05D-A1DC-4A08-8D45-F6CA8E4F5BF0@cs.princeton.edu> Hi! The Audicle source code is finally released (GPL). Now audicle can be built to run and crash on Linux systems in addition to Windows and OS X. http://audicle.cs.princeton.edu/ Additionally, there is now formal documentation for the Audicle: http://audicle.cs.princeton.edu/doc/ http://audicle.cs.princeton.edu/doc/faces/ Also, there is now a miniAudicle for linux: http://audicle.cs.princeton.edu/mini/ The command line ChucK and friends (most stable and full-featured option for linux currently): http://chuck.cs.princeton.edu/ http://chuck.cs.princeton.edu/doc/ http://chuck.cs.princeton.edu/community/ Since this is the first source release and effectively the first release for Linux, there is probably plenty of bad voodoo lurking in the build and beyond. Please let us know if you run into anything fishy or outright wrong. Feedback is most appreciated, and feel free to call us idiots. Finally, major thanks to Graham Coleman, Shawn Shaknitz, Scot Gresham- Lancaster, Gary Scavone, and the wonderful people of PLOrk (http:// plork.cs.princeton.edu/people.html). Thanks! Happy ChucKing. Best, audicle team (Perry, Phil, Ananya, Spencer, Scott, Ge, etc...) From smcameron at yahoo.com Wed Aug 16 11:06:54 2006 From: smcameron at yahoo.com (Stephen Cameron) Date: Wed Aug 16 11:07:18 2006 Subject: [linux-audio-dev] Which sequencer framework for a simple MIDI drum looper ? In-Reply-To: <49f299470608160157n7adc92cap22b68e6976a0d8aa@mail.gmail.com> Message-ID: <20060816150654.21498.qmail@web33003.mail.mud.yahoo.com> --- _ langagemachine wrote: > Thanks for suggesting Gneutronica :-) It provides useful answers to > some of my needs. > > If I had to make one main adjustment to my personal preferences, it > would be in the way that the pattern is visually rendered : while your > way of indicating note velocity (according to its vertical position on > a grid) makes it efficient and precise to set, I find it is not easy > to visualize the whole rhythm pattern at a glance. Not so easy as > colouring the block in a progressive shade of black&white would make > it, IMHO. Hm, that's an idea I hadn't thought of. More difficult to program... Also, though it's mostly a step sequencer, if you uncheck the "snap to grid" box, then the timing is freeform, and the gridlines become just visual guides, so there really is no "block" to color, but maybe the background color of each row could be graded along the x-axis according to the velocity of notes in the vicinity... sounds a little processor intensive to accomplish though. Or maybe just pre-generated bitmaps could be pasted, or single pixel high gradient lines duplicated vertically... Exactly how to do that in gnome is not something I know off the top of my head. Well, lately my music programming has been to do with a voice editor for my yamaha motif rack (kind of a pain to program that thing) but even that has been put on the back burner for awhile, so I doubt I'll be tweaking the graphics on gneutronica anytime soon. If you (or anyone) wanted to experiment, the code that draws each row in that grid is in gneutronica.c, in the function called canvas_event(). The for loop towards the bottom is where it draws each note. I'm thinking it wouldn't be too hard to add a section that draws a series of vertical lines of diminishing intensity in say, red, or some other color, beginning at the note's initial X position that fades out as you move to the right, then superimpose my existing note outline in a contrasting color over that. Or whatever else you want to try out. > > Well, maybe one gets used to it after working on the editor ... I will > install Gneutronica and make a more insightful feedback :-) Thanks. It's not anything like a perfect program, so don't get your expectations too high. -- steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From jens.andreasen at chello.se Wed Aug 16 13:03:49 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Wed Aug 16 13:15:01 2006 Subject: [linux-audio-dev] Greenphone Message-ID: <1155747829.22203.15.camel@c80-216-124-251.cm-upc.chello.se> I stumbled on this one today: http://www.linuxdevices.com/news/NS8030785497.html - Trolltech, best known for development tools and Linux application stacks for phones and other mobile devices, will ship an "open" Linux-based phone in September. The "Greenphone" features a user-modifiable Linux OS, and is meant to jumpstart a third-party native application ecosystem for Linux-based mobile phones. [...] So far I've figured out that it's an Xscale of the kind with mmx, which suits my purposes just fine. And that there is a /dev/dsp in there somewhere :-) I have no idea what kind of price point they are considering, but I have notifyed my significant other that this is the *ultimate* christmas present for a u**x geek ... I suppose one will have to "play" it by wawing ones hand in front of the camera? From _ at whats-your.name Wed Aug 16 14:13:01 2006 From: _ at whats-your.name (carmen) Date: Wed Aug 16 14:13:02 2006 Subject: [linux-audio-dev] Greenphone In-Reply-To: <1155747829.22203.15.camel@c80-216-124-251.cm-upc.chello.se> References: <1155747829.22203.15.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <20060816181301.GA14397@replic.net> > > http://www.linuxdevices.com/news/NS8030785497.html > So far I've figured out that it's an Xscale of the kind with mmx, which > suits my purposes just fine. And that there is a /dev/dsp in there > somewhere :-) very cool. although quite a few phones run QT, and there are ongoing efforts to run arbitrary kernels on Motorola's smartphones, i had more or less resigned to just getting something non-linux, since it looked like it was pretty much impossible to even get Mplayer or Ekiga-over-UMTS/WIFI/etc going on them, due to all the lack of source and hw specs.. i assume this Xscale is more or les x86.. definitely be interested int hese if theyre priced reasonably. From david at olofson.net Wed Aug 16 15:04:44 2006 From: david at olofson.net (David Olofson) Date: Wed Aug 16 15:06:18 2006 Subject: [linux-audio-dev] JACK MIDI <-> ALSA Sequencer link? Message-ID: <200608162104.44658.david@olofson.net> Is there such a thing? (Could be implemented as a JACK + ALSA sequencer client, I suppose.) Or is there some other way of wiring JACK MIDI ports to ALSA sequencer ports and/or vice versa? //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 _ at whats-your.name Wed Aug 16 15:10:10 2006 From: _ at whats-your.name (carmen) Date: Wed Aug 16 15:10:12 2006 Subject: [linux-audio-dev] JACK MIDI <-> ALSA Sequencer link? In-Reply-To: <200608162104.44658.david@olofson.net> References: <200608162104.44658.david@olofson.net> Message-ID: <20060816191010.GB14397@replic.net> On Wed Aug 16, 2006 at 09:04:44PM +0200, David Olofson wrote: > > Is there such a thing? (Could be implemented as a JACK + ALSA > sequencer client, I suppose.) a ~ # gre -i jack irclogs/freenode/#lad.log | grep -i midi | gre -i alsa | grep http 17:44 larsl peppo: This is the version I use: http://ll-plugins.sourceforge.net/alsaseq2jackmidi.c 11:52 larsl#lad http://ll-plugins.sf.net/alsaseq2jackmidi.c 20:29 larsl http://ll-plugins.sourceforge.net/alsaseq2jackmidi.c 16:04 c0ff#lad http://www.konstruktiv.org/index.php?page=JackMidi-AlsaSeq 20:39 larsl#lad gordonjcp: You need this: http://www.konstruktiv.org/code/jackmidi_alsaseq-0.2.tar.gz 19:29 larsl#lad edrz: This is probably the most useful one: http://www.konstruktiv.org/index.php?page=JackMidi-AlsaSeq cheers From dsbaikov at gmail.com Wed Aug 16 15:13:33 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Wed Aug 16 15:13:47 2006 Subject: [linux-audio-dev] all your face are belong to audicle (source released!) In-Reply-To: <5381B05D-A1DC-4A08-8D45-F6CA8E4F5BF0@cs.princeton.edu> References: <5381B05D-A1DC-4A08-8D45-F6CA8E4F5BF0@cs.princeton.edu> Message-ID: <70a871c80608161213ib308950u5fb7ec80f6885cdb@mail.gmail.com> Finally, great news! Runs fine, though I haven't done anything with it yet :) To build it I had to comment line 83 in chuck.y: //%expect 35 Regards, Dmitry From david at olofson.net Wed Aug 16 15:16:11 2006 From: david at olofson.net (David Olofson) Date: Wed Aug 16 15:17:46 2006 Subject: [linux-audio-dev] JACK MIDI <-> ALSA Sequencer link? In-Reply-To: <20060816191010.GB14397@replic.net> References: <200608162104.44658.david@olofson.net> <20060816191010.GB14397@replic.net> Message-ID: <200608162116.11671.david@olofson.net> On Wednesday 16 August 2006 21:10, carmen wrote: > On Wed Aug 16, 2006 at 09:04:44PM +0200, David Olofson wrote: > > > > Is there such a thing? (Could be implemented as a JACK + ALSA > > sequencer client, I suppose.) > > a ~ # gre -i jack irclogs/freenode/#lad.log | grep -i midi | gre -i alsa | grep http > 17:44 larsl peppo: This is the version I use: http://ll-plugins.sourceforge.net/alsaseq2jackmidi.c > 11:52 larsl#lad http://ll-plugins.sf.net/alsaseq2jackmidi.c > 20:29 larsl http://ll-plugins.sourceforge.net/alsaseq2jackmidi.c > 16:04 c0ff#lad http://www.konstruktiv.org/index.php?page=JackMidi-AlsaSeq > 20:39 larsl#lad gordonjcp: You need this: http://www.konstruktiv.org/code/jackmidi_alsaseq-0.2.tar.gz > 19:29 larsl#lad edrz: This is probably the most useful one: http://www.konstruktiv.org/index.php?page=JackMidi-AlsaSeq Excellent! Thanks. //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 smcameron at yahoo.com Wed Aug 16 16:08:02 2006 From: smcameron at yahoo.com (Stephen Cameron) Date: Wed Aug 16 16:08:10 2006 Subject: [linux-audio-dev] JACK MIDI <-> ALSA Sequencer link? In-Reply-To: <20060816191010.GB14397@replic.net> Message-ID: <20060816200802.88236.qmail@web33001.mail.mud.yahoo.com> --- carmen <_@whats-your.name> wrote: > On Wed Aug 16, 2006 at 09:04:44PM +0200, David Olofson wrote: > > > > Is there such a thing? (Could be implemented as a JACK + ALSA > > sequencer client, I suppose.) > > a ~ # gre -i jack irclogs/freenode/#lad.log | grep -i midi | gre -i alsa | grep http > 17:44 larsl peppo: This is the version I use: > http://ll-plugins.sourceforge.net/alsaseq2jackmidi.c > 11:52 larsl#lad http://ll-plugins.sf.net/alsaseq2jackmidi.c > 20:29 larsl http://ll-plugins.sourceforge.net/alsaseq2jackmidi.c > 16:04 c0ff#lad http://www.konstruktiv.org/index.php?page=JackMidi-AlsaSeq > 20:39 larsl#lad gordonjcp: You need this: > http://www.konstruktiv.org/code/jackmidi_alsaseq-0.2.tar.gz > 19:29 larsl#lad edrz: This is probably the most useful one: > http://www.konstruktiv.org/index.php?page=JackMidi-AlsaSeq > > cheers > Ooh, thanks. I needed that. -- steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From pcoccoli at gmail.com Wed Aug 16 17:38:51 2006 From: pcoccoli at gmail.com (Paul Coccoli) Date: Wed Aug 16 17:38:59 2006 Subject: [linux-audio-dev] Greenphone In-Reply-To: <20060816181301.GA14397@replic.net> References: <1155747829.22203.15.camel@c80-216-124-251.cm-upc.chello.se> <20060816181301.GA14397@replic.net> Message-ID: <8d27a0610608161438o18c809d0l98ec17e01faeb458@mail.gmail.com> On 8/16/06, carmen <_@whats-your.name> wrote: > i assume this Xscale is more or les x86.. definitely be interested int hese if theyre priced reasonably. > > Nope: ARM. See http://en.wikipedia.org/wiki/Intel_XScale From james at dis-dot-dat.net Wed Aug 16 18:13:22 2006 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Wed Aug 16 18:12:37 2006 Subject: [linux-audio-dev] Greenphone In-Reply-To: <20060816181301.GA14397@replic.net> References: <1155747829.22203.15.camel@c80-216-124-251.cm-upc.chello.se> <20060816181301.GA14397@replic.net> Message-ID: <20060816221322.GO13178@fitz.Belkin> On Wed, 16 Aug, 2006 at 06:13PM +0000, carmen spake thus: > > > > http://www.linuxdevices.com/news/NS8030785497.html > > > So far I've figured out that it's an Xscale of the kind with mmx, which > > suits my purposes just fine. And that there is a /dev/dsp in there > > somewhere :-) > > very cool. although quite a few phones run QT, and there are ongoing efforts to run arbitrary kernels on Motorola's smartphones, i had more or less resigned to just getting something non-linux, since it looked like it was pretty much impossible to even get Mplayer or Ekiga-over-UMTS/WIFI/etc going on them, due to all the lack of source and hw specs.. > > i assume this Xscale is more or les x86.. definitely be interested int hese if theyre priced reasonably. No, xscale is more or less ARM. But intel. > From james at dis-dot-dat.net Wed Aug 16 18:15:37 2006 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Wed Aug 16 18:14:25 2006 Subject: [linux-audio-dev] Greenphone In-Reply-To: <8d27a0610608161438o18c809d0l98ec17e01faeb458@mail.gmail.com> References: <1155747829.22203.15.camel@c80-216-124-251.cm-upc.chello.se> <20060816181301.GA14397@replic.net> <8d27a0610608161438o18c809d0l98ec17e01faeb458@mail.gmail.com> Message-ID: <20060816221537.GP13178@fitz.Belkin> On Wed, 16 Aug, 2006 at 05:38PM -0400, Paul Coccoli spake thus: > On 8/16/06, carmen <_@whats-your.name> wrote: > >i assume this Xscale is more or les x86.. definitely be interested int > >hese if theyre priced reasonably. > > > > > > Nope: ARM. See http://en.wikipedia.org/wiki/Intel_XScale I'm going to have to start reading my e-mail in reverse order when I've been away from it for more than a few hours. This isn't the first time I've duplicated someone's response because I didn't look down far enough. Sorry. James From a_mulyadi at telkom.net Fri Aug 18 12:10:57 2006 From: a_mulyadi at telkom.net (Mulyadi Santosa) Date: Fri Aug 18 12:12:14 2006 Subject: [linux-audio-dev] Linux kernel HZ, audio latency and how to measure? Message-ID: <200608182310.57713.a_mulyadi@telkom.net> Hello everyone.... I am kinda interested to study the effect of changing kernel HZ (internal timer frequency) and the audio processing. Since I am a newbie in Linux Audio, I will be glad to receive any comments, especially the constructive ones. Is there any relationship between kernel HZ and audio timing? I imagine that something like audio recording from a Hi Fi will get a benefit from a finer granularity timer frequency, since it can achieve 1ms (or even smaller) resolution. But, if there is relationship between those two, then how to measure it? Do I need to check every delay function and record the requested delay vs the actual delay? Or is there other method? I already searched the archieve looking for the similar question, but I found none. Thank you in advance your help and attention. regards, Mulyadi From paul at linuxaudiosystems.com Fri Aug 18 12:38:14 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Aug 18 12:46:58 2006 Subject: [linux-audio-dev] Linux kernel HZ, audio latency and how to measure? In-Reply-To: <200608182310.57713.a_mulyadi@telkom.net> References: <200608182310.57713.a_mulyadi@telkom.net> Message-ID: <1155919094.10635.9.camel@localhost.localdomain> On Fri, 2006-08-18 at 23:10 +0700, Mulyadi Santosa wrote: > Is there any relationship between kernel HZ and audio timing? I imagine no. or almost none. recording audio doesn't involve using the system timer at all. the only clock involved is the sample clock that drives the audio interface. having HZ set too high could conceivably make the system more likely to xrun, but this is not likely with a fully RT kernel. From rlrevell at joe-job.com Fri Aug 18 12:54:55 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Aug 18 12:54:19 2006 Subject: [linux-audio-dev] Linux kernel HZ, audio latency and how to measure? In-Reply-To: <1155919094.10635.9.camel@localhost.localdomain> References: <200608182310.57713.a_mulyadi@telkom.net> <1155919094.10635.9.camel@localhost.localdomain> Message-ID: <1155920095.24907.59.camel@mindpipe> On Fri, 2006-08-18 at 12:38 -0400, Paul Davis wrote: > On Fri, 2006-08-18 at 23:10 +0700, Mulyadi Santosa wrote: > > Is there any relationship between kernel HZ and audio timing? I imagine > > no. or almost none. > > recording audio doesn't involve using the system timer at all. the only > clock involved is the sample clock that drives the audio interface. > > having HZ set too high could conceivably make the system more likely to > xrun, but this is not likely with a fully RT kernel. High HZ will improve MIDI timing though. MIDI is more likely to be polled than interrupt driven. Lee From a_mulyadi at telkom.net Fri Aug 18 15:07:47 2006 From: a_mulyadi at telkom.net (Mulyadi Santosa) Date: Fri Aug 18 15:10:53 2006 Subject: [linux-audio-dev] Linux kernel HZ, audio latency and how to measure? In-Reply-To: <1155920095.24907.59.camel@mindpipe> References: <200608182310.57713.a_mulyadi@telkom.net> <1155919094.10635.9.camel@localhost.localdomain> <1155920095.24907.59.camel@mindpipe> Message-ID: <200608190207.47363.a_mulyadi@telkom.net> Hello... > > recording audio doesn't involve using the system timer at all. the > > only clock involved is the sample clock that drives the audio > > interface. I see. I took a wrong conclusion then.... > > having HZ set too high could conceivably make the system more > > likely to xrun, but this is not likely with a fully RT kernel. Ehm, excuse me. "xrun" here refers to a program's name? > High HZ will improve MIDI timing though. MIDI is more likely to be > polled than interrupt driven. polled? Well, interesting. Do you mean MIDI playback? BTW, a friend of mine suggest to take audio synthesizing as the "benchmark" for this HZ experiment. So far, I guess that synthesizing is also timing sensitive application, thus tweaking HZ could make difference. Thoughts? regards, Mulyadi From smcameron at yahoo.com Fri Aug 18 17:07:34 2006 From: smcameron at yahoo.com (Stephen Cameron) Date: Fri Aug 18 17:07:41 2006 Subject: [linux-audio-dev] Linux kernel HZ, audio latency and how to measure? In-Reply-To: <200608190207.47363.a_mulyadi@telkom.net> Message-ID: <20060818210734.29896.qmail@web33011.mail.mud.yahoo.com> --- Mulyadi Santosa wrote: > > High HZ will improve MIDI timing though. MIDI is more likely to be > > polled than interrupt driven. > > polled? Well, interesting. Do you mean MIDI playback? I know at least some MIDI sequencers (eg. the one I have written) rely on simple gettimeofday() and sleep() and usleep() to wake up when it's time (or nearly time) to send MIDI events out to MIDI devices. Mine uses gettimeofday to know what time it is, consults a schedule of events it is supposed to send out, sleeps until just before it needs to do the next item on the schedule, wakes up, then starts polling gettimeofday() for the imminent "go time" to arrive, and repeats for the next item on the schedule, etc. sleep() relies on the internal timer. With whatever the default Hz setting is for 2.6.16 kernels or thereabouts, I seem to remember getting notes out within 200 microseconds of the scheduled time as long as there wasn't lots of contention. I instrumented the code to check (via gettimeofday) if the deadline was missed by some adjustable interval and if it was missed by more than that, print a message. I then adjusted the interval until only a few messages came out during times when lots of notes were coming out at the same time. That turned out to be around 200 microseconds. (Actually the code to print a message is currently turned off, since if it executes, it only makes a bad situation worse.) Actually now that I think about it again, my algorithm, since it wakes up slightly before the "go time" then polls gettimeofday may be mostly immune to HZ changes (kind of why I wrote it that way, because I knew sleep() didn't make guarantees). xruns are, I think, JACK's equivalent of my deadline-missed message. It calls such tardiness an "xrun". JACK is the Jack Audio Connection Kit, an app that is useful for sync'ing and communicating audio data between various audio apps that know how to talk to JACK. -- steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From david at olofson.net Fri Aug 18 17:21:02 2006 From: david at olofson.net (David Olofson) Date: Fri Aug 18 17:22:29 2006 Subject: [linux-audio-dev] Linux kernel HZ, audio latency and how to measure? In-Reply-To: <20060818210734.29896.qmail@web33011.mail.mud.yahoo.com> References: <20060818210734.29896.qmail@web33011.mail.mud.yahoo.com> Message-ID: <200608182321.02408.david@olofson.net> On Friday 18 August 2006 23:07, Stephen Cameron wrote: [...] > xruns are, I think, JACK's equivalent of my deadline-missed > message. It calls such tardiness an "xrun". JACK is the > Jack Audio Connection Kit, an app that is useful for sync'ing > and communicating audio data between various audio apps that > know how to talk to JACK. Actually, I think xrun is just audio hacker shorthand for "overrun or underrun". :-) An overrun is when your application is too late to read imput data before buffers are full and data is lost. An underrun is when your application is too late to write data before the output buffer runs out of data, thus causing a glitch in the output. (Often heard in CD burning discussions, where a buffer underrun will ruin the CD being written, unless the CD writer can pause writing instantly in a controlled fashion.) //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 ivarga at csounds.com Fri Aug 18 17:54:25 2006 From: ivarga at csounds.com (Istvan Varga) Date: Fri Aug 18 17:55:04 2006 Subject: [linux-audio-dev] [ANN] Csound 5.1.00.0 beta1 ("alternative" version) release Message-ID: <200608182354.25332.ivarga@csounds.com> Source and binary packages, and documentation can be downloaded from here: http://sourceforge.net/project/showfiles.php?group_id=167991 Change log and release notes are attached. You can subscribe to the new mailing lists created for this project at these pages: http://lists.sourceforge.net/mailman/listinfo/csound5-devel http://lists.sourceforge.net/mailman/listinfo/csound5-user -------------- next part -------------- Release notes for Csound 5.1.00.0 beta1 ======================================= (Note: the list of changes is against version 5.03.0 beta, as of 2006-06-25; some new features that are in 5.03.0, but not documented, are also listed here. Changes that are known to be missing from 5.03.0 are marked with a '+' instead of a '*'.) Language changes ---------------- + User defined opcodes can now take and return string arguments. These are passed at init time only, and are identified by the 'S' character in input/output type lists. Here is a simple example that reverses a string: opcode ReverseString, S, S S1 xin S2 strsub S1, -1, 0 xout S2 endop + Many opcodes that change their input arguments are handled better by the orchestra parser. For such arguments, constants, reserved symbols (sr, kr, etc.), and expressions are now rejected with a syntax error. Also, when input arguments are really only written, and not read at all, the variables need not be previously defined. Examples of changed opcodes include: fin, fini, fink, splitrig, timedseq, trigseq, denorm, vincr, clear, OSClisten, loop_lt, loop_le, loop_gt, and loop_ge. * Implemented #ifndef and #else preprocessing directives for the orchestra, and also nested #ifdef/#ifndef. New opcodes ----------- * pcount, pindex, moogvcf2 (by John ffitch) * flooper2, syncloop (by Victor Lazzarini) * vadd_i, vmult_i, vpow_i, vexp_i, vaddv_i, vsubv_i, vmultv_i, vdivv_i, vpowv_i, vexpv_i (by Andres Cabrera and Istvan Varga) * sndload, loscilx, midipgm (by Istvan Varga) New command line options ------------------------ * --midi-key=N, --midi-key-cps=N, --midi-key-oct=N, --midi-key-pch=N, --midi-velocity=N, --midi-velocity-amp=N: route MIDI key number and velocity to p-fields (by Michael Gogins) Bug fixes --------- + Files #included from a CSD are now found relative to the directory of the CSD file, if the #include file name does not specify a full path. + Fixed bug in sprintf, sprintfk, printf, and printf_i with string argument. + Fixed problems in vector opcodes with overlapping source and destination vectors. + Minor bug fixes in GEN32, logbasetwo, delay, comb, alpass, randi, partials, convolve, s32b14, randomh, randomi, dconv, vcomb, and a number of other opcodes. + Fixed phase interpolation bug in atsa utility. * Fixed incorrect parsing of .csoundrc with trailing whitespace. * Fixed several bugs in the VST host opcodes. * Fixed overwriting of constants by pconvolve in the case of default partition size. Also, the default partition size is now really the value set for the -b command line option, and not -b * nchnls. * Minor bug fixes in nestedap, prepiano, inh, and ino. Misc. changes ------------- + csound5gui can now open files specified on the command line. This allows for associating CSD files with the GUI frontend on Windows. + Optimizations in atssinnoi (can be almost twice as fast with large ksmps values), and a-rate arithmetic and assignment operations. * Assume 0dbfs as the scale parameter in moogvcf if it is set to zero. * Use double precision internally in some filter opcodes (bqrez, moogvcf, pareq, rezzy, and tbvcf). * --sched command line option no longer checks for being used as the root user. * Added new parameters (source and destination offset) to many of the vector opcodes, and some previously existing i-rate parameters have been changed to k-rate. * Minor optimizations in many opcodes. Internal changes ---------------- + The CSOUND structure was converted to a C++ class named 'Csound'. + Header files csound.h, csoundCore.h, and csdl.h are replaced with csound.hpp and csdl.hpp. Also, several other headers (e.g. cwindow.h) are now integrated into csound.hpp. + Use of setjmp() and longjmp() was replaced with C++ exceptions. + Opcode subroutines no longer return an error code to indicate errors, and throw C++ exceptions instead. Also, there are no separate InitError() and PerfError() methods: Csound::ThrowError() can be used to throw an exception with a message using printf-style formatting, at both init and performance time. + Several improvements to the OENTRY structure: + there are no separate a- and k-rate opcode subroutines (avoids some confusion and possibility for errors) + 'threads' bits no longer need to be set: these were redundant and a source of errors + constructor and destructor routines can be set for opcodes. These are called by Csound::instance(), and when freeing memory used by instrument instances, respectively. + 'not initialised' errors can be generated automatically, by setting a flag in OENTRY + variable number of arguments can be taken and returned using MYFLT** pointers to arrays of output/input arguments, rather than allocating a large (VARGMAX) static amount of space + opcode data structures can have a size of up to 2 GB, as opposed to the previous limit of 64 kB + better support for automatic generation of opcode names from argument types (e.g. 'oscil.akk'): a pattern of 28 bits can be used to generate an opcode name using the type of any of the first 6 output and first 8 input arguments + opcodes that modify their input arguments can indicate such behavior with setting flags in OENTRY; it is also possible to allow for the use of previously not defined variables + it is possible to set a 'user data' pointer when allocating new opcode entries: this pointer will be stored in the OPDS structure on instrument instance allocation, and can be used for any purpose + Removed INOCOUNT, OUTOCOUNT, and several other similar macros. Inline methods of OPDS should be used instead. See also ChangeLog, H/csound.hpp, and Engine/entry1.cpp for more details, and changes not listed here. Known incompatibilities with 5.03.0 ----------------------------------- - The API of Csound 5.xx.x and 5.1.xx.x is not compatible. Emulation of old functions like csoundCreate() etc. is planned in the future. - The following changes (both by John ffitch) were not ported from 5.03.0, because they are incompatible with previous versions 5.00.0 to 5.02.1: - exprand and bexprnd output zero with a negative range parameter, rather than inverting output - vstprogset limits program numbers to the range 1 to 16, replacing all other values with 1 - pv_export and pv_import utilities were implemented independently, and use a different (more detailed, but also larger) file format. - The MFDIR environment variable is not supported - use SSDIR instead. - New flags for vector opcodes were developed independently, so it is not guaranteed that the behavior of 5.1.00.0 beta1 and 5.03.0 is consistent in all cases. One area where differences are likely to be present is the default value assumed for out of range indexes in source tables. Also, the flags for printing warning messages are ignored. - Some changes related to making messages more verbose were not ported; these do not affect orchestra compatibility, though. - Support for static Csound library and Mac platforms was removed. - CsoundVST and Mac frontends were removed. To do ----- - clean up and improve the API: - improve interfaces for loading of plugin libraries - better classes for exception handling - create a namespace for the Csound API (should probably have the same name as the modules for Python etc., for consistency) - move interfaces for shared libraries, thread locks, mutexes, timers, random generators, files, etc. from class Csound to separate, smaller classes - create wrapper templates similar to the one in OpcodeBase.hpp, to improve support for opcodes implemented as C++ classes - more consistent style of interfaces: naming of types, functions, etc., error handling (return values vs. exceptions), use of pointers vs. references, use bool type for boolean arguments, and a number of other minor issues - implement new orchestra (maybe score too ?) parser, either independently from the ffitch version, or porting from there if that is a better option - restore language interfaces, csoundapi~, TclCsound, and Cscore to working status - implement C-style API functions like csoundCreate(), csoundCompile(), etc. - write detailed API documentation -------------- next part -------------- 2006-08-17 Istvan Varga * Csound 5.1.00.0-beta1 release 2006-08-14 Istvan Varga * frontends/fltk_gui/main.cpp: allow for opening files specified on the command line * Engine/rdorch.cpp, H/csound.hpp, Top/csound.cpp, Top/main.cpp: made searching for #include files in directory of main file work with CSD files 2006-08-12 Istvan Varga * Opcodes/OSC.cpp: OSClisten: use new OENTRY flags for input args used as outputs * Opcodes/gab/vectorial.cpp: deal with the case of overlapping vectors * Opcodes/stk/stkOpcodes.cpp: fixed error (calling Instrmnt::noteoff() instead of Instrmnt::noteOff()) exposed by earlier fixes in OpcodeBase.hpp 2006-08-10 Istvan Varga * Opcodes/ugens9.cpp: pconvset: fixed overwriting of constants when the default partition size is used. Also changed the default partition size to the number of sample frames in the output buffer, rather than the number of samples as it was previously. * Opcodes/gab/vectorial.cpp, Opcodes/gab/vectorial.h: Made offset parameters k-rate. Also added optional flags for printing warnings on out of range index values; for now, no messages are actually printed. 2006-08-09 Istvan Varga * OOps/ugens1.cpp: fixed several incorrect uses of Csound::AuxAlloc() * Opcodes/sockrecv.cpp: initialize SOCKRECV structure before creating thread, to avoid race condition * Opcodes/ugmoss.cpp: dconvset(): always clear aux space to zero vcombset(): do not assume sizeof(MYFLT) == sizeof(long) 2006-08-08 Istvan Varga * Opcodes/gab/vectorial.cpp, Opcodes/gab/vectorial.h: New opcodes: vaddv_i, vsubv_i, vmultv_i, vdivv_i, vpowv_i, and vexpv_i. Added offset parameters to many of the vector opcodes. 2006-08-07 Istvan Varga * Engine/entry1.cpp, Engine/linevent.cpp, H/linevent.h, H/schedule.h, OOps/schedule.cpp, Opcodes/fout.cpp: Use new OENTRY flags for variable number of arguments and inputs used as outputs. Also fixed a bug in trigseq. * Opcodes/sndloop.cpp, Opcodes/sndwarp.cpp: fixed more incorrect uses of Csound::AuxAlloc() 2006-08-06 Istvan Varga * Opcodes/pvsbasic.cpp, Opcodes/pvsdemix.cpp: fixed some incorrect uses of Csound::AuxAlloc() * Opcodes/py/pycall-gen.py, Opcodes/py/pycall.auto.cpp: fixed a possible memory leak 2006-08-05 Istvan Varga * OOps/ugens1.cpp (linseg, expseg, etc.), Opcodes/pitch.cpp (mac, maca, transeg), Opcodes/uggab.cpp (sum, product): use new OENTRY flag for variable number of arguments * Opcodes/uggab.cpp: fixed randomh and randomi with a-rate 'cps' parameter 2006-08-04 Istvan Varga * Opcodes/midiops3.cpp: fixed bug in s32b14 opcode use templates instead of macros * Opcodes/minmax.cpp, Opcodes/oscbnk.cpp (denorm): use new OENTRY flag for variable number of arguments 2006-08-03 Istvan Varga * Opcodes/fout.cpp, Opcodes/metro.cpp: use new OENTRY flags to improve parsing of some opcodes that use input arguments as outputs (fin, fini, fink, splitrig, timedseq) 2006-07-31 Istvan Varga * Reorganized header files: csound.h and csoundCore.h are replaced with csound.hpp, and csdl.h is renamed to csdl.hpp. A number of headers that are no longer needed have been removed. 2006-07-30 Istvan Varga * Engine/rdorch.cpp: - changed format of Csound::TEXT::xincod, xoutcod, xincod_str, and xoutcod_str: - for args 1 to 30, bit N-1 is set if arg N is a-rate (xincod) or S-rate (xincod_str) - bit 30 is set if any of the arguments after the first 30 is a-rate (xincod) or S-rate (xincod_str) - bit 31 is set if all the arguments after the first 30 are a-rate (xincod) or S-rate (xincod_str) - bits 8 to 15 of Csound::OENTRY::flags can be set to indicate that some input arguments are actually used for output (bits 8 to 14 for args 1 to 7; if bit 15 is set, all input args after the first 7 are assumed to be outputs). This means that constants and expressions will be rejected by the orchestra parser. Additionally, if bit 3 is set, none of the input arguments that are flagged as being outputs need to be previously defined. * Engine/entry1.cpp: documented changes to OENTRY structure. * Added new command line options: --midi-key=N, --midi-key-cps=N, --midi-key-oct=N, --midi-key-pch=N, --midi-velocity=N, --midi-velocity-amp=N 2006-07-29 Istvan Varga * Changed version to 5.1.00.0 beta, and API version to 10.00. * Added S (string) type to user defined opcodes; string values are copied at i-time only. * Made argument space allocation dynamic in user defined opcodes, xin, xout, and subinstr. Removed .xin64, .xin256, .xout64, and .xout256. 2006-07-26 Istvan Varga * H/csoundCore.h, H/csdl.h, Opcodes/ftest.cpp, Top/csmodule.cpp: Renamed Csound::NGFENS to Csound::NFGENS (was apparently a typing error). * Opcodes/biquad.cpp: Assume 0dbfs as the scale parameter in moogvcf if it is set to zero. Use double precision internally in filter opcodes (bqrez, moogvcf, pareq, rezzy, tbvcf). Fixed some possible out of range indexing in use of a-rate signals. Added moogvcf2 opcode (same as moogvcf, but scale defaults to 0dbfs). * Opcodes/sndloop.cpp, Opcodes/syncgrain.cpp: Added "skip init" parameter to flooper2 and syncloop opcodes. 2006-07-22 Istvan Varga * Converted struct CSOUND to a C++ class. 2006-07-20 Istvan Varga * Opcodes/ugens9.cpp: cvset(): always call Csound::AuxAlloc() * Opcodes/sndloop.cpp: new opcode: flooper2 (by Victor Lazzarini) * Opcodes/syncgrain.cpp: new opcode: syncloop (by Victor Lazzarini) * frontends/tclcsound/commands.cpp: do not add -d flag 2006-07-19 Istvan Varga * Opcodes/partials.cpp: partials_init(): fixed bugs in aux space allocation 2006-07-18 Istvan Varga * frontends/csound/sched.cpp: removed check for root user * OOps/ugens4.cpp: fixed typing error in riset() * OOps/ugens6.cpp: delset(), cmbset(): do not assume sizeof(MYFLT) == sizeof(long) 2006-07-16 Istvan Varga * OOps/aops.cpp: fixed bug in logbasetwo 2006-07-15 Istvan Varga * Added new opcodes: pcount, pindex (written by John ffitch) * Top/one_file.cpp: fixed error on trailing whitespace in .csoundrc 2006-07-10 Istvan Varga * Started to convert the CSOUND structure to a C++ class. * Engine/fgens.cpp: fixed bug in GEN32 2006-07-09 Istvan Varga * util/atsa.cpp: peak_detection(): fixed phase interpolation 2006-07-07 Istvan Varga * Engine/entry1.cpp: corrected opcode data size for inh and ino * Opcodes/bilbar.cpp: play_pp(): use fabs() instead of abs() * Opcodes/biquad.cpp: nestedapset(): do not assume sizeof(MYFLT) == sizeof(long) 2006-07-05 Istvan Varga * Implemented pv_export and pv_import utilities. 2006-06-28 Istvan Varga * bug fixes in VST host opcodes From radarsat1 at gmail.com Fri Aug 18 20:26:09 2006 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Fri Aug 18 20:26:17 2006 Subject: [linux-audio-dev] Linux kernel HZ, audio latency and how to measure? In-Reply-To: <1155919094.10635.9.camel@localhost.localdomain> References: <200608182310.57713.a_mulyadi@telkom.net> <1155919094.10635.9.camel@localhost.localdomain> Message-ID: <9b3e2dc20608181726g39be96b9kf232aeb9ba4cbacc@mail.gmail.com> I've certainly seen setitimer()-driven sleeping get much better response time on a kernel compiled to 1000 Hz (with preemption) over one compiled to 100 Hz (without preemption). >From this, I think it should be possible to say that one could read the audio card with smaller buffers more quickly, reducing latency. But I haven't made tests using audio, specifically, so I won't say more. I suspect the kernel driver and userspace API (ALSA or whatever) might need to be made to take advantage of it, but I know little about ALSA internals. Steve On 8/18/06, Paul Davis wrote: > On Fri, 2006-08-18 at 23:10 +0700, Mulyadi Santosa wrote: > > Is there any relationship between kernel HZ and audio timing? I imagine > > no. or almost none. > > recording audio doesn't involve using the system timer at all. the only > clock involved is the sample clock that drives the audio interface. > > having HZ set too high could conceivably make the system more likely to > xrun, but this is not likely with a fully RT kernel. > > > From rlrevell at joe-job.com Fri Aug 18 20:28:12 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Aug 18 20:28:20 2006 Subject: [linux-audio-dev] Linux kernel HZ, audio latency and how to measure? In-Reply-To: <9b3e2dc20608181726g39be96b9kf232aeb9ba4cbacc@mail.gmail.com> References: <200608182310.57713.a_mulyadi@telkom.net> <1155919094.10635.9.camel@localhost.localdomain> <9b3e2dc20608181726g39be96b9kf232aeb9ba4cbacc@mail.gmail.com> Message-ID: <1155947293.2924.92.camel@mindpipe> On Fri, 2006-08-18 at 20:26 -0400, Stephen Sinclair wrote: > I've certainly seen setitimer()-driven sleeping get much better > response time on a kernel compiled to 1000 Hz (with preemption) over > one compiled to 100 Hz (without preemption). > > >From this, I think it should be possible to say that one could read > the audio card with smaller buffers more quickly, reducing latency. > But I haven't made tests using audio, specifically, so I won't say > more. I suspect the kernel driver and userspace API (ALSA or > whatever) might need to be made to take advantage of it, but I know > little about ALSA internals. > Audio doesn't use setitimer()-driven sleeping. It's interrupt-driven, not timer-driven. Lee > > Steve > > > On 8/18/06, Paul Davis wrote: > > On Fri, 2006-08-18 at 23:10 +0700, Mulyadi Santosa wrote: > > > Is there any relationship between kernel HZ and audio timing? I imagine > > > > no. or almost none. > > > > recording audio doesn't involve using the system timer at all. the only > > clock involved is the sample clock that drives the audio interface. > > > > having HZ set too high could conceivably make the system more likely to > > xrun, but this is not likely with a fully RT kernel. > > > > > > > From radarsat1 at gmail.com Fri Aug 18 20:39:10 2006 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Fri Aug 18 20:39:20 2006 Subject: [linux-audio-dev] Linux kernel HZ, audio latency and how to measure? In-Reply-To: <1155947293.2924.92.camel@mindpipe> References: <200608182310.57713.a_mulyadi@telkom.net> <1155919094.10635.9.camel@localhost.localdomain> <9b3e2dc20608181726g39be96b9kf232aeb9ba4cbacc@mail.gmail.com> <1155947293.2924.92.camel@mindpipe> Message-ID: <9b3e2dc20608181739y19880f85j261f289f249d1858@mail.gmail.com> > Audio doesn't use setitimer()-driven sleeping. It's interrupt-driven, > not timer-driven. Yes, the driver is interrupt driven, but the driver interrupt handler is only responsible for getting the data off the card's FIFO and storing it in memory. (i.e., initialing a DMA transfer.) It doesn't do anything with the audio data itself, except pass it on to user space. Won't HZ make a difference to the user application code which must wake up to do something with this audio data? Hence the need for SCHED_FIFO and the like.. Steve From rlrevell at joe-job.com Fri Aug 18 20:42:40 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Aug 18 20:43:09 2006 Subject: [linux-audio-dev] Linux kernel HZ, audio latency and how to measure? In-Reply-To: <9b3e2dc20608181739y19880f85j261f289f249d1858@mail.gmail.com> References: <200608182310.57713.a_mulyadi@telkom.net> <1155919094.10635.9.camel@localhost.localdomain> <9b3e2dc20608181726g39be96b9kf232aeb9ba4cbacc@mail.gmail.com> <1155947293.2924.92.camel@mindpipe> <9b3e2dc20608181739y19880f85j261f289f249d1858@mail.gmail.com> Message-ID: <1155948160.2924.97.camel@mindpipe> On Fri, 2006-08-18 at 20:39 -0400, Stephen Sinclair wrote: > > Audio doesn't use setitimer()-driven sleeping. It's interrupt-driven, > > not timer-driven. > > Yes, the driver is interrupt driven, but the driver interrupt handler > is only responsible for getting the data off the card's FIFO and > storing it in memory. (i.e., initialing a DMA transfer.) It doesn't > do anything with the audio data itself, except pass it on to user > space. Won't HZ make a difference to the user application code which > must wake up to do something with this audio data? Hence the need for > SCHED_FIFO and the like.. The user application code is woken up by the interrupt from the audio interface, not from a timer firing - in addition to getting data from the card and storing it in memory, the interrupt handler wakes up any processes that are waiting on the audio data. So HZ is irrelevant. SCHED_FIFO is needed because otherwise, if there are multiple runnable processes when the audio interrupt fires, the kernel could decide to run a different process. With SCHED_FIFO it must run the audio process. Lee From radarsat1 at gmail.com Fri Aug 18 20:49:17 2006 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Fri Aug 18 20:49:23 2006 Subject: [linux-audio-dev] Linux kernel HZ, audio latency and how to measure? In-Reply-To: <1155948160.2924.97.camel@mindpipe> References: <200608182310.57713.a_mulyadi@telkom.net> <1155919094.10635.9.camel@localhost.localdomain> <9b3e2dc20608181726g39be96b9kf232aeb9ba4cbacc@mail.gmail.com> <1155947293.2924.92.camel@mindpipe> <9b3e2dc20608181739y19880f85j261f289f249d1858@mail.gmail.com> <1155948160.2924.97.camel@mindpipe> Message-ID: <9b3e2dc20608181749xa2f3db7ua7f40e3b43718f0d@mail.gmail.com> > The user application code is woken up by the interrupt from the audio > interface, not from a timer firing - in addition to getting data from > the card and storing it in memory, the interrupt handler wakes up any > processes that are waiting on the audio data. So HZ is irrelevant. > > SCHED_FIFO is needed because otherwise, if there are multiple runnable > processes when the audio interrupt fires, the kernel could decide to run > a different process. With SCHED_FIFO it must run the audio process. Ah, interesting. Thanks. I feel like I should have known that. I'm going to go read up on audio drivers now.. Steve From a_mulyadi at telkom.net Sat Aug 19 00:31:21 2006 From: a_mulyadi at telkom.net (Mulyadi Santosa) Date: Sat Aug 19 00:44:36 2006 Subject: [linux-audio-dev] Linux kernel HZ, audio latency and how to measure? In-Reply-To: <9b3e2dc20608181749xa2f3db7ua7f40e3b43718f0d@mail.gmail.com> References: <200608182310.57713.a_mulyadi@telkom.net> <1155948160.2924.97.camel@mindpipe> <9b3e2dc20608181749xa2f3db7ua7f40e3b43718f0d@mail.gmail.com> Message-ID: <200608191131.21804.a_mulyadi@telkom.net> Hello... > Ah, interesting. Thanks. > I feel like I should have known that. I'm going to go read up on > audio drivers now.. I also thank everyone who had given their thoughts and opinion. At least you gave me clue on what is really going on in some audio applications. I'll dig more about MIDI and possibly ask something about it in near future. Thanks a lot... NB: Actually, I am going to write an article that analyze the effect of kernel's HZ on real applications. So far, I rely on simulated load such as by using Interbench (written by Con Kolivas), lmbench and so on. Measuring the effect of HZ on real application is a new challenge for me... regards, Mulyadi From a_mulyadi at telkom.net Sat Aug 19 00:31:21 2006 From: a_mulyadi at telkom.net (Mulyadi Santosa) Date: Sat Aug 19 00:45:08 2006 Subject: [linux-audio-dev] Linux kernel HZ, audio latency and how to measure? In-Reply-To: <9b3e2dc20608181749xa2f3db7ua7f40e3b43718f0d@mail.gmail.com> References: <200608182310.57713.a_mulyadi@telkom.net> <1155948160.2924.97.camel@mindpipe> <9b3e2dc20608181749xa2f3db7ua7f40e3b43718f0d@mail.gmail.com> Message-ID: <200608191131.21804.a_mulyadi@telkom.net> Hello... > Ah, interesting. Thanks. > I feel like I should have known that. I'm going to go read up on > audio drivers now.. I also thank everyone who had given their thoughts and opinion. At least you gave me clue on what is really going on in some audio applications. I'll dig more about MIDI and possibly ask something about it in near future. Thanks a lot... NB: Actually, I am going to write an article that analyze the effect of kernel's HZ on real applications. So far, I rely on simulated load such as by using Interbench (written by Con Kolivas), lmbench and so on. Measuring the effect of HZ on real application is a new challenge for me... regards, Mulyadi From smcameron at yahoo.com Sat Aug 19 08:16:07 2006 From: smcameron at yahoo.com (Stephen Cameron) Date: Sat Aug 19 08:16:15 2006 Subject: [linux-audio-dev] Linux kernel HZ, audio latency and how to measure? In-Reply-To: <1155948160.2924.97.camel@mindpipe> Message-ID: <20060819121607.36647.qmail@web33001.mail.mud.yahoo.com> On Fri, 2006-08-18 at 20:39 -0400, Stephen Sinclair wrote: > > Audio doesn't use setitimer()-driven sleeping. It's interrupt-driven, > > not timer-driven. > > Yes, the driver is interrupt driven, but the driver interrupt handler > is only responsible for getting the data off the card's FIFO and > storing it in memory. (i.e., initialing a DMA transfer.) I'm not familiar with audio drivers, but is that strictly correct? I am familiar with storage drivers (e.g. cciss) and there, interrupts happen when DMA transfers complete. At that time, the driver _may_ say, "as long as I'm down here in the driver, let me check if there's more work to do and set up some additional dma transfer(s) before the interrupt handler returns," but it doesn't _have_ to do that, excepting unplugging the stream of requests from the OS in case the board was too busy on last submission and i/o got plugged.) The only data gotten from the board in the interrupt handler is typically a tag (or tags) that tells _which_ of many previously initiated DMA transfers have completed. The tag may or may not be gotten via DMA, often it's a memory mapped register on the board, and it's retrieved via readl(), etc, though if the board is coalescing completions and delivering a pile of tags with one interrupt, _that_ would have been done by a DMA, typically. The primary purpose of the interrupt handler in the storage world is to figure out which previously initiated DMA transfers have completed, and notify the upper levels of the OS code that they have completed, so that layer can, among other things, wake up processes waiting for that i/o... the data isn't copied to userspace by the driver (usually), but by some upper layer of the OS (assuming O_DIRECT isn't used. If it is, the DMA goes right to/from userspace directly.) Probably audio drivers are different in some ways, due to the more sequential nature of typical i/o, and the need for low latency and keeping buffers from getting empty, general differences in how audio data vs. generic block i/o is used, etc? Probably depends on the hardware too. Still, I would expect an interrupt on DMA completions... Just wondering, (and I probably managed to get at least some of the above wrong as well.) -- steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From paul at linuxaudiosystems.com Sat Aug 19 08:26:56 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Sat Aug 19 08:27:15 2006 Subject: [linux-audio-dev] Linux kernel HZ, audio latency and how to measure? In-Reply-To: <20060819121607.36647.qmail@web33001.mail.mud.yahoo.com> References: <20060819121607.36647.qmail@web33001.mail.mud.yahoo.com> Message-ID: <1155990416.10635.30.camel@localhost.localdomain> On Sat, 2006-08-19 at 05:16 -0700, Stephen Cameron wrote: > On Fri, 2006-08-18 at 20:39 -0400, Stephen Sinclair wrote: > > > Audio doesn't use setitimer()-driven sleeping. It's interrupt-driven, > > > not timer-driven. > > > > Yes, the driver is interrupt driven, but the driver interrupt handler > > is only responsible for getting the data off the card's FIFO and > > storing it in memory. (i.e., initialing a DMA transfer.) > > I'm not familiar with audio drivers, but is that strictly correct? well, not precisely, but lee was trying to make a point. > I am familiar with storage drivers (e.g. cciss) and there, interrupts > happen when DMA transfers complete. At that time, the driver _may_ audio h/w interrupts not when a transfer is complete, but when more data is required/available to keep the buffer used by the h/w full/empty (depending on whether we are talking about playback or capture). > say, "as long as I'm down here in the driver, let me check if there's > more work to do and set up some additional dma transfer(s) before the > interrupt handler returns," but it doesn't _have_ to do that, excepting > unplugging the stream of requests from the OS in case the board was too > busy on last submission and i/o got plugged.) well of course, but storage drivers have no real time streaming characteristics, so whether the driver does that or something else is largely irrelevant - there is plenty of *time*. with audio, there are RT deadlines for reading/writing the data. > The only data gotten from the board in the interrupt handler is > typically a tag (or tags) that tells _which_ of many previously > initiated DMA transfers have completed. audio is not so different, except that the RT deadlines mean that the work that must follow an interrupt must follow it before the next interrupt arrives. this means that after the interrupt comes in and a small amount of housekeeping is done by the interrupt handler, the application must be running ASAP. > the OS code that they have completed, so that layer can, among other things, > wake up processes waiting for that i/o... the data isn't copied > to userspace by the driver (usually), but by some upper layer of > the OS (assuming O_DIRECT isn't used. If it is, the DMA goes right > to/from userspace directly.) applications that use JACK or a JACK-like approach mmap the buffer used by the hardware, and therefore data transfer is similarly direct between h/w and userspace. older applications that use read/write models require extra data copying and are generally (not always, but generally) not structured appropriately for low latency. From James at superbug.co.uk Sat Aug 19 17:42:41 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Sat Aug 19 17:42:55 2006 Subject: [linux-audio-dev] Linux kernel HZ, audio latency and how to measure? In-Reply-To: <1155990416.10635.30.camel@localhost.localdomain> References: <20060819121607.36647.qmail@web33001.mail.mud.yahoo.com> <1155990416.10635.30.camel@localhost.localdomain> Message-ID: <44E785D1.6090004@superbug.co.uk> Paul Davis wrote: > On Sat, 2006-08-19 at 05:16 -0700, Stephen Cameron wrote: >> On Fri, 2006-08-18 at 20:39 -0400, Stephen Sinclair wrote: >>>> Audio doesn't use setitimer()-driven sleeping. It's interrupt-driven, >>>> not timer-driven. >>> Yes, the driver is interrupt driven, but the driver interrupt handler >>> is only responsible for getting the data off the card's FIFO and >>> storing it in memory. (i.e., initialing a DMA transfer.) >> I'm not familiar with audio drivers, but is that strictly correct? > > well, not precisely, but lee was trying to make a point. > >> I am familiar with storage drivers (e.g. cciss) and there, interrupts >> happen when DMA transfers complete. At that time, the driver _may_ > > audio h/w interrupts not when a transfer is complete, but when more data > is required/available to keep the buffer used by the h/w full/empty > (depending on whether we are talking about playback or capture). > Paul has it right. I will explain how the audio transfer works on Creative Sound cards, as I know about them, but I assume most sound cards are the same. During setup of the buffer, one configures a number of periods. On Creative cards, one can have anything from 2 to 8 periods per buffer. The sound card hardware has a pointer identifying where the DAC is currently playing samples from. At each period boundary and interrupt is triggered. The stream of DMA transfers is simply started, then keeps running automatically until commanded to stop. Each DMA transfer is 64 bytes, so there are normally multiple DMA transactions between each interrupt. James From fons.adriaensen at skynet.be Wed Aug 23 13:06:55 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Wed Aug 23 13:05:44 2006 Subject: [linux-audio-dev] Kokkini Zita Message-ID: <20060823170655.GB5930@linux-1.site> (Since this was rejected on LAA ('no reason given'), I'll answer the question here.) On Mon, Aug 14, 2006 at 09:20:36PM +0400, Andrew Gaydenko wrote: > What do "Kokini Zita" words mean? I have thought, Fons Adriaensen is the author > of the listed apps :-) It should be "Kokkini" (with 2 k's in the middle) actually. It's indeed Greek and means 'red zita', where zita is the name in modern Greek for the character traditionally known as 'zeta'. So I'll be using a red zeta as a logo. There some word play involved as well. Zita is also a girl's name, and there exists a Flemish comic series in which a character called 'rode Zita' (red Zita) appears. She's the red-haired and voluptuous girlfriend of the hero - a sort of Robin Hood like character whose gang of outcasts is constantly pestering the French soldiers that occupied Flanders 200 years ago. -- FA Lascia la spina, cogli la rosa. From ico.bukvic at gmail.com Wed Aug 23 17:51:54 2006 From: ico.bukvic at gmail.com (Ivica Ico Bukvic) Date: Wed Aug 23 17:52:08 2006 Subject: [linux-audio-dev] Kokkini Zita In-Reply-To: <20060823170655.GB5930@linux-1.site> Message-ID: <001501c6c6fe$59eb1810$5bc752c6@64BitBadass> I just fixed it on the LAO site. Best wishes, Ico > -----Original Message----- > From: linux-audio-dev-bounces@music.columbia.edu [mailto:linux-audio-dev- > bounces@music.columbia.edu] On Behalf Of Fons Adriaensen > Sent: Wednesday, August 23, 2006 1:07 PM > To: Linux Audio Developers > Subject: [linux-audio-dev] Kokkini Zita > > (Since this was rejected on LAA ('no reason given'), I'll answer > the question here.) > > On Mon, Aug 14, 2006 at 09:20:36PM +0400, Andrew Gaydenko wrote: > > > What do "Kokini Zita" words mean? I have thought, Fons Adriaensen is the > author > > of the listed apps :-) > > It should be "Kokkini" (with 2 k's in the middle) actually. > > It's indeed Greek and means 'red zita', where zita is the name in > modern Greek for the character traditionally known as 'zeta'. So > I'll be using a red zeta as a logo. > > There some word play involved as well. Zita is also a girl's name, > and there exists a Flemish comic series in which a character called > 'rode Zita' (red Zita) appears. She's the red-haired and voluptuous > girlfriend of the hero - a sort of Robin Hood like character whose > gang of outcasts is constantly pestering the French soldiers that > occupied Flanders 200 years ago. > > -- > FA > > Lascia la spina, cogli la rosa. From _ at whats-your.name Thu Aug 24 20:30:12 2006 From: _ at whats-your.name (carmen) Date: Thu Aug 24 20:30:20 2006 Subject: [linux-audio-dev] plug:jack device channel-count In-Reply-To: <1156464231.27216.133.camel@mindpipe> References: <44EDA22B.6040202@woh.rr.com> <44EDD463.6090804@prodigy.net.mx> <20060824172618.GD4914@replic.net> <20060825064333.7a0c64f5.mle+la@mega-nerd.com> <20060824213548.GC15900@replic.net> <20060825074449.42b1878c.mle+la@mega-nerd.com> <44EE3E34.2050000@gmail.com> <20060824231312.GE15900@replic.net> <20060824233410.GF15900@replic.net> <1156464231.27216.133.camel@mindpipe> Message-ID: <20060825003012.GI15900@replic.net> > Yes, but what would be even more useful is to report this to the > sweep developers. done. as it turns out, theres a divide-by-zero on alsahandle->num_channels or similar. ive noticed other ALSA apps will also fail with plug:jack (notably Twinkle) with an error very similar (eg, no available channels for opening), while others such as Ekiga or those using GStreamer, have no problems with plug:jack. are these apps working around it by trying to open channels even if the number available is reported to be 0? maybe this is a bug in jack:plug for not making up a number like at least 2, if alsa_pcm devices exist in jack.. From rlrevell at joe-job.com Thu Aug 24 20:38:55 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Aug 24 20:38:48 2006 Subject: [linux-audio-dev] plug:jack device channel-count In-Reply-To: <20060825003012.GI15900@replic.net> References: <44EDA22B.6040202@woh.rr.com> <44EDD463.6090804@prodigy.net.mx> <20060824172618.GD4914@replic.net> <20060825064333.7a0c64f5.mle+la@mega-nerd.com> <20060824213548.GC15900@replic.net> <20060825074449.42b1878c.mle+la@mega-nerd.com> <44EE3E34.2050000@gmail.com> <20060824231312.GE15900@replic.net> <20060824233410.GF15900@replic.net> <1156464231.27216.133.camel@mindpipe> <20060825003012.GI15900@replic.net> Message-ID: <1156466336.27216.139.camel@mindpipe> On Fri, 2006-08-25 at 00:30 +0000, carmen wrote: > > Yes, but what would be even more useful is to report this to the > > sweep developers. > > done. > > as it turns out, theres a divide-by-zero on alsahandle->num_channels > or similar. ive noticed other ALSA apps will also fail with plug:jack > (notably Twinkle) with an error very similar (eg, no available > channels for opening), while others such as Ekiga or those using > GStreamer, have no problems with plug:jack. > > are these apps working around it by trying to open channels even if > the number available is reported to be 0? maybe this is a bug in > jack:plug for not making up a number like at least 2, if alsa_pcm > devices exist in jack.. > I don't know - you failed to mention that you were using plug:jack. Probably no one ever tested this configuration. (I don't think plug:jack is well tested in general. The JACK API is simpler than ALSA so it's easier for apps to just support JACK.) You did mention that in your bug report I hope? Does Sweep really have no JACK support? Lee From mle+la at mega-nerd.com Thu Aug 24 21:35:32 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Thu Aug 24 21:35:42 2006 Subject: [linux-audio-dev] plug:jack device channel-count In-Reply-To: <1156466336.27216.139.camel@mindpipe> References: <44EDA22B.6040202@woh.rr.com> <44EDD463.6090804@prodigy.net.mx> <20060824172618.GD4914@replic.net> <20060825064333.7a0c64f5.mle+la@mega-nerd.com> <20060824213548.GC15900@replic.net> <20060825074449.42b1878c.mle+la@mega-nerd.com> <44EE3E34.2050000@gmail.com> <20060824231312.GE15900@replic.net> <20060824233410.GF15900@replic.net> <1156464231.27216.133.camel@mindpipe> <20060825003012.GI15900@replic.net> <1156466336.27216.139.camel@mindpipe> Message-ID: <20060825113532.48ea4c18.mle+la@mega-nerd.com> Lee Revell wrote: > Does Sweep really have no JACK support? Unfortunately that is correct. Its high on the TODO list but none of the current developers have the time to tackle it. Sweep does have a nice driver output layer but I suspect that its mainly geared towards push outputs like OSS/ALSA etc and as I understand it, JACk uses pull instead of push. Is that correct? Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "C++ is an atrocity, the bletcherous scab of the computing world, responsible for more buffer overflows, more security breaches, more blue screens of death, more mysterious failures than any other computer language in the history of the planet Earth." -- Eric Lee Green From conrad at metadecks.org Thu Aug 24 23:54:58 2006 From: conrad at metadecks.org (Conrad Parker) Date: Thu Aug 24 23:55:12 2006 Subject: [linux-audio-dev] plug:jack device channel-count In-Reply-To: <20060825113532.48ea4c18.mle+la@mega-nerd.com> References: <20060825064333.7a0c64f5.mle+la@mega-nerd.com> <20060824213548.GC15900@replic.net> <20060825074449.42b1878c.mle+la@mega-nerd.com> <44EE3E34.2050000@gmail.com> <20060824231312.GE15900@replic.net> <20060824233410.GF15900@replic.net> <1156464231.27216.133.camel@mindpipe> <20060825003012.GI15900@replic.net> <1156466336.27216.139.camel@mindpipe> <20060825113532.48ea4c18.mle+la@mega-nerd.com> Message-ID: <20060825035458.GL1433@vergenet.net> On Fri, Aug 25, 2006 at 11:35:32AM +1000, Erik de Castro Lopo wrote: > Lee Revell wrote: > > > Does Sweep really have no JACK support? > > Unfortunately that is correct. Its high on the TODO list but > none of the current developers have the time to tackle it. > > Sweep does have a nice driver output layer but I suspect that > its mainly geared towards push outputs like OSS/ALSA etc and > as I understand it, JACk uses pull instead of push. Is that > correct? yeah, that's right :) the "driver" layer will need a bit of rearchitecture, as sweep can handle simultaneous input and multiple outputs (ie. for scrubbing on live input, with both headphone and live outputs). Could be fun :) Conrad. From nettings at folkwang-hochschule.de Fri Aug 25 05:42:42 2006 From: nettings at folkwang-hochschule.de (Joern Nettingsmeier) Date: Fri Aug 25 05:41:37 2006 Subject: [linux-audio-dev] job offer... [Fwd: Algorithm Development Manager (Full-Time)] Message-ID: <44EEC612.5010703@folkwang-hochschule.de> hi guys! i got this job enquiry to my private address, forwarding it here in case anyone's interested. i don't know any details about this, please get back to the original author if you have any questions. regards, j?rn -------- Original Message -------- Subject: Algorithm Development Manager (Full-Time) Date: Fri, 25 Aug 2006 14:04:35 +0200 (CEST) From: Sandy Perlman To: I am a working with a Silicon Valley (Mountain View, CA) company that is looking for an Algorithm Development Manager. This is a fulltime role. I would appreciate any referrals. Our client provides advanced noise suppression solutions for enhanced voice communication to the mobile, VOIP, PC and auto markets. Their proprietary technology, derived from human hearing biology, allows the complete removal of the most difficult and distracting noises from voice, enabling clear communication and greater network efficiency. The Manager of Algorithm Development, reporting to the VP of Engineering, will be responsible for leading and managing all algorithm development functions. Responsibilities include overseeing the creation, development, and design of the algorithms that form the basis for the company's exciting leading-edge products. This manager will actively participate in product definition, manage the team's deliverables effectively and efficiently, and work extensively with the platform and test teams to deliver product to the market. Experience required: Proven track record developing and shipping embedded software or IC products in the areas of Audio Signal Processing, Speech Enhancement, Speech Coding, Noise Reduction, or Acoustic Echo Cancellation, including algorithm development and integration, and software development. At least 2 years of experience managing signal processing or audio product development efforts from concept to production, leading a team of engineering personnel ranging from architect to entry-level engineers. Successful experience recruiting, motivating and retaining high quality engineering personnel Effective interaction with other departmental functions such as test teams marketing etc... Proven ability to effectively communicate with customers, peers and team members. Qualifications: Minimum 5 years audio/signal processing engineering experience. Minimum MS, At least 3 years experience in engineering management. Strong track record in delivering to schedules. Knowledge of patent writing and understanding of IP protection. Experience with customers, vendors, and third party relationships. Excellent communication skills, written and verbal, good presentation skills and meeting facilitation skills. If you know someone that would be a good fit, please forward this email to him or her. If you want to apply, reply to this email with your resume. For more information, send an email to info@ctsearch.com. Sandy Perlman Principal & Senior Recruiter, BSEE 408-723-0560 http://www.ctsearch.com https://www.linkedin.com/in/sandyperlman In business since 1989, CTSearch is an independent high technology search firm that specializes in placing technical professionals into high technology companies. From _ at whats-your.name Fri Aug 25 13:02:41 2006 From: _ at whats-your.name (carmen) Date: Fri Aug 25 13:03:13 2006 Subject: [linux-audio-dev] job offer... [Fwd: Algorithm Development Manager (Full-Time)] In-Reply-To: <44EEC612.5010703@folkwang-hochschule.de> References: <44EEC612.5010703@folkwang-hochschule.de> Message-ID: <20060825170241.GA20153@replic.net> > Our client provides advanced noise suppression solutions for enhanced > voice communication to the mobile, VOIP, PC and auto markets. Their > proprietary technology, derived from human hearing biology, allows the > complete removal of the most difficult and distracting noises from > voice, enabling clear communication and greater network efficiency. it would be cool if companies listed their licenses in job boards, when they don't mention company name. ive found the vast majority of these things involve writing win32 GUIs for niche markets, and generally working on patented closed-source code where the aim is to license to cellphone film/video-equipment manufacturers as a better music/speech codec, and the like. i guess everyone has to pay the rent somehow...but do a indeed/simplyhired search for linux audio, or similar. and check out the names of the top 10 entries....Sony, Avid, Qualcomm. id rather work at starbucks than give them more intellectual property :) From paul at linuxaudiosystems.com Fri Aug 25 13:11:53 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Aug 25 13:12:36 2006 Subject: [linux-audio-dev] job offer... [Fwd: Algorithm Development Manager (Full-Time)] In-Reply-To: <20060825170241.GA20153@replic.net> References: <44EEC612.5010703@folkwang-hochschule.de> <20060825170241.GA20153@replic.net> Message-ID: <1156525913.2174.72.camel@localhost.localdomain> On Fri, 2006-08-25 at 17:02 +0000, carmen wrote: > i guess everyone has to pay the rent somehow...but do a indeed/simplyhired search for linux audio, or similar. and check out the names of the top 10 entries....Sony, Avid, Qualcomm. id rather work at starbucks than give them more intellectual property :) thats pretty much what they did, in addition to sending to linux-audio- announce. i know at least 6 people who got this (and related) emails. From S.W.Harris at ecs.soton.ac.uk Fri Aug 25 13:24:04 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Fri Aug 25 13:24:27 2006 Subject: [linux-audio-dev] job offer... [Fwd: Algorithm Development Manager (Full-Time)] In-Reply-To: <1156525913.2174.72.camel@localhost.localdomain> References: <44EEC612.5010703@folkwang-hochschule.de> <20060825170241.GA20153@replic.net> <1156525913.2174.72.camel@localhost.localdomain> Message-ID: <20060825172404.GF13241@login.ecs.soton.ac.uk> On Fri, Aug 25, 2006 at 01:11:53PM -0400, Paul Davis wrote: > On Fri, 2006-08-25 at 17:02 +0000, carmen wrote: > > i guess everyone has to pay the rent somehow...but do a indeed/simplyhired search for linux audio, or similar. and check out the names of the top 10 entries....Sony, Avid, Qualcomm. id rather work at starbucks than give them more intellectual property :) > > thats pretty much what they did, in addition to sending to linux-audio- > announce. i know at least 6 people who got this (and related) emails. 7. I'm not opposed to companies posting to l-a-a or l-a-d when they have relevent job openings, but this recruitment firm is spamming in my opinion. - Steve From david at olofson.net Fri Aug 25 18:06:16 2006 From: david at olofson.net (David Olofson) Date: Fri Aug 25 18:07:59 2006 Subject: [linux-audio-dev] job offer... [Fwd: Algorithm =?iso-8859-1?q?Development=09Manager?= (Full-Time)] In-Reply-To: <20060825172404.GF13241@login.ecs.soton.ac.uk> References: <44EEC612.5010703@folkwang-hochschule.de> <1156525913.2174.72.camel@localhost.localdomain> <20060825172404.GF13241@login.ecs.soton.ac.uk> Message-ID: <200608260006.16827.david@olofson.net> On Friday 25 August 2006 19:24, Steve Harris wrote: > On Fri, Aug 25, 2006 at 01:11:53PM -0400, Paul Davis wrote: > > On Fri, 2006-08-25 at 17:02 +0000, carmen wrote: > > > i guess everyone has to pay the rent somehow...but do a > > > indeed/simplyhired search for linux audio, or similar. and check > > > out the names of the top 10 entries....Sony, Avid, Qualcomm. id > > > rather work at starbucks than give them more intellectual > > > property :) > > > > thats pretty much what they did, in addition to sending to > > linux-audio-announce. i know at least 6 people who got this (and > > related) emails. > > 7. I'm not opposed to companies posting to l-a-a or l-a-d when they > have relevent job openings, but this recruitment firm is spamming in > my opinion. Got one of those too. For a moment, I was actually wondering whether I should take it seriously, or feel offended because some recruiter that I've never heard of is trying to have me do work for free. What really annoys me about these is that they're usually written to give the impression of a personal message from someone who would know what you're doing and what kind of social network you have. Sometimes you can't really tell without reading the entire mail. "Did I meet this person somewhere...? Is this someone I know from a mailing list or something?" There is quite enough noise as it is without these clever (and way too often, successful) attempts to bypass the spam filters. :-( //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 TimBlechmann at gmx.net Fri Aug 25 18:32:46 2006 From: TimBlechmann at gmx.net (Tim Blechmann) Date: Fri Aug 25 18:30:11 2006 Subject: [linux-audio-dev] job offer... [Fwd: Algorithm Development Manager (Full-Time)] In-Reply-To: <200608260006.16827.david@olofson.net> References: <44EEC612.5010703@folkwang-hochschule.de> <1156525913.2174.72.camel@localhost.localdomain> <20060825172404.GF13241@login.ecs.soton.ac.uk> <200608260006.16827.david@olofson.net> Message-ID: <1156545166.5225.8.camel@localhost> On Sat, 2006-08-26 at 00:06 +0200, David Olofson wrote: > > 7. I'm not opposed to companies posting to l-a-a or l-a-d when they > > have relevent job openings, but this recruitment firm is spamming in > > my opinion. > > Got one of those too. only one? i received 3 mails to 3 different addresses, that i've been using on various mailing lists in the last few years ... makes me wonder, where they harvest the addresses ... cheers ... tim -- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk Every word is like an unnecessary stain on silence and nothingness Samuel Beckett -------------- 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/20060826/ea258436/attachment.bin From patrickkidd.lists at gmail.com Fri Aug 25 18:41:26 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Fri Aug 25 18:41:34 2006 Subject: [linux-audio-dev] job offer... [Fwd: Algorithm Development Manager (Full-Time)] In-Reply-To: <1156545166.5225.8.camel@localhost> References: <44EEC612.5010703@folkwang-hochschule.de> <1156525913.2174.72.camel@localhost.localdomain> <20060825172404.GF13241@login.ecs.soton.ac.uk> <200608260006.16827.david@olofson.net> <1156545166.5225.8.camel@localhost> Message-ID: <664bf2b80608251541y16074b5dv48bab45ea2a763ed@mail.gmail.com> Am I the only one that feels a little wierd about seeing this on the lad list? On 8/25/06, Tim Blechmann wrote: > On Sat, 2006-08-26 at 00:06 +0200, David Olofson wrote: > > > 7. I'm not opposed to companies posting to l-a-a or l-a-d when they > > > have relevent job openings, but this recruitment firm is spamming in > > > my opinion. > > > > Got one of those too. > > only one? i received 3 mails to 3 different addresses, that i've been > using on various mailing lists in the last few years ... > makes me wonder, where they harvest the addresses ... > > cheers ... tim > > -- > tim@klingt.org ICQ: 96771783 > http://www.mokabar.tk > > Every word is like an unnecessary stain on silence and nothingness > Samuel Beckett > > > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From mle+la at mega-nerd.com Fri Aug 25 18:48:29 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Fri Aug 25 18:48:41 2006 Subject: [linux-audio-dev] job offer... [Fwd: Algorithm Development Manager (Full-Time)] In-Reply-To: <1156545166.5225.8.camel@localhost> References: <44EEC612.5010703@folkwang-hochschule.de> <1156525913.2174.72.camel@localhost.localdomain> <20060825172404.GF13241@login.ecs.soton.ac.uk> <200608260006.16827.david@olofson.net> <1156545166.5225.8.camel@localhost> Message-ID: <20060826084829.e4a99783.mle+la@mega-nerd.com> Tim Blechmann wrote: > only one? i received 3 mails to 3 different addresses, Thats how I knew it was spam. Emails to three different addresses. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Religion is a magic device for turning unanswerable questions into unquestionable answers." -Art Gecko, Wombat Discord-1, 128649 From david at olofson.net Fri Aug 25 18:55:08 2006 From: david at olofson.net (David Olofson) Date: Fri Aug 25 18:56:53 2006 Subject: [linux-audio-dev] job offer... [Fwd: Algorithm =?iso-8859-6?q?Development=09Manager?= (Full-Time)] In-Reply-To: <1156545166.5225.8.camel@localhost> References: <44EEC612.5010703@folkwang-hochschule.de> <200608260006.16827.david@olofson.net> <1156545166.5225.8.camel@localhost> Message-ID: <200608260055.08361.david@olofson.net> On Saturday 26 August 2006 00:32, Tim Blechmann wrote: > On Sat, 2006-08-26 at 00:06 +0200, David Olofson wrote: > > > 7. I'm not opposed to companies posting to l-a-a or l-a-d when > > > they have relevent job openings, but this recruitment firm is > > > spamming in my opinion. > > > > Got one of those too. > > only one? I get similar emails once in a while. (And, it does happen that I get similar but authentic ones from people I know too, which makes the "fake" ones even more annoying.) The one I got the other day was a shorter version of the very message quoted in the original post. (Some paragraphs identical, others missing or rephrased.) Smells like a deliberate attempt at bypassing spam filters... //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 fons.adriaensen at skynet.be Fri Aug 25 19:44:33 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Fri Aug 25 19:43:26 2006 Subject: [linux-audio-dev] job offer... [Fwd: Algorithm Development Manager (Full-Time)] In-Reply-To: <200608260006.16827.david@olofson.net> References: <44EEC612.5010703@folkwang-hochschule.de> <1156525913.2174.72.camel@localhost.localdomain> <20060825172404.GF13241@login.ecs.soton.ac.uk> <200608260006.16827.david@olofson.net> Message-ID: <20060825234433.GA5944@linux-1.site> On Sat, Aug 26, 2006 at 12:06:16AM +0200, David Olofson wrote: > What really annoys me about these is that they're usually written to > give the impression of a personal message from someone who would know > what you're doing and what kind of social network you have. Sometimes > you can't really tell without reading the entire mail. "Did I meet > this person somewhere...? Is this someone I know from a mailing list > or something?" Got one too. IMHO this *is* a form of spamming. But at least this one was informative as it rather clearly listed the requirements. Compare that with this gem I received both at home and at work some time ago: > As I have already reviewed your background through our confidential > research process, I think you might be interested in a job opportunity > we are presently working on. One of our major European client is hiring > IT and programming talents for a new development center. > In order for me to go any further with your package to be reviewed by > my client, I must have your completed background to date, including your > latest CV, any creative work and references. -- FA Lascia la spina, cogli la rosa. From shakti at bayarea.net Fri Aug 25 22:05:57 2006 From: shakti at bayarea.net (Tracey Hytry) Date: Fri Aug 25 22:06:06 2006 Subject: [linux-audio-dev] job offer... [Fwd: Algorithm Development Manager (Full-Time)] In-Reply-To: <20060825234433.GA5944@linux-1.site> References: <44EEC612.5010703@folkwang-hochschule.de> <1156525913.2174.72.camel@localhost.localdomain> <20060825172404.GF13241@login.ecs.soton.ac.uk> <200608260006.16827.david@olofson.net> <20060825234433.GA5944@linux-1.site> Message-ID: <20060825190557.bfe56041.shakti@bayarea.net> We live out here in the valley where the headhunters are still trying to recover from the last bust. It's hard when you have the outlook of a car salesperson trying to sell people to companies. First they have to get companies to trust them, and then have to present the most sparkling people to them. And oh, there is the spam advertising of your services! The problem is, most of it's a big charade. The companies overstate what they need, trying to to get some decent talent into what could be a rather mundane job; and the headhunters encourage the would be employees to pad(shine up) their resumes. Sometimes it can be said that these salespeople are a necessary evil, but I see them more like the people that are taking 4 or 5 percent of the sale of a house just because they know who to refer the buyer to to close the deal. Sorry for being a little sarcastic here. Tracey. From loki.davison at gmail.com Sat Aug 26 05:33:46 2006 From: loki.davison at gmail.com (Loki Davison) Date: Sat Aug 26 05:33:55 2006 Subject: [linux-audio-dev] Re: job offer... [Fwd: Algorithm Development Manager (Full-Time)] In-Reply-To: <20060825190557.bfe56041.shakti@bayarea.net> References: <44EEC612.5010703@folkwang-hochschule.de> <1156525913.2174.72.camel@localhost.localdomain> <20060825172404.GF13241@login.ecs.soton.ac.uk> <200608260006.16827.david@olofson.net> <20060825234433.GA5944@linux-1.site> <20060825190557.bfe56041.shakti@bayarea.net> Message-ID: On 8/26/06, Tracey Hytry wrote: > We live out here in the valley where the headhunters are still trying to > recover from the last bust. > > It's hard when you have the outlook of a car salesperson trying to sell > people to companies. First they have to get companies to trust them, and > then have to present the most sparkling people to them. And oh, there is > the spam advertising of your services! > > The problem is, most of it's a big charade. The companies overstate what > they need, trying to to get some decent talent into what could be a rather > mundane job; and the headhunters encourage the would be employees to > pad(shine up) their resumes. > > Sometimes it can be said that these salespeople are a necessary evil, but I > see them more like the people that are taking 4 or 5 percent of the sale of > a house just because they know who to refer the buyer to to close the deal. > Sorry for being a little sarcastic here. > > Tracey. > > As some one who has just finished a 3 month contract and will be looking for work again soon I can say... they are evil.... EVIL! There is so much lies and so little info that it's amazing. I one applied for a "C programming job" which said they were looking for a linux guy from the traditional hacker culture good with gdb/etc, where i did a 2 hour interview where they asked me incredibly basic questions about inheritance and encapsulation and other OO style slop. After these 2 hours the total idiot told me they really didn't have a c job, it was actually a website job involving javascript and interactive web design, but that i seemed perfect for it.... EVIL. ;) Loki From a at gaydenko.com Sun Aug 27 11:17:13 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Sun Aug 27 11:17:59 2006 Subject: [linux-audio-dev] [ANN] QLoud v.0.14 Message-ID: <200608271917.14298@goldspace.net> QLoud is a tool to measure loudspeaker frequency response. Find it here: http://gaydenko.com/qloud/ Changes: - a crash (hitting "Plot" with empty IR list) is fixed, - pickers values are rounded now, - multiple minor fixes and cleanup, - now "Window, msec" is a time from IR peak to cutted reverberations, which is more intuitive, I think (earlier it was equal to applied window width itself). Direct screenshot links: - main window with few SPL plots: http://gaydenko.com/qloud/screenshots/shot01.png - IR-power plot: http://gaydenko.com/qloud/screenshots/shot02.png Andrew From mail at jensgulden.de Tue Aug 29 19:19:33 2006 From: mail at jensgulden.de (Jens Gulden) Date: Tue Aug 29 19:17:14 2006 Subject: [linux-audio-dev] Mailinglist for JJack In-Reply-To: <8764gfm5hd.fsf@esben-stien.name> References: <8764gfm5hd.fsf@esben-stien.name> Message-ID: <44F4CB85.4010708@jensgulden.de> Hello, there now is a mailing list for JJack, the Java bridge API for JACK. This was suggested by Esben Stien. Maybe the list will grow to become a helpful source of information about JJack. You are invited to register at https://lists.berlios.de/mailman/listinfo/jjack-users. Jens From iainduncan at telus.net Wed Aug 30 07:33:44 2006 From: iainduncan at telus.net (Iain Duncan) Date: Wed Aug 30 00:28:39 2006 Subject: [linux-audio-dev] Voice and pitch recog libraries Message-ID: <44F57798.6080301@telus.net> I'm planning on some trying out some voice and pitch recognition stuff for some ear training utilities. Wondering if anyone can tell me which of the many FOSS libraries for both would be best. Cross platform a bonus, but not essential. Thanks Iain From radarsat1 at gmail.com Wed Aug 30 09:53:47 2006 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Wed Aug 30 09:53:56 2006 Subject: [linux-audio-dev] Voice and pitch recog libraries In-Reply-To: <44F57798.6080301@telus.net> References: <44F57798.6080301@telus.net> Message-ID: <9b3e2dc20608300653u6a94708bmdc9dafd860850cd8@mail.gmail.com> Voice and pitch recognition are two very different things! :) Since you mention ear training I assume you really mean pitch recognition... One of the best-known pitch estimators is the "fiddle~" object for Pd! http://pure-data.cvs.sourceforge.net/pure-data/pd/extra/fiddle~/ The nice thing about Pd is that it should be easy to extend it into an "ear training utility" with a few mouse clicks. :) (And it is cross-platform..) Steve On 8/30/06, Iain Duncan wrote: > I'm planning on some trying out some voice and pitch recognition stuff > for some ear training utilities. Wondering if anyone can tell me which > of the many FOSS libraries for both would be best. Cross platform a > bonus, but not essential. > > Thanks > Iain > From iainduncan at telus.net Wed Aug 30 19:56:14 2006 From: iainduncan at telus.net (Iain Duncan) Date: Wed Aug 30 12:51:19 2006 Subject: [linux-audio-dev] Voice and pitch recog libraries In-Reply-To: <9b3e2dc20608300653u6a94708bmdc9dafd860850cd8@mail.gmail.com> References: <44F57798.6080301@telus.net> <9b3e2dc20608300653u6a94708bmdc9dafd860850cd8@mail.gmail.com> Message-ID: <44F6259E.7070103@telus.net> > Voice and pitch recognition are two very different things! :) > Since you mention ear training I assume you really mean pitch > recognition... > One of the best-known pitch estimators is the "fiddle~" object for Pd! > > http://pure-data.cvs.sourceforge.net/pure-data/pd/extra/fiddle~/ > > The nice thing about Pd is that it should be easy to extend it into an > "ear training utility" with a few mouse clicks. :) No, I meant two different questions. I mean to incorporate both, but I will do so in C++ hosting the Csound engine. While I like PD, I would hate to do any lower level programming in it. Iain From paul at linuxaudiosystems.com Wed Aug 30 23:20:31 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Aug 30 23:22:00 2006 Subject: [linux-audio-dev] i'd like my software back (ICube MIDI sensor kit) Message-ID: <1156994431.6480.18.camel@localhost.localdomain> several years ago, i wrote an system to control an ICube MIDI Sensor interface, described here: http://equalarea.com/paul/icube unfortunately, the actual software has gone missing, even google cannot find it. if anyone has a copy of the software, i'd like to get a copy of it. From paul at linuxaudiosystems.com Wed Aug 30 23:23:14 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Aug 30 23:24:39 2006 Subject: [linux-audio-dev] I'd like my brain back (idiot developer) Message-ID: <1156994594.6480.20.camel@localhost.localdomain> Re: ICube software: I found it immediately I did a shell-based search on the webhost where it used to be located. Sorry for the noise. From ico.bukvic at gmail.com Wed Aug 30 23:39:50 2006 From: ico.bukvic at gmail.com (Ivica Ico Bukvic) Date: Wed Aug 30 23:40:00 2006 Subject: [linux-audio-dev] I'd like my brain back (idiot developer) In-Reply-To: <1156994594.6480.20.camel@localhost.localdomain> Message-ID: <000701c6ccaf$1ec778d0$3402a8c0@64BitBadass> Does this mean that we'll get a shiny new revamped version soon ;-)? Best wishes, 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: Wednesday, August 30, 2006 11:23 PM > To: The Linux Audio Developers' Mailing List > Subject: [linux-audio-dev] I'd like my brain back (idiot developer) > > Re: ICube software: I found it immediately I did a shell-based search on > the webhost where it used to be located. Sorry for the noise. > From jens.andreasen at chello.se Thu Aug 31 01:12:39 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Thu Aug 31 01:12:59 2006 Subject: [linux-audio-dev] i'd like my software back (ICube MIDI sensor kit) In-Reply-To: <1156994431.6480.18.camel@localhost.localdomain> References: <1156994431.6480.18.camel@localhost.localdomain> Message-ID: <1157001159.8932.4.camel@c80-216-124-251.cm-upc.chello.se> On Wed, 2006-08-30 at 23:20 -0400, Paul Davis wrote: > unfortunately, the actual software has gone missing, even google cannot > find it. > > if anyone has a copy of the software, i'd like to get a copy of it. > I think it was Linus Torvalds who once said: - Publish your software under GPL, and let others bother about archiving and backups ... -- ( ) c[] From marcell.mars at gmail.com Thu Aug 31 10:26:17 2006 From: marcell.mars at gmail.com (Marcell Mars) Date: Thu Aug 31 10:26:24 2006 Subject: [linux-audio-dev] Re: Which sequencer framework for a simple MIDI drum looper ? Message-ID: <342c3e740608310726i3471861bp7e6232d9184311a4@mail.gmail.com> i really recommend pyseq and midikinesis by peter brinkmann... you can find it here: http://www.math.tu-berlin.de/~brinkman/software/ after playing around in python interactive shell (actually ipython for me) for a bit i got note playing in fluidsynth.. this is how it looked like: 1 : import pyseq 2 : seq = pyseq.MidiTee('miditi') ## after this you can find miditi with aconnect -lo or -li or better qjackctl.. connect it with fluidsynth or some other synth and then: 3 : e=pyseq.snd_seq_event() 4 : e.setNoteOn(0, 60, 127) 5 : seq.callback(e) this was way easier than anything else i ever tried... i dunno if this is the right way to do that but i just feel to say: all kudos to brinkman ;) From capocasa at gmx.net Thu Aug 31 10:31:03 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Thu Aug 31 10:35:55 2006 Subject: [linux-audio-dev] Re: I'd like my brain back (idiot developer) In-Reply-To: <1156994594.6480.20.camel@localhost.localdomain> References: <1156994594.6480.20.camel@localhost.localdomain> Message-ID: You must be the best idiot developer on the planet with the most people who are extremely happy and satisfied thanks to things that you did. Carlo From gene.heskett at verizon.net Thu Aug 31 11:13:52 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Thu Aug 31 11:14:01 2006 Subject: [linux-audio-dev] I'd like my brain back (idiot developer) In-Reply-To: <1156994594.6480.20.camel@localhost.localdomain> References: <1156994594.6480.20.camel@localhost.localdomain> Message-ID: <200608311113.53048.gene.heskett@verizon.net> On Wednesday 30 August 2006 23:23, Paul Davis wrote: >Re: ICube software: I found it immediately I did a shell-based search on >the webhost where it used to be located. Sorry for the noise. Looking at the subject line prompts me to ask if you have it (your brain) backed up on tape somewhere? Most of us have claimed that at one point or another... :-) -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From fons.adriaensen at skynet.be Thu Aug 31 17:35:50 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Thu Aug 31 17:34:46 2006 Subject: [linux-audio-dev] I'd like my brain back (idiot developer) In-Reply-To: <200608311113.53048.gene.heskett@verizon.net> References: <1156994594.6480.20.camel@localhost.localdomain> <200608311113.53048.gene.heskett@verizon.net> Message-ID: <20060831213550.GA5953@linux-1.site> On Thu, Aug 31, 2006 at 11:13:52AM -0400, Gene Heskett wrote: > Looking at the subject line prompts me to ask if you have it (your brain) > backed up on tape somewhere? Most of us have claimed that at one point or > another... To help Paul find back his brain, we should all burn candles, chant "Om", offer oxen to Zeus or . -- FA Lascia la spina, cogli la rosa.