Sometimes, foundations and other organizing groups are almost invisible to the people that they serve. That can be a good thing in some ways, because it means that most of what the group does is running so smoothly that nobody notices the well-oiled machine humming away in the background. But there are downsides too, as people may not be aware of all of the opportunities for funding and other assistance that the organization can provide. Python Software Foundation (PSF) director Brian Curtin gave a talk at PyCon 2013 to try to ensure that the gathered "Pythonistas" at the conference were up to speed on the PSF.
Curtin started out by noting the visibility problem for the PSF. Most people know that it exists and perhaps a little bit about what it does. But there are things that PSF does that are not well known, so people are unaware of ways the PSF could help their projects. There are also activities that other groups are doing that could help the PSF. Basically, there is a bit of a disconnect between the PSF and others in the Python community. His talk was meant to bridge that gap.
The PSF is a 501(c)(3) US non-profit organization, which means that it is tax-exempt and that donations to it are tax deductible (in the US). It is made up of both individual members and sponsor members, which are organizations that make an annual donation to the PSF.
The PSF Mission Statement makes it clear that the organization is "for everybody", Curtin said. It is meant to support core developers, people writing Python code, people using Python programs, the people at PyCon, and so on. It is "big P Python", not just "/usr/bin/python on your latest MacBook", he said.
Part of PSF's mission is to promote the language, and events like PyCon are one way to do that. There were also a variety of tutorials surrounding PyCon that promoted the language to children and to programmers who use other languages. Protecting the language is another piece of the mission. That includes protecting the Python trademark, for example, as it recently did in a European dispute. It also involves maintaining the PSF license for Python. The final piece of the mission is to "advance" Python. That effort is partially to fund Python development, but there is more to it than just core development. It is meant to push the Python community forward through funding a variety of activities.
The 200+ individual members of the PSF were nominated by existing members based on their efforts to "promote, protect, and advance Python". Beyond just core developers, the list includes community and conference organizers, developers of Python web frameworks, evangelists, and so on. It is people who are "trying to make the Python world better".
There are also roughly 30 sponsor members, who are companies or organizations that like and use Python. Those members donate annually because they believe in the mission of the PSF. They see a great benefit from being able to freely download and use Python throughout their organization. In return, the PSF tries to keep the Python world running smoothly so that those organizations can continue to be successful.
There are several PSF committees—made up of both members and others from the community—that are charged with handling a specific piece of the PSF's mission. For example, the Sprints committee is responsible for helping fund development sprints. Originally, sprint funding was focused on CPython (the C language Python core), but that has changed. Now, anyone who is "making Python better through code" is eligible for funding. The committee has funded PyPy and Django sprints as well as efforts to create new web sites for user groups.
Typically, the money is used to buy food or rent meeting space, but other things are possible too. The Cape Town users group was one of the first to use PSF sprint funding. It used the funding to make socks and coffee mugs with the Python logo for sprint participants who went on to do lot of work to make matplotlib and Genshi work on Python 3.
There is an Outreach and Education committee which does much what its name would imply: funding educational and community building efforts. The Trademark committee looks after the Python trademark. It was instrumental in resolving the recent European dispute, but more generally works to ensure that user groups and others are following the trademark policy. There is also an Infrastructure committee that handles the web servers for python.org, the Python wiki, the Mercurial repository, and so on. The PSF has recently added two part-time system administrators to help keep the infrastructure running well.
The PSF also grants money for specific projects. For example, Kivy, NLTK, and Pillow were recently granted funding to complete specific features or releases. In the past, the PSF funded Brett Cannon to create a Python developer's guide to help get new contributors up to speed.
Conference grants are another big part of what the PSF spends its money on. In 2012, it granted $33,000 to 18 conferences in 15 countries. It wants to help other conferences "all over the world" grow to be more like PyCon. The smaller conferences have trouble attracting sponsors sometimes (unlike PyCon, which had multiple chock-full sponsor pages), so the PSF helps out. Curtin said that the PSF plans to double its contributions to each of the conferences for 2013.
The Sprints and Outreach committees both have their own budgets, so they can make funding decisions without needing to go to the board of directors for money. Sprints has a $5000 annual budget, and will reimburse expenses up to $300 for approved sprints. It "works well and people like it", he said, and the committee would like to see it grow. He gave a long list of sprints that had been funded all over the world. There have been a lot of repeat groups applying for funding, which is good, but the committee would like to see new groups representing new geographical areas apply. The Outreach committee has funded a wide variety of workshops and other activities including PyStar Philly, PDX Python, PyCamp Argentina, and more.
The PSF also gives out awards to give back to contributors, so that they know their work is appreciated. There are two community service awards given each quarter, which include either a $500 check or free PyCon registration plus up to $500 travel reimbursement. The Frank Willison memorial award is given yearly at OSCON to an outstanding Python contributor, and is awarded by O'Reilly Media based on a recommendation from the PSF. In 2012, the $5000 distinguished service award was added to recognize "sustained and exemplary contributions" to Python. The inaugural award was made posthumously to matplotlib creator John Hunter.
The PSF is always looking for more ways to advance "big P" Python. It is currently "kicking around" some ideas on how to serve local Python communities better, perhaps by way of regional representatives to the PSF. That would help ensure that word about what assistance the PSF can provide gets out to all of the local groups that could take advantage.
In order to have money to give away, the PSF has to raise money. PyCon is the biggest fundraiser for the organization, but the sponsor members also help replenish the funds as well. There is a (non-voting) associate member class for those who donate to the PSF. Curtin would like to see that program built up and to make it more attractive for people to contribute that way with T-shirts or other incentives. He ended his talk with a pair of questions: Can the PSF help you? Can you help the PSF? He encouraged anyone with ideas in either direction to contact the PSF.
If PyCon is the major fundraiser for the PSF, it seems likely to have a long and prosperous future ahead of it. This was my first visit to PyCon (with luck, not my last) and it is an impressive conference. Lots of excellent technical talks, with an engaged and excited community in evidence. Getting 2500 enthusiasts together in one place for a few days will do that.
One fear when attending a conference with an "expo hall" is that it will have gone down the path of LinuxWorld (or the RSA Conference and other large "industry" conferences), where much of the content is targeted at executives and other non-technical folks. Those kinds of conferences have their place, I suppose, but they don't offer much in the way of intellectual stimulation. PyCon was certainly not that kind of conference, though it had a large contingent of company and organization booths. While I didn't spend much time on the expo floor, it was always crowded with attendees.
While PyCon 2013 will be known to some because of an unfortunate incident that occurred, that incident does not typify the conference at all. In fact, it is clear that PyCon (and the PSF) have made great strides in trying to even out the gender imbalance typically seen at free software conferences. Of the 116 talks in six tracks, 22 were given by women. That ratio is roughly the same as that of the conference as a whole, which was 20% women. Progress has certainly been made; one can only hope more will be.
There were lots of talks that I sat in on but wasn't able to write up and even more that I wasn't able to sit in on at all. There is a whole lot going on in the Python world and that is clearly reflected in the conference lineup. For anyone with an interest in the language, PyCon 2014 (in Montréal, Canada) should get strong consideration.
Just when it seems like the Internet is done fighting about video codecs, another salvo is fired. Google recently announced an agreement with the codec patent holders at the MPEG Licensing Authority (MPEG LA) that allowed Google and all other third parties to use Google's VP8 codec without fear of MPEG LA's patent infringement claims. The agreement was a major win for VP8, and soon afterward momentum picked up to push for VP8's adoption in a variety of web standards. But shortly after the announcement, Nokia jumped into the fray, asserting that it had numerous patents on which VP8 infringed, and that it would not license them. There is no telling where the Nokia incident will head, but on the heels of its victory in the MPEG LA fight, Google may be unlikely to back down.
As a refresher, MPEG LA is a consortium that sells licensing agreements for various multimedia codecs; member companies contribute their relevant patents to a "pool," then MPEG LA sells one-stop-indemnification against patent infringement lawsuits based on those contributions. Despite its confusingly-similar name, MPEG LA is not affiliated with the Motion Picture Experts Group (MPEG), which is a joint ISO/IEC working group that produces media compression specifications.
In recent years, MPEG LA's highest-profile cash cow has been the H.264 video codec. In 2009, H.264 proponents successfully lobbied to keep the open-source Theora video codec from being named as a "mandatory to implement" (MTI) part of the HTML5 standard. Arguably in response to the threat posed by Theora, MPEG LA agreed to make H.264 decoders royalty-free for video that is delivered over the Internet for free to end users. That meant that non-subscription services like YouTube can deliver H.264-encoded content to users without the users needing to shell out any cash, but it still left plenty of opportunities for royalty-collection by MPEG LA, including for-pay video services, physical media like Blu-Ray discs, and video encoders.
Theora was derived from a codec called VP3, which was developed by codec shop On2 Technologies and was released as open source in 2002. VP3's code was donated to the Xiph.org Foundation along with a royalty-free patent grant. In 2009, Theora was quite a bit older than H.264, but its real selling point was its royalty-free nature. Still, H.264 proponents included MPEG LA members who both profit from H.264 licensing and make web browsers (such as Microsoft and Apple), and they claimed that Theora was both technically inferior to H.264 and infringed on MPEG LA patents, too.
The HTML5 video codec argument ended in a stalemate with neither codec becoming enshrined in the specification, but Google changed the tenor of the entire debate in February 2010, when it purchased On2 for US $124 million. On2 had released several codecs since VP3/Theora, including one called VP7 that it claimed was superior to H.264. In May 2010, Google released the next generation codec VP8 under a BSD-style license, along with an irrevocable royalty-free patent grant to all of the company's VP8 patents, under the banner of the WebM media format (which uses VP8 for video and Vorbis for audio).
But the VP8 patent grant did not deter MPEG LA; immediately after Google's announcement, the group said that it was looking into forming a patent pool around VP8. In February 2012, it asked for contributions to a VP8 patent pool, and in May announced that 12 companies had responded.
Despite MPEG LA's triumphant announcement, it never actually unveiled a public VP8 patent pool (if that is what one does with a pool). Nor did it initiate any patent infringement litigation against Google or anyone else. Prior to March 2013, the only major news events around VP8 or H.264 was Mozilla's controversial decision to enable H.264 decoding on certain platforms by passing decoding duties down to hardware decoders. At the time, Mozilla's justification was that its efforts were better spent ensuring that royalty-free codecs would be adopted in newer standards like WebRTC. Indeed, WebRTC arrived in February 2013, with VP8-based interoperability implemented by Mozilla and Google.
Thus, it came as a bit of a surprise on March 7 when Google announced that it had reached an agreement with MPEG LA about VP8. The full terms were not made public, but the announcement said that Google had been granted licenses to the MPEG LA patents that "may be" essential to VP8, and that MPEG LA would discontinue its VP8 patent pool.
The terseness of the announcement led to considerable speculation online; some even assumed that Google had paid a licensing fee to MPEG LA for some or all of the infringing patents. But the language of the announcement is weighted entirely in Google's favor:
Specifically, the grant covers all of VP8's predecessors, covers its next iteration (which is already under development), applies to any implementation of VP8 (whether derived from Google's or not), and leaves Google free to sublicense the patents to third parties at will. Xiph.org's Christopher Montgomery summed up the agreement as "Google won. Full stop." After the announcement, Google's Serge Lachapelle elaborated on the agreement in an email to the W3C's rtcweb mailing list, saying that Google "intends to license the techniques under terms that are in line with the W3C’s definition of a Royalty Free License" in the coming weeks, and adding that the agreement with MPEG LA "is not an acknowledgment that the licensed techniques read on VP8."
Since patent licensing is MPEG LA's sole reason to be, it is indeed difficult to hypothesize a set of secret conditions that would amount to the agreement being a favorable outcome for its side. A lot of technology companies end their patent disputes with a "cross-licensing" agreement, which amounts to a pact to not sue each other over the patents, but allows both companies to continue to wield them against others. Google certainly has a patent portfolio; a Google–MPEG LA agreement of this form would be plausible, but there is no mention of cross-licensing. If it was part of the deal, it is strange that MPEG LA would not mention it, considering that its business hinges on such licensing deals. Similarly, it is unknown if a cash payment by Google was involved; if so, such a cash payment would have to be sizable indeed for MPEG LA to potentially undermine its own future business interests by walking away from the fight with nothing to show for it publicly.
Another possible scenario is that the primary reason for the agreement was that Google privately demonstrated something even more harmful to MPEG LA, such as invalidating some key MPEG LA patents, or disclosing patents of its own that pose a serious threat to one of MPEG LA's key properties. Cash might or might not have greased the wheels of deal-making. Alas, it is doubtful that we will ever know for sure so long as corporate lawyers roam the earth.
Many in the web standards bodies, meanwhile, were so relieved to hear of the deal that they quickly rallied to promote VP8 and WebM. Lachapelle proposed that VP8 be adopted as WebRTC's MTI codec. Codec expert Rob Glidden reported that Google had also submitted VP8 for consideration in MPEG's still-under-development Internet Video Coding (IVC) standard. Steve Faulkner even proposed reopening the issue of including an MTI video codec in HTML5.
VP8's rosy future hit an abrupt obstacle a few days later, however. As Pamela Jones at Groklaw reported, a Nokia representative interrupted a Google talk about VP8 at a recent IETF meeting to announce that Nokia owned a number of patents upon which VP8 was infringing, and that it would not license them. Nokia put its claim on file with the IETF, listing 64 patents in various jurisdictions (many of which are simply jurisdictional duplicates of the same invention claims) plus 22 pending patent applications. A few news sites noted that MPEG LA's tally of prospective VP8 patent-poolers was 12, and that only 11 companies were mentioned in the Google–MPEG LA agreement; perhaps, then, Nokia was the holdout.
Whether or not it was the missing party is tangential; the real questions are whether the claimed patent infringements are legitimate, and what Google will do about them. Jones broke down the list of patents and removed the duplicates, then called for a search to turn up prior art. That is certainly one approach that might yield results. Another would be for Google to perform a thorough investigation and decide that some or all of the patents do not apply; as Thom Holwerda at OSnews observed, that is the approach Xiph.org took when a similar patent infringement charge was raised over the Opus audio codec—which was subsequently cleared by the legal review team and approved as WebRTC's MTI audio codec.
The odds are that Google's legal department has already conducted a pretty detailed examination of VP8, of course. So it is hard to say what the next move will be. WebM project manager John Luther pointed out that there was never any lawsuit nor finding of infringement in the MPEG LA case. He called it a distraction, and said that the project unfortunately had to keep quiet while the talks were in progress. So we may not hear much more from Google on the subject of Nokia's claims until Nokia files a lawsuit or another surprise announcement reveals how it all turns out.
For the time being, arguably the most puzzling aspect of this latest development is the fact that Nokia is wading into the argument in the first place. There is plenty of speculation as to why—every theory from puppetry on behalf of Nokia's business partner (and H.264 proponent) Microsoft to a gamble that Google will pay the financially-troubled Finnish phone maker to make the problem go away.
Of course, Google already knows if Nokia was the mysterious twelfth member of the defunct MPEG LA patent pool, and, if it was, then Google has known about its patents for quite some time. But either way, nothing stops any other company from springing a similar attack on VP8 or any other codec. In the battle to make VP8 an MTI standard in any web specification, the parties that benefit from license sales of rival codecs have no incentive to cooperate. That goes for H.264 as well as for the next generation, and it is not merely a hypothetical problem. Apple's Maciej Stachowiak has already voiced his objection to making VP8 an MTI standard in HTML5. The agreement between MPEG LA and Google has smoothed over the issue of VP8's patent status, but it cannot perfectly resolve it, simply because nothing can.Louigi's notes and commentary before taking the plunge.
Developer Jeff Hubbard wants to provide a solution to this problem with his PyDAW project, a singular environment for the Linux-based musician working in contemporary electronic music. PyDAW supports audio/MIDI sequencing in a well-designed GUI that includes a piano-roll interface for MIDI event entry, an audio sample editor, and a set of graphical editing tools for designing control curves for various integrated sound parameters. An audio mixer, a suite of instruments, and a set of signal processors round out PyDAW to make it a self-contained system for producing electronic music with Linux.
PyDAW has been designed to appeal to users who want to avoid the difficulties presented by excessive modularity. No external plugin architecture is supported, and the author has indicated that its JACK deployment may be discontinued in favor of direct communication with ALSA. While these decisions may seem heretical to other Linux audio developers and users, they proceed from PyDAW's basic design philosophy, i.e. to provide a complete system for immediate and uncomplicated use by musicians working in a specific genre.
PyDAW requires modern hardware, and its performance reflects the host machine's capabilities. A sufficiently powerful laptop is usable, but the author prefers a desktop system equipped with an audio interface designed for high-quality sound. A dual-core 64-bit CPU with 4G memory is a base system for adequate performance, a quad-core system with 8G memory is recommended. An eight-core or better system with 16G memory would be optimal for fully exploiting PyDAW's capabilities.
You can download PyDAW in pre-built versions for Ubuntu and other deb-based systems, as a source tarball for a local build, and in an ISO image for a bootable DVD or USB stick. The bootable images include a plain-vanilla Ubuntu 12.04 for AMD64 systems, PyDAW's target Linux distribution.
A Git repository is also available for anyone with an interest in the project's most recent development. Building PyDAW is uncomplicated, with minimal and readily available dependencies, though it should be noted that the project expects Python 2. To be clear, Python is required for the program's PyQt4 user interface bindings. The DSP components — synths, fx, sampler, etc. — are written in standard C, with their Qt4 GUIs written in C++. PyDAW is licensed under GPLv3.
PyDAW is a work in progress, with a fast rate of development, so be aware that the descriptions here are subject to change. This review is based on versions from the 12.xx series through 13.03-8. Subsequent versions may change the program's internal and/or external aspects significantly. See the PyDAW Web site for current information about project development and the latest release.
The program opens to the main arrangement screen seen to the right. The top menu bar offers some basic file operations, an offline rendering dialog, a theme manager, and links to the program's Web site and online manual. Immediately below the top menu we see the PyDAW transport and tempo controls, the active region and loop mode indicators, and the MIDI input port selector. Beneath the transport control bar we see six editor tabs, with the Song/MIDI tab set as the default. The top row of the Song/MIDI tab presents a series of empty grey boxes, numbered 0 through 12. Click any box to open the region creation dialog.
Double-click on an item to open the default item editor, a "piano-roll" display for MIDI events recorded from an external device or entered manually. Other editors include GUI and numeric list displays for designing envelopes for parameter controllers, pitch-bend, and velocity values. Multiple items can be edited as a single item — a very cool workflow amenity — with all editors expanded to the specified range.
The CC Map tab displays the default MIDI controller assignments. Controller maps have been prepared for PyDAW's instruments and processors, another workflow amenity that speeds up the design and application of gain curves for synthesis/processing parameters such as filter cutoff frequency, volume control, and low-frequency oscillator (LFO) modulation depth.
For its internal sound sources PyDAW comes equipped with two synthesizers. Ray-V is a virtual analog synthesizer constructed in a standard architecture with a single-panel UI for uncomplicated programming. However, there's nothing missing its design: Ray-V provides two oscillators with four source waveforms, filter and amplitude stages with ADSR envelopes, a pitch envelope, noise and distortion generators, an LFO, and a master mixer section with controls for glide and pitchbend. Ray-V's presets indicate its possibilities in a set of synthesizer pads, leads, and percussion sounds.
Way-V is PyDAW's wavetable synthesizer. Sixteen waveforms are available to each of Way-V's two oscillators, the output from the oscillators is sent to their optional ADSR envelopes, move to a non-optional master ADSR, and finally reach the master mixer. The mixer includes glide and pitchbend controls, and a noise generator is available. The PolyFX processing module mixes the synthesizer's output with up to four effects processors, sending the blend on to PolyFX's own LFO and two ADSR output envelopes. Alas, Way-V includes no preset patches, but new sounds can be created quickly and easily. With my laziest method I merely select different wave types for the default patch. In a more energetic mood I apply and modify Way-V's other parameters for more complex sound design.
Per-track effects processing is managed by the Modulex multi-effects device. Up to six processors can be applied, with available modules for nine filter types, two distortions, a limiter, an equalizer, and a panner. Two pre-defined modules are also available for reverb and a tempo-synchronized delay line.
A caveat for the unwary: MIDI track definitions (instrument, FX, level, state, solo/mute status) persist from region to region. Item definitions behave similarly, with changes in an item applied to all instances of the item, i.e. the original and its copies in any regions. Fortunately, items can be "unlinked" for individual edits, but the user is advised to learn what's fixed, what's flexible, and the default status of objects in the PyDAW UI. Hint: Right-click on a region or item to see available operations.
At the macro-composition level PyDAW's tools promote a rapid workflow. Regions and items can be copied and moved singly or as a group, and playback can be looped to region or item bar, allowing realtime arrangement of your material. By the way, items can be copied and pasted between regions, also in realtime.
Audio content can be set into a track either by employing the Euphoria sampler, by recording new audio directly, or by using the audio sequencer (seen to the left). Euphoria supplies the expected sample file handlers — load/save, MIDI key assignment and range, sample tuning, MIDI velocity sensitivity — and provides a hook to the Audacity soundfile editor for more detailed editing. The audio sequencer's Viewer tab is especially useful for arranging recorded material in arbitrary patterns, with snap-to available for bar/region boundaries (or not at all). Double-clicking on a waveform in the Viewer or single-clicking anywhere in the Item List invokes PyDAW's built-in sample editor, a limited-by-design utility for quick and easy work with time-stretching, pitch-shifting, and setting loop points.
The Tracks tab provides a virtual audio mixing board with five input strips and five buses (master plus four). Input can be routed to any of the eight tracks, each of which has its own bus selector, solo/mute switches, and effects processing. PyDAW isn't designed to be a first-choice application for recording and mixing by electroacoustic instrumentalists, but the facilities are there if needed and they are certainly useful for the creation of new sound samples.
A word about PyDAW's offline rendering: The dialog presents good defaults, the process is very fast, and the output format is an acceptable 32-bit stereo WAV file. That's the word, short and sweet.
Initial workflow proceeds from the top downwards, from Region to Item to Event. Objects are invoked quickly to sustain creative momentum — left-click in the Region/Item areas to invoke those objects, right-click to open their available operations — and many edits can be accomplished with commonly-used keyboard accelerators (Ctrl-C to copy, Ctrl-V to paste, Del to delete). Mouse behavior is predicated by the active editor. For example, group selection in the piano-roll grid is made by holding down the Ctrl key while sweeping with the mouse with any button held down. In the continuous controller and Pitchbend editors it isn't necessary to hold the Ctrl key while making the selection, again with any button pressed.
PyDAW allows any number of sequential Items to be edited as a group. The piano-roll and the continuous controller displays will reflect the decision and show the increased time period. A similar feature allows arbitrary grouping of items for copy/paste operations, a welcome device when creating complex arrangements from multiple items across multiple regions.
I had no problems with basic operations in the PyDAW audio sequencer. Audio clips are arranged on a region-assigned timeline, i.e. the clips play along with the passage of the Song's regions. They can be snapped to bar or region boundaries, or they may be freely placed on the timeline. Only one audio item is allowed per line, and only horizontal replacement is permitted. Double-clicking on an audio clip in the audio sequencer will invoke a basic editor for massaging your sound samples. The editor is intentionally feature-limited, with particular attention given to setting loop points, stretching or squashing the sample length, and changing its pitch. Again, all operations are easy to access and can be applied quickly.
Fizz-pluck-bang [MP3] is a short demonstration piece made with PyDAW 13.03-6. With the exception of one problem getting my laptop's internal microphone to work, all my objectives were met in the piece. I created MIDI sequences in the piano-roll editor that drove sound samples in Euphoria and synthesis patches in Ray-V and Way-V, I added drum loops with the audio sequencer, and I applied a simple volume control curve for one of the synthesizers. Macro-level formation was made simple with PyDAW's easy arrangement of Regions and Items, and the offline rendering was flawless.
The PyDAW author has suggested some recommended settings for improving PyDAW's performance with JACK. Discontinuities in the audio stream can be reduced by switching off JACK's realtime option and raising its buffer period size. Latency will increase, but performance is more stable. Until PyDAW is rewritten for direct connection to ALSA I suggest following Jeff's advice, with a little experimentation with your JACK settings to find the happiest numbers.
Documentation currently consists of the online manual, a wiki, and a forum for exchanges between users and developers. The online docs may not be up-to-date with the latest changes, so it's a good idea to join the forum where Jeff and his associates are quick to respond to reports and suggestions. Jeff is also available on the PyDAW forum at KVRaudio.
For more examples of music made with PyDAW, check out the PyDAW Music page on SoundCloud. New works are also announced on the KVR forum.
PyDAW can stand improvement in some areas. More presets for the Ray-V synthesizer would be nice; any presets for Way-V would be nicer. Cut/copy/paste and multiple selection would be welcome in the audio item display, the audio sequencer could be more flexible, documentation needs some love, and a metronome would be helpful. Fortunately Jeff works to fix PyDAW's most egregious bugs as quickly as possible, and I must note that I've encountered no show-stoppers in recent releases.
I tested PyDAW in three settings. I built it from source code on uniprocessor machines running Arch 64 and KXStudio (Ubuntu 12.04 in i386 mode), platforms clearly underpowered for PyDAW, with predictably poor performance. As I recommended earlier, you'll need a multicore CPU, preferably in native 64-bit mode, with at least 3G memory, to experience PyDAW's full capabilities.
Incidentally, it is worth noting that more audio software is demanding the power of multicore hardware. Harrison's Mixbus and the upcoming Bitwig Studio both require a multicore machine, and explicit support for multiprocessor hardware is present in Ardour3 and Csound.
My best-case reports come from running PyDAW on a dual-core laptop. I built and ran the program under KXStudio (again in i386 mode), and I also ran it from a bootable USB stick created with the 64-bit ISO image from the PyDAW SourceForge site. I followed Jeff's suggestions for improving performance by taking JACK out of realtime mode and increasing its buffer size. My tests weren't realtime-critical, and the higher latency was worth the more pleasant experience while learning how to use the program.
As stated earlier, PyDAW may not be for everyone but it will surely appeal to many contemporary computer-based musicians. If you're into EDM and other electronic styles you should check it out, with the full understanding that the project is still in development (PyDAW v.3 is already in progress) The author wants to know about any bugs or unexpected behavior you encounter in his program, you can reach him on the KVR forum and on the PyDAW wiki.
Page editor: Jonathan Corbet
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds