Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7513 discussions

Re: [linux-audio-dev] Re: Software controller for homemade edrums

by Ben Loftis

> Message: 10 > Date: Wed, 08 Jun 2005 15:57:23 +0200 > From: Olivier Guilyardi <ml(a)xung.org> > Subject: Re: [linux-audio-dev] Re: Software controller for homemade > edrums > To: "The Linux Audio Developers' Mailing List" > <linux-audio-dev(a)music.columbia.edu> > Message-ID: <42A6F943.4080606(a)xung.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Florian, > > Florian Schmidt wrote: > >For quick tests without libDSP you can tweak the jack_convolve Makefile > >a little: > > > >uncomment the > > > >#COMPILE_FLAGS += -DC_CMUL > > > >line and remove "-ldsp" from the LINK_FLAGS line. This will use an > >unoptimized C complex multiplication implementation. jack_convolve will > >use around 10-20% more cpu than with the libDSP implementation. > > > > > > It did compile. I also needed to remove the #include <dsp/dspop.h> in > convolve.c > > Okay, so I now have an idea of what convolution is. Your little piece of > software is very nice, very easy to understand. I used three samples : a > bassdrum, a snare drum, and a short guitar chord. I plugged the output > of one of my pads into jack_convolve's input and its output into the > alsa_pcm playback. > > Both the bassdrum and the chord sounded quite nice. But the snare drum > sounded like very far away. I guess this comes from the silence at the > end of this sample. > > What exactly happens with these "response files" ? Should I use very > simple samples, like a sine wave with no silence ? Shouldn't convolving > be coupled with trigerring ? I mean : hitting the pad would start the > sample playback, and the convolving engine would use both this sample > playback and the pad signal to produce its output. In this case, > jack_convolve would then need one output and two inputs : > - one for the pad signal, > - and one for the "response signal", that is : the sample playback that > started right when the pad got hit > > Is this possible, or do I misunderstand convolution here ? Olivier, I think the next step is to run jack_convolve, and connect the soundcard input directly into jack_convolve's input using qjackctl. then connect the output of jack_convovle to the soundcard's outputs. (jack_convolve may already do this for you, I can't check just this moment) Now when you hit a pad, it should be "convolved" with the response signal giving you something different than the simple "click" of the input signal. I'm very interested to see how this works out (I suggested this path to Olivier, I hope it's not totally worthless :) ). It could be a way to build a cheap, responsive electronic drum kit that preserves the nuances of the input signal. I wonder if this is how the Korg Wavedrum worked? -Ben

20 years, 3 months

Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many

by eviltwin69＠cableone.net

On Wed, 08 Jun 2005 09:50 , Simon Jenkins <sjenkins(a)blueyonder.co.uk> sent: >On Tue, 2005-06-07 at 19:34 -0500, Jan Depner wrote: >> On Tue, 2005-06-07 at 19:20, Dave Robillard wrote: >> > "Premature optimization is the root of all evil". Using C arrays and >> > strings for no reason when a much more robust higher level type would >> > suffice is /just as stupid/ as always using slow high-level operations >> > in time critical code. >> > >> > It's like arguing about, say, assembly vs. perl. Anyone who says one >> > side is (always) "better" is automatically wrong. :) >> > >> True. I usually try to use the right tool for the job. >> Unfortunately, with the data I work with, the right tool is almost >> always the fastest tool. >> >You must be working with relatively large amounts of relatively simple >data then. > I'm working with multibeam sonar, airborne topographic and hydrographic LIDAR, and airborne hyperspectral imagery data. >Suppose I sum a vector of 5 million integers and it takes 6 seconds. And >assume - (generously![1]) - that I switch to using an array and now it >only takes 1 second. Hmmm... a 6 * speedup! So I look to see where else >my code could benefit from this super performance boost. > >Aha! Here's a vector of 5,000 oscillator structures, and it takes 5 >seconds to initialise them all. Switch to using an array and... erm... >now it only takes 4.995 seconds to initialise them all. > >I'm sure my users will notice and appreciate the 5ms saving, but I >suspect I could have served them better by looking at where my code was >actually spending most of its time before trying to "optimise" it. > As far as data volumes go, for your 5 million integers, you're off by about 5 orders of magnitude ;-) So, now that 5ms just became 500 seconds. Yes, my users do notice and appreciate that time savings ;-) Jan >Cheers > >Simon > >[1] It really was a generous assumption: I've assumed that arrays are >

20 years, 3 months

[linux-audio-dev] Re: Software controller for homemade edrums

by Juhana Sadeharju

>From: Olivier Guilyardi <ml(a)xung.org> > >Well, that's an idea, but you'll be playing alone then. That was the idea because the drum objects are tuned for the detector software, not for the song. Sure real drums are tuned and could be detected by these methods, possibly using the suggested two mics. By the way: As recently as two weeks ago, for learning purposes, I picked up drumming mp3s of John Bonham (Led Zeppelin) at http://www.drummerworld.com/Sound/johnbohnhammobylive.mp3 http://www.drummerworld.com/Sound/johnbonhamdrumsalone.mp3 http://www.drummerworld.com/Sound/JohnBonhamMoby.mp3 http://www.drummerworld.com/Sound/JohnBonham_When.mp3 http://www.drummerworld.com/Sound/johnbonhamRockAndRoll.mp3 http://www.drummerworld.com/Sound/johnbonhamfool.mp3 Two first files could work as an excellent example resource. I planned manually to mark the duples (time, name of the drum). I even downloaded plenty of photos of John Bonham so that I know how he arranged the drum set in the stereo field -- at http://www.led-zeppelin.org/multimedia/photoarchive.html Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software

20 years, 3 months

[linux-audio-dev] DMRN Summer Conference 2005

by Matthew Davies

Apologies for cross-postings. Dear Digital Music Research Network, [Please forward to relevant researchers in your group] Following a number of requests, the deadline for abstract submission to the DMRN Summer Conference has been extended to Monday 13 June 2005 Submissions (abstracts) should be emailed to dmrn05submissions(a)elec.gla.ac.uk This conference will be an excellent opportunity, particularly for young researchers, to present their work in a friendly environment and interact with others in the field. A specific aim of the conference is to promote collaboration between those in computational music analysis and musicians. A concert will be held during the conference to allow those working directly in the music side to present their work. Attendance for young researchers is free and UK based students may apply for travel and accommodation directly through DMRN (so there is no excuse for not going!). See below for the call for papers. Further information can be found at http://www-sigproc.eng.cam.ac.uk/~mps37/DMRNSummerConference05/ Best wishes, Mark Plumbley --- Dr Mark D Plumbley Centre for Digital Music Department of Electronic Engineering Queen Mary University of London Mile End Road, London E1 4NS, UK Tel: +44 (0)20 7882 7518 Fax: +44 (0)20 7882 7997 Email: mark.plumbley(a)elec.qmul.ac.uk **************************************************************** CALL FOR PAPERS DMRN SUMMER CONFERENCE 2005 23 - 25 JULY 2005 Glasgow, Scotland http://www-sigproc.eng.cam.ac.uk/~mps37/DMRNSummerConference05/ **************************************************************** *** EXTENDED SUBMISSION DEADLINE: 13 June 2005 *** The Digital Music Research Network invites the submission of papers for the DMRN Summer Conference 2005. Submissions will initially take the form of an extended abstract of between 500-750 words giving an overview of the intended content. In addition to this, primary authors are asked to indicate their status as one of the following: * Young researcher (year of PhD study) * Research assistant (year PhD obtained) * Academic * Other (please specify) Although paper acceptance will depend on relevance to the conference and academic merit, preference will be given to those submissions where the primary author is a young researcher. Authors will be invited to present their work either by oral presentation (20 minutes) or as a poster. This allocation will be decided by the conference committee, however authors may specify a preference when submitting their abstract. The DMRN Summer Conference 2005 solicits contributions from the following topics: * Digital music content generation * Sound synthesis, virtual instruments * Audio analysis: machine recognition of music * Signal processing tools for music analysis * Music data structures and representations * Music notation, musicology * Psychoacoustics, perception, cognition of music and audio * Human computer interfacing for music and audio * Non-western musicology, analysis and performance Abstracts should be emailed to dmrn05submissions(a)elec.gla.ac.uk no later than Monday 13th June 2005. Authors will receive email confirmation of whether their proposal has been successful by Monday 20th June 2005. Authors will then be asked to submit a camera ready version of their paper (in pdf format) by Friday 15th July 2005. Latex and word templates are available at http://www-sigproc.eng.cam.ac.uk/~mps37/DMRNSummerConference05/CallForPa pers/ Final pdf submissions should not exceed 4 pages. DEADLINES 13th June 2005: Deadline for submissions of paper abstracts 20th June 2005: Notification of acceptance of papers 15th July 2005: Deadline for submission of camera ready pdf versions of full papers Further information can be found at http://www-sigproc.eng.cam.ac.uk/~mps37/DMRNSummerConference05/ ********************************************************************

20 years, 3 months

[linux-audio-dev] Re: Software controller for homemade edrums

by Lachlan Davison

> Assembling piezo microphones, cardboard, foam, wood and a cymbal stand, > I have just made my first DIY electronic pads. Actually it's electronic > percussions, because I will play these mostly with hands. > > I've found a few sites about DIY "edrums" (1), as well as some detailed > documentation about how to build a trigger-to-midi hardware controller > (2). But since I started this little project, I've been thinking about > plugging the piezo mikes directly into my soundcard inputs. My first > tests are very good : the signal is clean, and indicates faithfully how > hard the pads get hit. Hi, There will be a lot of developments in smack in the coming months on modeling hand drums and i think you might get some good results with your triggers and smack. You can also try pluggin the audio out of your triggers and the excitation signal for the physical modeling drums in smack. This would allow you to get a level of control that is very difficult with midi/osc in that it directly uses the attack/release/velocity etc of your triggers in the sound. Give me a yell if you want a hand with using them like that, as i'd love the testing. Loki

20 years, 3 months

Fw: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many

by Simon Jenkins

>As far as data volumes go, for your 5 million integers, you're off by about 5 >orders of magnitude ;-) So, now that 5ms just became 500 seconds. Yes, my > users do notice and appreciate that time savings ;-) > >Jan Sooo..... if you stored this stuff on punched paper tape it would be long enough to stretch something like 10 times around the planet - unless those were binary orders of magnitude, in which case it would be a mere 1600 km long :). Heh, I *said* you must be working with relatively large amounts of relatively simple data, but I had no idea. (Don't tell me its relatively complex data... if it is then a 500 second saving would become insignificant next to the hours, days, weeks or whatever that your code would be spending "inside" the data rather than "in-between" it). Cheers Simon

20 years, 3 months

Re: [linux-audio-dev] photo needed

by Paul

Hi. I made many photos of the building, including some nice panoramas. The pics are at resolution 1024x768 or 1600x1200 and if you want, I can stitch some panoramas. Paul >Greetings: > I've prepared a brief report on LAC 2005 for the Linux >Journal, it's >ready for submission but I need an outside photo of ZKM >+ the Kubus. Did >anyone take a nice shot of the buildings that they'd like >to see in LJ ? >If so, let me know asap. A TIFF is preferred, but >high-resolution JPG >will probably do. TIA! Best, dp __________________________________ Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.html

20 years, 3 months

[linux-audio-dev] some new soundfiles on-line

by Dave Phillips

Greetings: I recently submitted another article for my monthly column at Linux Journal on-line, it should show up within the next few days. I wanted to let LA* folks know that I've placed the article's two short example files here: http://linux-sound.org/lj-seq24-examples.html They aren't finished pieces, nor were they meant to be (though I'm liking them enough to maybe work on them some more). I made them as examples of what can be done with seq24 and a batch of Linux softsynths (and one VST plugin). I had an enormous amount of fun doing these pieces, and I want to extend great thanks to Rob Buse for seq24 and Nick Dowell for amSynth. The state of things in our little world is getting to the point where it gets harder to write about the stuff because I'd really just rather be making music with it. Vast thanks to all Linux audio developers for making dreams come true. You guys rock, every one of you. Now if I can just get seq24 working with JACK... ;) Best regards, Dave Phillips

20 years, 3 months

[linux-audio-dev] LAC2005 pictures by me ;)

by Paul

Hi. When I was at LAC2005 I made a lot of pictures. I sorted the pictures that are interesing for the people who participated LAC2005, I corrected them (rotate, etc.) and I uploaded them at: http://zynaddsubfx.sourceforge.net/doc/PicturesPaulNascaLAC2005.zip The pictures are in a single zip archive (55MB) and there are 215 pictures;-) MD5SUM(PicturesPaulNascaLAC2005.zip)=8c6877789e5c303d979d0dd85f73dc79 SHA1SUM(PicturesPaulNascaLAC2005.zip)=b4f18efd4eb51dee711e6b7d1c1fb183048a2479 Please note that this link is NOT permanent and very likely the pictures will be available at linuxdj.com. Hope you'll like it. Paul Nasca, the author of ZynAddSubFX. __________________________________ Discover Yahoo! Get on-the-go sports scores, stock quotes, news and more. Check it out! http://discover.yahoo.com/mobile.html

20 years, 3 months

[linux-audio-dev] Re: [linux-audio-user] disaster day #1

by Jonathan Woithe

vanDongen/Gilcher wrote: > If there are little brown spots on the top of some condensers on the mobo, > then they are fried and you have to get a new one.(unless you fancy soldering > multi-layer boards) Apperently some factories saved a few tenths of pennies > by using substandard parts. Steve Harris wrote: > ... but If the motherboard is oldish (couple of years or so) then its > worth eyeballing the motherboard for bulging capacitors, I lost my studio > PC to this and we lost a load at work. > > The tops should be slightly concave and clean, if theres any sign of brown > gunge (technical term) or bulging then the motherboard is a gonner. > > There was a bad batch of capacitors for a while from a major manufacturer, > but I suspect all the bad boards have blown allready by now. There was a bad batch of capacitors doing the rounds a few years back. I've seen a large number of MSI K7T Turbo boards die this way as well as two HP boards from the same era - around the time of the Athlon-900. It wouldn't surprise me if Dave's mainboard is suffering from these bad capacitors since the symptoms are very close to those I've seen in the 20 or so failures I've witnessed: the machine gets less and less stable until finally either it doesn't boot (mostly) or the offending capacitor(s) explode (as has happened twice in my experience). I've been told from a reputable source that it wasn't actually the mobo factories which did the dirty as such. An electrolyte formula was apparently stolen from a factory, copied at another and then stolen *again* and passed to a third. It was the resulting capacitors from the third factory which, falsely branded as a reputable brand, found their way into all these mainboards which have been dying over the past 3 or so years. I started seeing mainboards failing in machines which run 24/7 about 3 years ago. Since then, mainboards with intermittant use have been showing up with the same fault. The last one I saw suffering this problem surfaced only a few months ago, so there are still some out there. From my observations it appears related to power-on hours which, given the failure mode of the capacitors, isn't all that surprising. Of course this is all cold comfort for those unfortunate enough to be stuck with a faulty board. Regards jonathan

20 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev