[music-dsp] Matching Pursuit Toolkit (MPTK) 0.7 released
Dear all, Matching Pursuit Toolkit (MPTK) is a fast and efficient library (with Matlab and Python wrappers) for the sparse decomposition of multichannel audio signals. Version 0.7 is now officially released: https://gforge.inria.fr/frs/?group_id=36 Changes in 0.7: * New pyMPTK wrapper, enables direct use of MPTK within Python * Enabled GPD with the Dirac, Constant and Nyquist blocks * Anywave block now working from command-line mpd and mpr * Improved XML parsing of books (note: the API to use for writing new plugins changes as a result of this; and MPTK books are now written with an outer mptkbook tag surrounding book and dict) * Slight Matlab API change: second “dict” arg now needed for reconstruct(book, dict) Best Dan -- Dan Stowell Postdoctoral Research Assistant Centre for Digital Music Queen Mary, University of London Mile End Road, London E1 4NS http://www.elec.qmul.ac.uk/digitalmusic/people/dans.htm http://www.mcld.co.uk/ -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
[music-dsp] [admin] music-dsp FAQ
Hi, Just a reminder that if you are new to the list you should read the music-dsp FAQ. It contains answers to both technical _and_ adminstrative questions that often come up on the list. If your question appears in the FAQ it is safe to assume that it has been discussed on the list many times in the past, and you should probably have a look through the list archives before posting your question to the list. http://music.columbia.edu/cmc/music-dsp/musicdspFAQ.html Also of interest to new and not-so-new list members: The music-dsp list archives http://music.columbia.edu/cmc/music-dsp/musicdsparchives.html The music-dsp source code archive http://www.musicdsp.org music-dsp books and reviews http://music.columbia.edu/cmc/music-dsp/dspbooks.html All this and more at: http://music.columbia.edu/cmc/music-dsp Hasta la pasta, douglas (this is an automated message sent out on the 1st and 15th of each month) -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Functional Programming C code generation
For those interested, a short list of theoretical and general considerations, as of course some of you know I'm hardly fresh to all this, and recognize some of my PhD level considerations from long ago, which were about parallelizing (why does my spell check complain on this word ?! :) ) computer graphics computations, which is more massive mostly, but less timing dependent. Remember in DSP there is the usual suspects concerning sampling theory (Niquist, perfect reconstruction, the mathematical limits on constructing frequency limited time-piece signals, etc), parallels with other disciplines like electronical filters for radio, audio, control loops depend on how well the congruence is between the elca examples and the digital form (very often a problem), and as well: usually practical real workd filters have properties the digital domain doesn't copy well. I mean both the programmers and the actual 9theoretical) problems with the analogy. Doesn't mean anything to you? Fine, but most people will easier associate with the Loudness control onan old Pioneer amp, than most modernist oriented Which brings me to the attempt of generalizing DSP solutions. Some of the better DSP tricks are very non-trivial, and non-intuitive, so merely making all DSP blocks and their most trivial connection possibilities available isn't going to enable the average Joe to make hte perfect HiFi system, or do him (or her) much good. Of course it is great fun to have the blocks available to built a software radio FM-stereo receiver, or a toolboc to turn your potent microcontroller into a internet radio, and be able to mess with the connections and parameters of doing so, and of course it is fun to kludge about in the home studio, like the more intelligent world citizens in principle can since the Moog Modulars. So I'm cool with the idea, but it appears a but tainted, often. A lot of simulations of filter and processing behavior will have intrinsic (hard-theoretically determined) characteristics, which often are un-circumventable (read: each plugin, and in fact most all plugins with certain signature, can be picked out because it has a sound-effect people could probably pick from behind a curtain, evem in non-ideal listening circumstances). Even a variety of given type prpcessing units (like the collection of filters and such in the Ladspa/Jack library) often needs tuning to make them work right to the human ear. The same is true when combining such, so I'd like more comments on that subject. Now about the notion of lambda functions in lieu of DSP: unless I understand it wrong, of course I agree with lisp being a nice tool to compose functions, and that function structure is a good thing (coming from functional integrals in higher mathematics/theoretical physicas/EE, where it is actually essentially interesting but hopelessly too complicated for here), but the notion of lambda alone doesn't cut it. Unless you figure out some way to make the functional parts work together (like I did in my Bwise' tcl/tk program) you'll find out that even the simplest filters and delays have a state, so you'd be reduced to mixers and some simple math functions that really lend themselves to strict functional composition. Compositing state-containing machines (like the well known finite state machines, which apply to various DSP type of processing units) is a well known problem from the history of Unix (read Hoare, Milner for languages and mathematical foundations of communicating systems. So making a working flow graph like my example from this month in Linux with jack-rack blocks and patchage or qjackctl isn't just a matter of compiling the DSP functions, but making (virtual) streams connected in such a way that sample-accurate behavior results at the level of the top-level signal graph. There's lv2 (IIRC) to make such a flow graph (with changeable internal buffer length which in normal cases doesn't influence the output samples at all) ito a compiled form where the sockets between the unix processes and threads are replcaed by explicit assignment code. Of course playing with mathematical definitions in a functional way as well as (interactive) graph-wise programming is something I've worked on ( http://wiki.tcl.tk/22249 as opposed to http://wiki.tcl.tk/37865 ), but that doesn't automatically solve more than being able to define some generator and some other processing-connected blocks, but after that it depends on the tools and their flexibility to know what is easily possible to create. I've worked on symbolic math processing, which of course has the added boon of allowing reordering and transformations which are strictly theoretically well defined as well as strictly neutral transformations , and there are mathematical tools whic can do interesting things with that. The endless maze of reusing DSP blocks with not strictly defined compositing logic, and honestly not even
Re: [music-dsp] Functional Programming C code generation
On 05/15/2013 04:54 AM, Jamie Bullock wrote: On 15 May 2013, at 00:42, Tom Schoutent...@zwizwa.be wrote: Faust is amazing. it can compile to many different end targets and even has it's own IDE in FaustWorks. Also, Albert Graf has embedded it (of sorts) into Pd already (via Pure). very powerful combo. the language itself is a little mathematical, finicky and technically minded though. I really like the idea behind Faust, and I made sure that this idea can be used on top of what I am writing. Faust is already a stateless operator/combinator language, so very close to what I have in mind. That combinator approach used in Faust can work well for high level composition, though after working a lot with such style of languages (though more Forth-like) I no longer think combinators are a good basic substrate for low-level work. They can be very powerful and succinct, but are indeed finicky to work with, and produce hard to read code. Overall I prefer a more direct applicative style ie. named variables for input and possibly output. If you don't like FAUST's functional semantics, there is also Poing Impératif https://github.com/kmatheussen/poing-imperatif Paper: http://users.notam02.no/~kjetism/poingimp_lac2011.pdf Thanks for the link. Seems a lot of interesting things happening in Faust land since I last looked. Maybe to clarify a bit, since I do not want the point to be missed that I like the functional semantics. That part is a really great idea. I'm saying that instead of process1 = +, i prefer process2(a,b) = a + b, meaning explicitly named variables. It's easier to build process1 style notation on top of process2 style, instead of the other way around: it's easier to drop local variables than to re-introduce them. The process1 approach works well and can be very powerful once things are properly abstracted, but when you are working with low-level issues like approximation, interpolation, ... there tend to be more magic parameters involved, which is harder to work with if you have to implicitly keep track of where they are at. Similar to stack juggling in Forth-like languages. However, it seems use of local variables is possible in Faust using the with form so I'm not sure to what extent my process1/2 remark actually matters. It does seem possible to have the best of both worlds in Faust. Is with in Faust a recent addition, or was it there from the start? Tom -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Functional Programming C code generation
On 05/14/2013 11:12 PM, Alan Wolfe wrote: fwiw, i have a DAW I work on, and on my todo list is the ability to export your creations to C++. what DAW is that? One option would do generic C++ so you could drop it into whatever program you wanted (like, an fmod callback, or custom code etc). The other option to be generating code for a VST plugin. Just wanted to mention it because as you probably know... a lot of people have the same good ideas, but fewer people actually bring them to fruition (: yes, it's a lot of work to make everything fit well. code gen is one of those areas where good design pays off. it can get unwieldy very fast. and good design takes time and often many attempts.. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
[music-dsp] Final call: SoundSoftware.ac.uk Prizes for Reproducibility in Audio and Music Research
Dear MUSIC-DSP, please find below the final call for entries for our Reproducible Research Prizes. Deadline is *Sunday, 19 May 2013*. (Apologies for possible cross posting.) Kind regards, Luis Figueira soundsoftware.ac.uk *** Call for entries: SoundSoftware.ac.uk Prizes for Reproducibility in Audio and Music Research *** To promote the development and release of sustainable and reusable software associated with published research, the SoundSoftware project will be awarding a number of “Reproducible Research Prizes”. If you have published your software or datasets as part of your audio or music research output, so that other UK researchers can reproduce your results, you could win a prize! ** Categories ** 1) Journal paper: New submission 2) Conference paper: New submission 3) Journal paper: Already published 4) Conference paper: Already published ** Prizes ** Prizes awarded vary and will depend on the type of work and affiliation of entrants, but will consist of one of the following: * Article Processing Charge (APC) to make your paper open access; * Travel bursary of up to £1000 towards the cost of presenting the work at a relevant conference or workshop; * For non-UK researchers, travel bursary to visit a UK institution; * Alternatives of comparable value as appropriate. In addition, entrants may be invited to present their work at a SoundSoftware workshop. ** Deadlines ** Next deadline will be the 19 May 2013 ** Homepage ** For updated news and more detailed information, please visit: http://soundsoftware.ac.uk/rr-prize For further advice or assistance with preparing your entries, contact the SoundSoftware project at i...@soundsoftware.ac.uk -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
[music-dsp] Listening test: Perceptual Similarity of Residual from Sinusoidal Analysis (5 min)
Dear list, We are looking for participants to take a short (~5 minutes) listening test online to evaluate the perceptual similarity between the residual from sinusoidal analysis of musical instrument sounds and their modeled counterpart. Here's the link http://gillesdegottex.eu/index.php?n=Main.Test2013simil. Thank you for your time and interest, Marcelo Caetano -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
