If you are going to work with audio data in a program then getting this data in and out of your program is one of the key problems, largely due to the proliferation of formats and sub formats available. libsndfile is a very useful library that simplifies these problems considerably and is used by virtually every application that needs to read or write audio data (except of course those that deal with encumbered formats.)
Being able to use the simple power of libsndfile in a Perl program makes working with audio data much simpler and lets you get on with actually doing the things you want to do rather than spending your time re-inventing various rather complicated wheels.
If you need to read or write audio data in your program you probably should be using this module.
When I'm not earning a living doing programming I like to make and record music and computers have played quite a large part in this for a while, being able to stand in for quite a large amount of the bulky and expensive equipment that might have been used before. LADSPA (Linux Audio Developer's Simple Plugin API) is a key platform in the increasingly usability of free and open source audio applications, allowing the creation of modular software synthesizers ( such as Alsa Modular Synthesizer) and flexible application of effects to audio tracks in digital audio workstation software (such as Ardour).
This great set of modules brings the power and flexibility of the LADSPA architecture to my favourite programming language, making it easy to create and manipulate sounds in Perl programs, building on the many excellent and interesting plugins available. Previously Perl had largely been limited to sequencing or generating notes for other software to generate the sounds, but now it can all be done in Perl (albeit with plugins written in C).
You can find a link to a piece generated with the help of this module which I presented at LPW 2007 on my use.perl journal.
We'll leave aside the fact that no-one will ever be able to install this via the CPAN installer and that the module is completely pointless as I'm sure others will mention. I'll also skip over the stupidity of creating a module with a lower case name in in the top-level namespace as this has been mentioned in relation to this author's other recent modules. BUT WHAT ON EARTH IS THE AUTHOR OF THIS THING THINKING OF CREATING A MODULE WITH THE SAME NAME AS THE LANGUAGE ITSELF? I truly despair - if there was an argument for moderating CPAN then this is pretty close to one. Please remove this from CPAN immediately.
Forget your application frameworks, forget your database interfaces, forget your XML, your webservices, your annoying but necessary authentication or session management, your CGI. This is the module du jour. Software is on the whole sickeningly boring, rooted as it is in the two dimensions of the screen: now you can have your programs interact in three or four dimensions *and* enhance your delusions of world domination at the same time. Amaze your friends! Declare war on your family or co-workers! Have fun!
Actually, it's worse than just gilding as someone else just pointed out as the upper and lower methods explicitly only work on the ASCII alphabetic characters and do not respect locale settings as the builtins do.
To be honest I just can't see the point of this, dealing with files is not that difficult that five minutes with the perlopentut manpage couldn't sort any of the things that this module does. There are also no meaningful tests and the documentation is laid out appallingly.
I'm afraid I don't understand the purpose of this module, it doesn't do SOAP at all but wraps LWP to send something with a content-type of "text/xml" using a POST request. It doesn't even appear to provide a facility to send a SOAPAction header which is a requirement for the majority of mainstream SOAP toolkits. Additionally there are no useful tests of the modules functionality.
I love this module more out of nostalgia more than any practical use I might have for it. Informix Perform was quite a powerful tool for the time it came out originally and the abilty to reuse the simple forms in 4GL programs made rapid prototyping easy. This module does just what I expect and I don't really think you can ask any more of it.
Any one who knows me will know that I have for a long time been a skeptic when it comes to object relational frameworks, this could be because I am getting old and can't deal with all this newfangledness or it could be because it never really sat well with the way my brain sees software, but whatever. I first saw Michael Schwern talk about Class::DBI in 2000 and was impressed with the coolness of the idea, but have assiduously avoided using it in my own programs ever since. I've seen it get installed as a dependency of something else I wanted to install but never once typed 'use Class::DBI' in a text editor.
So recently I was half way through writing a set of data classes for a medium sized web application and was beginning to lose the will to live, everything worked fine but I was getting really bored of preparing and executing the necessary SQL statements and using the data to variously populate the classes, hand defining the relationships and then passing the data to Template as required. I'd already demonstrated the first cut to the person who had commmisioned the application and I just needed to wrap up some more details and add a little more functionality to the frontend. It felt like a chore - this isn't my day job you understand, now if only something could take all the hassle and ugly DBI code away and just make this stuff work as nicely as the hand crafted classes... I was being lured into the Object-Relational crack-den.
But I'm still going to have to create a bunch of classes by hand, even if I do use Class::DBI and I am going to have to replicate all those foreign key definitions I had carefully put into the database in a whole bunch of 'has_a' and 'has_many' calls. Surely there must be something that could do all this for me, write out the code based on the database schema or something. Oh there was something better.
I'd seen Class:DBI::Loader referred to before but was never particularly interested in examing it closer, but now it fit my requirement perfectly: it examines my database and dynamically creates the data classes and the relations between them; I don't have any annoying module files to deploy and when I change the structure of the database the data classes, being dynamically created, reflect the changes without any effor on my part. A couple of little test programs to verify that it did actually work with the structure of my database and to familiarise myself with the way things worked and then I set about redoing the whole application to use this new (to me) wonder. A little jigging around in the templates to deal with the new accessors, a couple of changes of case from the names of my original classes and some aesthetic changes of column names in the database from FooKey to Foo and it was all done in an hour or so and I had excised some 700 lines of code in the process.
I would thoroughly recommend this module (and by extension Class::DBI itself) to anyone. There are mutterings in various quarters about these modules but these seem to be about things unrelated to the actual functionality or if they aren't they are mostly so vague as to be best to ignore.
I just don't understand what spreading the plethora of comment and opinion about this matter into CPAN is going to achieve. This appears to be a cheap shot and the comments in the README simply reflect what has already been said in a mutltitude of blogs and use.perl journals.
The module is not packaged properly, it lacks a Makefile.PL and/or a Build.pl, there are no tests and the documentation is lacking. It should not be introduced into the top level namespace and offers little that a good HOWTO for the existing Date or Time modules would do.
This doesn't appear to do anything that the latest version of Module::Pluggable can't do and lacks tests. It would probably have been better to have provided a patch to Module::Pluggable to offer an alternate interface.
It is noted that the author doesn't do himself any favours by unethically rating his own module.
I still stand by my view that this would be best provided as a set of patches to Module::Pluggable.