After carefully evaluating the situation, I decided rather than carrying legacy bloat by forking PyDAW, I decided to write my next generation completely-conventional-DAW/soulless-Cubase-clone from scratch.  For those that haven’t followed the project since it’s inception one-and-a-half years ago, this has been the evolution of the scope of the project:

1. It was only supposed to be a library and tools for developing DSSI plugins, because LV2 was still in alpha after 6 years of development, with no guarantee of ever seeing v1.0 (not that v1.0, or versions 1.1, 1.2, 1.3 or 1.4 that quickly followed were all that great anyways)

2. After realizing that there was a serious lack of DSP-savvy Linux developers writing original plugins rather than incestual re-packaging of old LADSPA plugins, I decide to go the extra mile and turn the library/tools into an actual suite of plugins, rather than risking another pointless hobbyist repo on Sourceforge with zero adoption

3. I then realize that the only Linux host capable of 100% stable DSSI hosting is the reference DSSI host (jack-dssi-host).  After numerous back-and-forth bickering with various Linux audio developers who insisted that even though every other host failed in a completely different way, that it was somehow acceptable for a DSSI host implementation to be less resilient than the reference DSSI host, and that I should somehow “fix” my plugins in every host(when the format does not support even knowing which host is running it).  I then write my own DAW (catering purely to electronic music) to host my plugins, and cast aside the rest of the “undeniably awesome” (according to the dozens of Linux audio users) existing ecosystem, spawning rumors that I was sent by Satan himself to cause discord in paradise.  Meanwhile, I find my own dozens-strong group of supporters in the Windoze world, who say “Thank Gawd!  Finally a developer who doesn’t turn a blind eye to the millions of Windows users who tried Linux audio, thought it was complete rubbish, and promptly reinstalled Windows!  We are the 99.999999999% , lead us to the promised land!!!”

So, it makes sense to start with a clean code base, and a new, clean plugin format rather than carrying any DSSI-isms.  This will mean that the current plugins won’t be moving to the new format, but it also gives a chance to use hindsight to write even better versions without the massive constraints DSSI imposes on the GUI…  This will also somewhat cause development of PyDAW to slow down, but I’ll probably still be pushing out 1-3 updates a month to it until it hits complete and total maturity.

Interested in checking out the early Git repo?  You can’t.  I’ve decided to develop it privately, and not show it until it is in a very complete, polished, mature and stable state.  Why, you ask?  While some parts of it will most certainly be open source (the JD-Rack super-host, the plugin format, etc…), I may (or may not) make the DAW and some of the plugins commercial, but with demo versions and reasonable pricing.  I will probably also offer the chance to crowd-fund the open sourcing of the code, for a yet-undecided sum of money.  This opportunity will happen once every major version, ie:  Kickstarter project to open source DAW-Next-v1, separate Kickstarter for DAW-Next-v2, etc…

Considering the current “Hello World” state that the code is in, I couldn’t begin to make an ETA.  However, having already written a full DAW + plugin suite in 1.5 years already should make it clear that this isn’t a 5 or 10 year plan, and the prior end-to-end experience will only speed up the process.  Having said that, since there will be no public Git or alpha/beta “preview” releases, I don’t plan on providing any status updates on development until I have a gold-certified, stable, production-ready .deb installer for sale in Ubuntu Software Centre and ready for mass-consumption…

To my detractors who claim to never have even tried PyDAW, but yet still take the time to read literally every word of every post I’ve made on pydaw.org and discuss them on forums and mailing lists all over the internet:  If you’re so confident that Jack and LV2 are awesome, then it shouldn’t bother you that they’ll be having competition soon, so there’s no need to cite this blog post and whine about it across the internet.  Am I the only one that finds it ironic that these people preach software freedom, but yet are intolerant of free speech when it comes to (valid) criticisms of Jack?  If you have any doubts about Jack or LV2 or any of the existing DAWs or plugins, then I would strongly suggest giving it all you’ve got to fix the situation in the mean time, because I am coming for you, with the intent of dethroning Jack and LV2 with sane audio standards (you know, like the kind of sane standards that Windows and Mac audio have flourished under for decades while Linux audio people refuse to acknowledge that Jack and LV2 just might be part of the problem, rather than part of the solution).

I have just posted another release that fixes several bugs, but also adds an important new feature to PyDAW-OS for those using live USB flash drive.

Now, when creating a flash drive, if you create a partition on the flash drive with a partition label called “pydaw_data”, PyDAW will automatically save it’s settings there so that they will persist between sessions.  Please note that this only applies to PyDAW, and not any other applications on the live DVD/USB image.  The wiki page has been updated with the new instructions.

This release fixes every known bug in the v3 series, development is now going to move towards big new features and architectural improvements.

I was able to figure out that Ubuntu 13.04 is actually worse than 12.10 in far less time than expected, so we’re still based on 12.04.  Twice I tried to install to my main hard disk, twice it failed spectacularly to result in a bootable configuration.  At least 12.10 installed, even if it was a crash-fest afterwards.  What’s worse is that the Ubuntu devs have known about the installer problem for at least 6 months, WTF, really?  It’s not like they added anything useful to Ubiquity to justify the breakage…

I also rolled my own live DVD customization scripts, since UCK has roughly a 0% success rate, Remastersys is no more, and Reconstructor is a crash-fest…  I may even spin it off into a separate open source project, since making a live DVD isn’t hard, and yet there is no suitable all-in-one for automating it that doesn’t crash more often than not…  What I came up with in 1 hour by copying-and-pasting from the Ubuntu wiki page seems to work 100% of the time so far, so spending a few more hours making it general-purpose and putting it on my Github seems like a reasonable thing to do…

About JD-Rack (Jack Done Right Audio Connection Kit):

PyDAW is, was, and will always be a tightly-controlled all-in-one aimed at a very specific subset of genres and workflows, and will continue to be developed even after DAW-next is forked from it…  However, my recently announced PyDAW fork to create a conventional DAW will mimic the way that Steinberg succeeded by making ASIO and VST standards that anybody could use, even competing DAWs.  As such, it makes sense to communicate my plans to prospective developers, rather than the shock and awe of launching a surprise product nobody was expecting.

Jack works by connecting separate processes using shared memory, and by using the slow and inefficient DBus to create a “sound server”.  By  everything being separate processes, there is no centralized management of CPU resources, and there is considerable overhead to synchronizing shared  memory and signalling across many processes.  Then there’s the problem of session management, which still has yet to be adequately solved by any of the available session managers.

How JD-Rack is different:

JD-Rack is a single binary executable, that launches, gets configured for exclusive access to a single ALSA device using direct mmap.  Each JD-Rack instance can then load one or more DAWs as a DAW plugin format (ie: a DAW compiled to a .so shared library, and dynamically loaded at run time).  Each DAW plugin can specify it’s own input/output ports and which ALSA device port to output to, and because everything is run in a single process, there is zero overhead in being able to access the input/output buffers of all other loaded DAW hosts, and the entire setup is far less convoluted and fragile than Jack…  Each DAW will be able to create it’s own project file format, but they will all be saved and written to disk by JD-Rack, this centralized control will ensure that JD-Rack doesn’t become encumbered by the same session management failures that have held Jack back all of these years.

Each host can load it’s own instrument/effect plugins, HOWEVER, rather than each host processing it’s own plugins using it’s own set of worker threads, all hosts submit work items to the JD-Rack host to be processed, which allows JD-Rack to intelligently manage CPU resources as opposed to the anarchy of Jack, where no application can know how the other applications are managing worker threads, and therefore could never optimally manage it’s own.  JD-Rack,  in turn, ensures that everything is processed in the correct order, mixed and sent to the correct ALSA device outputs.

Aside from the obvious benefits, this will also offer a greatly simplified programming model vs. how things are done today in Linux audio.  JD-Rack will take care of the most difficult and error prone aspects of developing a DAW (plugin processing, mixing, managing buffers, ALSA devices, etc…), and provide a relatively simple and straightforward API for connecting to it.  This will enable developers to focus on high-level features and slick UIs, instead of searching for SEGFAULTs and thread concurrency errors in low-level C code.  One solid, well-designed super-host to rule them all.

This is a huge release, nearly every area of PyDAW has seen massive improvements in the ~1 month since development started (and continues to prove that PyDAW is the only Linux audio project that can deliver the goods in a timely manner).

Highlights (not a comprehensive “what’s new”):

1.  Many improvements to the plugins (especially Way-V)

2. Reworked automation and CC maps

3. All new audio sequencing

4. Items and regions can now be renamed

5. Many new effects (stereo chorus, formant filter, ring modulator, lo-fi and more…)

While PyDAWv3 is a giant leap forward vs. PyDAWv2, this release was mostly about creating a solid foundation for future releases, look for PyDAWv3 to have rapid release cycles that add new features and refinement to existing features, much like PyDAWv2 did.

PLEASE NOTE:  There are no PyDAW-OS images yet, or an ETA of when there will be. I’m in the process of evaluating whether to continue basing it on Ubuntu 12.04, or the just-released Ubuntu 13.04…

ANNOUNCEMENT:   Features missing from PyDAWv3 include the ability to record audio and sequence it at the song-level…  One could draw the conclusion that I’m ceding the traditional recorded genres to Ardour to focus on electronic music.  Nothing could be further from the truth…

After PyDAWv3 reaches it’s logical conclusion, I plan on forking it into a new DAW, based on the conventional DAW format (ie: like Reaper, Cubase, etc…), and even including a plugin format and even an alternative to Jack(that is neither fragile nor has any significant overhead to run).  PyDAW was always intended to be the ultimate tool for composing electronic music.  Producing traditional recorded genres is a completely different job than producing electronic music, so much that in the spirit of “one tool per job”, it is worthy of having it’s own tool, rather than being consolidates into PyDAW’s paradigm.

DAW-next will still have PyDAW’s top-notch plugins and MIDI support, but will use the traditional “one giant timeline with everything directly in it” paradigm instead of PyDAW’s pattern-isms…