Linux has a new DAW: PyDAW 12.11 released

[jeffh]

2.5 months after I wrote the first lines of code, the first release of PyDAW is now ready for public consumption.

Already slightly outdated screenshots:

http://sourceforge.net/projects/libmods ... editor.png
http://sourceforge.net/projects/libmods ... uments.png

Ubuntu 12.04 packages:

http://sourceforge.net/projects/libmodsynth/files/

Source:

https://github.com/j3ffhubb/audiocode

Features:

Unique, MIDI focused workflow, somewhere inbetween a conventional DAW, a tracker, a drum machine.

Built in modular sampler, analog style synthesizer and multieffects unit featuring 15 different effects. (no 3rd party plugin support, nor any plans to support any 3rd party formats)

Efficient, low latency multithreaded plugin processing, makes excellent use of 4 or more cores...

Extreme accuracy engine; Sample-accurate plugins and external MIDI recording, with the host capable of extreme sub-sample accuracy. No concept of ticks-per-quarter-note or any other 1980s style MIDI-isms, just unbridled digital accuracy.

A UI written entirely in Python and PyQt4, with a high performance audio/MIDI back end written in C, all with very few 3rd party library dependencies.

Disclaimer:

The current release, while basically functional and reasonably tested before being released, should be considered experimental, and things like the file saving format, etc... may change in the next few months before I declare the project stable with guaranteed forward-compatibility. I'm letting the public evaluate it and report any bugs before I work on the next wave of features; I want to ensure that the core audio/MIDI loop, UI and plugins are 100% unbreakable and 24/7 production-capable before I start piling on features. There are a few known issues, but they're all minor annoyances, I think I've worked through all of the show-stoppers. If you do find any bugs, please help make PyDAW better and report it.

Forthcoming features currently being worked on:

Robust audio sequencing and recording via Jack
A comprehensive undo/redo system based on Git that will maintain a complete history of every change you've made since creating the project(which is exactly why the current file-saving format is designed the way it is)...
Offline rendering of a project to .wav file
region and song level automation
An integrated manager application for Jack and ALSA settings, not unlike QJackCtl
Routable track outputs and bus tracks + master track with integrated effects
Freeverb integrated directly into the multieffects unit
Metering
A new larger, more modular and feature-rich synthesizer plugin(wavetable, FM, etc...)
A Live CD image for trying PyDAW or creating a studio-on-a-stick
A piano-roll editor, maybe a notation-editor, maybe even some kind of drum editor... Any other kind of editors I may have missed.

[nils]

when is the notation editor coming and how will it look like?

[jeffh]

when is the notation editor coming...

I don't know, I'm pretty much in feature-freeze until I'm content that the core fundamentals of PyDAW (aka, what's already in there), is 100% free of any bugs... Having said that, I expect to have it sorted out in 2-4 weeks, so sometime after that....

...and how will it look like?

Well, it wouldn't be hard to hack one out in PyQt using the built-in painting and some basic notation .png's that I could hack out in GIMP, which could either align to PyDAW's unique concept of 'items', or I could make them song or region level(probably more useful to the people who care about notation editors)...

However, I was actually leaning towards making notation editing a separate Python script that opens a completely separate window, and using a 3d OpenGL gaming engine like Pyglet, PyOpenGL or PyGame, and doing some kind of 3d, smooth-scrolling animated eye-candy-filled affair... My initial experiment using Pyglet was pretty promising, I could have an entire screen full of sprites moving around smoothly at 30fps on a fairly weak GPU(Radeon 5450 using the FOSS driver).

[mgraham]

I like the way songs are subdivided into sections and sections are broken out into parts.

How well will it deal with odd time signatures?

[jeffh]

I like the way songs are subdivided into sections and sections are broken out into parts.

How well will it deal with odd time signatures?

That's forthcoming... For now, it's all four-to-the-floor western-style Britney Spears music, but I was eventually going to integrate the following features:

1. Items will be able contain a number of beats other than 4 (probably going to be a global setting for the entire PyDAW project)
2. Regions are currently always 8 bars long, but eventually there will be an option for any particular region to be anywhere from like 4 to 16 bars (subdivided down to beats, ie: a region can be 8 bars and 2 beats long). There will also be a global option for the PyDAW project to have the default length of a region be something other than 8, like 12 bars for Blues, etc...

Having said that, I've never personally done a tune in anything other than 4/4, if the odd-time-signatures crowd has any input for how best to implement it, I am open to suggestions.

BTW, I fixed a somewhat major bug with projects other than the default project not recalling correctly; It was actually a last-minute-regression introducted in a last-minute-fix right before I released... I'm going to try to wait a few more days to find any other bugs before I re-spin the .deb packages...

[tux99]

Looks interesting, the only thing that I'm worried about is the python requirements (in my experience as packager, python version compatibility is tricky, quite a few python apps only work with specific python versions), which versions of Python does it work with and what additional python libs are needed?
I'm particularly interested in knowing if it works with python 2.6 as that's what current Centos 6.x, Scientific Linux 6.x (and Redhat EL6) distros come with.

[jeffh]

Looks interesting, the only thing that I'm worried about is the python requirements (in my experience as packager, python version compatibility is tricky, quite a few python apps only work with specific python versions), which versions of Python does it work with and what additional python libs are needed?
I'm particularly interested in knowing if it works with python 2.6 as that's what current Centos 6.x, Scientific Linux 6.x (and Redhat EL6) distros come with.

AFAIK, it should work with Python 2.6 as long as PyQt4 and python-liblo are available. I developed it on Python 2.7, and it doesn't rely on any of the more exotic features of Python or Qt.

[tux99]

AFAIK, it should work with Python 2.6 as long as PyQt4 and python-liblo are available. I developed it on Python 2.7, and it doesn't rely on any of the more exotic features of Python or Qt.

Thanks, if I find the time for it I will try it this weekend on Centos 6.3 (if I do I will let you know if it works or not).

[jeffh]

I think the latest packages are getting pretty f'ing stable now, you can get them here:

http://sourceforge.net/projects/libmodsynth/files/

The changes being:

Euphoria Sampler: Fixed UI failing to launch under certain conditions
Improved multithreading, better performance and stability, including fixes for a possible race condition
Fixed previewed samples being played back on project load
Projects (or parts of projects) can now be rendered directly to .wav file using the FileMenu->Offline Render option (not in real-time, aka, disconnected from Jack, XRuns can't screw up your audio, etc...)
Fixed a bug where MIDI items recorded from an external MIDI keyboard may not play back correctly
Numerous smaller fixes...

Moving on to next month's release now, I'm going to focus on multitrack audio recording/sequencing and my big plans for an epic undo/redo system. Within the next 3 months PyDAW should be approaching feature parity with existing mature DAWs, then in the 6 months after that: World DAWmination

[tatch]

looks interesting! I like the grid interface, reminds me of seq24, which I find incredibly intuitive to use but with a few drawbacks (automation is a pain imo). I just installed pyDAW, time to put my rather-limited electronic music experience to the test!

[tatch]

I'm in the middle of looking around PyDAW right now, and I'm a little confused, maybe just because I'm not used to this editing paradigm. Is this what they call a "tracker"? Interesting.

So far I haven't been able to correctly connect a track to a synth, I'm trying to follow the manual instructions but I'm not able to locate which combobox i'm supposed to click to open the instrument dialog or whatever it is. A few more things I noticed, sorry if I'm listing things you already know:

-in the gridview, right-clicking on the track info panels at the beginning give the same copy/paste/etc dialog as on the track grid
-neither sections nor regions can be renamed
-if all that's going to be in the boxes is the name of the section/region, I think it would be more helpful to vertically compress the boxes into rectangles to allow for more information to be viewed on the screen

Aside from the grid itself, the interface to me is very new, so I'll probably have to wrestle with it for a while before I can make any sounds out of it, but I will try to report back when I have.

edit: I discovered the "track" tracks below the bus tracks, perhaps I wasn't being observant enough, though this brings up some more things possibly worth mentioning:

-the scrolling interface for the tracklist seems to be by-track instead of featuring smoother scrolling or whatever you might call it, is this a preference of yours? Because I think a smoother scrolling experience would make things easier to find.
-what are the bus tracks for?

[jeffh]

I just got home from going clubbing on a weekday, I'll attempt to answer your questions, then I'm going to bed

-in the gridview, right-clicking on the track info panels at the beginning give the same copy/paste/etc dialog as on the track grid

Oops, I thought I fixed that... Thanks for the heads-up....

-neither sections nor regions can be renamed

That's a known limitation with a planned fix... Eventually the items will have UIDs, instead of being referenced by names, which will allow them to be renamed.

-if all that's going to be in the boxes is the name of the section/region, I think it would be more helpful to vertically compress the boxes into rectangles to allow for more information to be viewed on the screen

That's something I'm working on, but Qt is making it unnecessarily difficult... Every attempted fix I've tried for it thus far wound up being worse than the actual problem

Aside from the grid itself, the interface to me is very new, so I'll probably have to wrestle with it for a while before I can make any sounds out of it, but I will try to report back when I have.

The heirarchy goes like this:

song{contains regions}
regions{contain items}
items{contain notes, CC automation and pitchbend}
tracks{host instruments and effects, and receive notes, CCs and pitchbend from items, and output audio to the busses}
busses{mix together audio from tracks, and optionally apply effects like EQs, filters, limiters, etc...}

Probably the least obvious concept is that notes can be longer than an item. For example, you can start a note on beat 3.0 of one item, and have the note held for 16 beats or something, overlapping the next several items... It may seem complicated, but it actually makes all kinds of syncopated rhythms a lot easier than using a linear piano-roll editor like Cubase or Reaper. It also plays into PyDAW's concept of regions well, when making electronic music, everything is usually broken down into 8 bar regions anyways, so in PyDAW you would make your first region, copy it and add something to the copy to make your second region, etc... Then you can right-click>unlink items to make new item variations from copies of existing items...

Therefore all items are 1 bar long, but can have notes extending past the ends of the items, regions have a default length of 8 bars (which you can change per-region), rather than the traditional concept of the song being one big thing that directly contains items that can be any length... And you can use CTRL+C/X/V to copy/cut/paste items within a region(and notes/CCs/pitchbend within an item), and you can copy a new region from an existing region... It achieves the same things a traditional setup does, but IMHO in a way that makes more sense for electronic music, which is usually very pattern-based.

Probably the other "gotcha" is the sampler modes(far right on the first tab in Euphoria)... There's a mode that adds character to bright, pitched samples, gives them kind of a gritty hardware-like sound, but certain things (like kick drums and other non-bright percussive sounds) sound a bit wonky using that kind of interpolation... There's a 2nd mode for that, which doesn't add much in the way of character, but also doesn't make anything sound bad... The first mode is the default now, but in the next release it's actually going to the be the "new and improved" 2nd mode I just implemented tonight... I should've thought that default setting through some more, because most people probably just use samplers for drums, and will probably not have a good first impression of what is otherwise a very capable sampler because of that

-the scrolling interface for the tracklist seems to be by-track instead of featuring smoother scrolling or whatever you might call it, is this a preference of yours? Because I think a smoother scrolling experience would make things easier to find.

I like that suggestion, but I'm not sure if that's something that the Qt QTableWidget I'm using supports... Maybe it's just a setting somewhere, I'll do some research on that...

-what are the bus tracks for?

Mostly so that you can mix tracks together and apply effects to them together as a group before mixing them into the master channel and sending them to the audio interface. For example, it's very common to route the bass elements of a track to a single bus, then run them through a limiter, so that they don't cause the other parts of the track to start pumping... Many people also route the midrange and treble elements to their own tracks to be limited and/or EQ'ed together...

[jeffh]

@tatch: I've implemented most of the features/fixes you asked for, except for the right-click on the track bug, because that will be a very invasive fix... I have made sure that the right-click bug can't actually harm anything, it's just cosmetic.

@everybody else:

PyDAW 12.12-11 is out:

http://sourceforge.net/projects/libmodsynth/files/

It has a much improved UI, and has been extensively tested to provide a stable experience. The current PyDAW v1 is now in maintenance mode, I'm going to begin work on PyDAW v2, which will mostly feature audio tracks, and external audio recording, a Live CD/USB image, among other features.

Important: In the interest of spreading Linux audio to a broader audience, I won't be making release announcements on linuxmusicians.com anymore. I'm going to be focusing on taking PyDAW v2 and beyond to a broader audience. Those following PyDAW are encouraged to follow the above SourceForge page for updates, which will be coming frequently.

[danboid]

Cool stuff Jeff!

I will try pydaw v2 as it sounds like it should be able to compete more evenly with my current Linux DAW faves but it will all depend on how good the synth is then for me.

You say I'm happy with Linux audio as it is but thats not true at all - in fact I'm about the most vocal person in the world in voicing my unhappiness with its current state. You can call me a n00b all you want but I've been following Linux audio since '96 and I've been heavily involved in it since the days of JACKLAB - circa 2007. I know for a fact that my extensive and thorough bug reporting, testing, video production and documentation writing has gone a long way in advancing our community and my contributions have been widely acknowledged by Paul Davis, Rui, Falk and many others.

I really appreciate your efforts and you can fully expect pydaw will undergo the same intense scrutiny I give any other project I take interest in when I deem it useful but by the sounds of it I shouldn't have much to complain about - which is what I'm hoping for - as you claim to have very rigorous test procedures in place that should stop nitpickers like me dead in their tracks.

[jeffh]

Ah... I feel a re-hash of my previous "There's no possible combination of plugin flags that will please all hosts" rant coming on

1- modulex uses dssi run_synth, thus making it a synth and not FX.
please set that function to NULL so that hosts know it's an effect and not a synth.

This is intentional. The ability to show the GUI is part of the DSSI spec, if the host only recognizes it as a LADSPA plugin, it probably won't allow the GUI to be shown, which pretty much renders the plugin useless, since the generic UI will show the effect choices as a number 0-15 instead of by effect name... This is another example of fixing something in one host and breaking it in several others... If you really want this, I think you should make a separate KX Studio patch...

2- ray_v has no run() function (set as NULL), which is mandatory (even if the plugin is a synth).
please add a (maybe dummy) function there.
renoise refuses to load it because of this^.

The 'run' function isn't mandatory for DSSI plugins(or shouldn't be). 'run_synth' is 'run', plus 2 extra arguments for a MIDI event buffer array and int count of MIDI events. Any host that freaks out at a DSSI synth not having a 'run' function should be fixed at the host level, there's no good reason to refuse to load(or crash) because that isn't there... It's not like any DSSI synth in existence is useful without MIDI, so if it's checking for a function pointer to be set, even though it will never be used, then it shouldn't be... I think this is really something that the Renoise people should address, but once again, if you really want this, I think you should make a separate KX Studio patch...

3- way_v port number 104 is neither input or output.
renoise also refuses to load it.

Oops... My bad, I skipped over 104 when creating the ports. Unfortunately, one of the biggest failings (IMHO) of LADSPA is that if you re-order the port numbers, you break the plugin for every host/project it's already been saved(because on re-load values will be assigned to the wrong control), so that rules out a 'correct' fix... If you are saying that a null port 104 is the reason that Renoise doesn't work, they would only need to wrap their port iterating code in a "if port_descriptor[x] is not null{...}" block to then be able to handle it properly like other hosts... For that reason, I'm not so keen on fixing it, but if you really wanted to you could patch in a dummy port @ 104... Or, ideally, if this is a Renoise problem, they should fix it, it goes without saying that any host should have as much resiliancy as possible built in...

4- euphoria and pydaw are not set as rt capable (the ladspa flag in the plugin properties), so live hosts may refuse to load it.
(the other plugins might also have this issue, but because of previous issues they didn't get this far in the testing).

PyDAW isn't actually meant to be used as a plugin, it has no means of syncing to host tempo or start/stop playback, so even if technically possible to load it into another host, it's completely useless when used that way... I just forked Ray-V into PyDAW as a quick-n-dirty way of getting Jack/ALSA support + a well tested main loop, PyDAW showing up as a DSSI plugin was a side-effect... In fact, yesterday I made PyDAWv2 into a real standalone Jack/ALSA app without requiring my fork of jack-dssi-host to load it...

Euphoria wasn't marked as RT capable because I had aspirations of making it not-necessarily-RT-capable with time-stretching libraries... Although I would argue that if Renoise or other hosts are not going to fully support the full DSSI spec(including non-RT plugins), then they shouldn't bother to check those flags at all... If I had followed through with making Euphoria v1.0 not-necessarily-RT-capable, then they just shut themselves out from using it, when in fact it would probably still work.

That flag just indicates that the plugin will try to avoid certain expensive/time-consuming operations in the main loop, but like anything else, whether something will run without dropouts has far more to do with the CPU it's running on than whether I technically met some guidelines for being "RT capable"... Hell, I could've added some really computationally intensive stuff like 512pt SINC interpolation to Euphoria, which would have still technically met the RT guidelines, and yet it would still choke any PC attempting low latency... So, in short, any host that takes that flag seriously and as just cause for refusing to load a plugin, shouldn't be...

So, please don't take this as me being a dick, but once again, if your top priority is to have the plugins work in Renoise, I think you should maintain your own patch of these things... Or preferably ask the Renoise people to address these problems, surely there are other plugins out there needlessly not working in Renoise for the same reasons...