The PyDAW thread!

[jeffh]

Glad to see things coming along.

Just don't neglect those sharp sounding synths you got got going on there.

Mr. Spurt, long time no see

Thanks for the kind words... The current plugins had some great improvements during the PyDAWv4 development cycle(especially Euphoria)... but my plans for PyDAWv4 after the release are mostly focused around creating quite a few new (mostly synth) plugins for those who would like more variety.

Current plans include additive, analogue-modelling (including emulations of classics), and perhaps a modular...

[codec_spurt]

I was seriously impressed by the sound of your synths.

Very basic interfaces - very easy to use.

You are on to something with these.


I'd actually buy these if you sold them separately.

But including them with the whole package - I'm in!


I'm going to check it out again when I get a bit of time, which should be soon.



Man, your work is really really appreciated.

[jeffh]

I was seriously impressed by the sound of your synths.

While everybody else engages in an arms-race to have oscillators with negative amounts of aliasing and/or have enough oversampling to bring samples within a Planck Length of each other, I actually listen to my synths rather than relying on unit tests to tell me they sound good

Very basic interfaces - very easy to use.

You are on to something with these.

From the very beginning, I wanted to make something that was more like using hardware... When designing hardware synths, each knob you add has a cost and adds to the total cost of the synth, hence you only add a knob when there is real value in doing so. How many hardware synths have 100 knobs? Not very many... yet hardware synths sound great and are a lot of fun to use...

Most softsynths took advantage of the fact that knobs are essentially free, so they add knobs for everything... Which doesn't improve the sound a bit, but does make it much harder to program... Then out of the millions of possible knob value combinations, very few sound good.

I'd actually buy these if you sold them separately.

Orly?

Maybe it's time to setup a Paypal donation account... Or a "donate to the Kris-starter project in my name" button... Wouldn't that be super-cool if I got the 10000GBP prize where I get 30 minutes alone in his studio to wank it to all of his vintage analogue gear while he slaves away in the kitchen cooking me a feast of traditional British food

I'm going to check it out again when I get a bit of time, which should be soon.

I'd say wait for the imminent release of PyDAWv4... I might even commission you to make another piece for the PyDAW Soundcloud page to really show what PyDAWv4 can do

Man, your work is really really appreciated.

You're welcome, bro

[jeffh]

Please all don't speak at once about donating .sfz files to test


Actually, I think .sfz support is good now, so don't worry about it (or at least my test suite can pass with 25 random .sfz files I found on the internets)...

[codec_spurt]

Well, in the beginning it was all supposed to be about the sequencer.

And that was a bit 'esoteric', shall we say, but so are these things.

Got my head around it eventually.

The sound of the synths and the immediacy of the synths were more than a pleasant surprise.


I've talked with Kris a couple of times, about other things, very different things. And he keeps bringing your name up.

f**k the bullshit.
Richard Stallman's name comes up too.

Make of that what you will dear readers.

The time is not for shrinking.


This is going to be a really big project. Most people don't believe it can be done.

We are talking here about a new super duper Linux Audio Standard.

Will we fail?

Yes we might!

But how many tried?



If it all falls flat on its face, you can laugh.
The people trying to make this work don't even expect that much.
But they are trying.

If it all goes down in flames, what the hey.


But in the meantime, behind the scenes, there are people that have the skills, beavering away.


This is such a mad crack.


I got to hand it to you...

[codec_spurt]

Please all don't speak at once about donating .sfz files to test


Actually, I think .sfz support is good now, so don't worry about it (or at least my test suite can pass with 25 random .sfz files I found on the internets)...

That can be arranged.

Big promises, I know.

But I got Wusikstation that converts pretty much anything to .sfz.


Whatever.

You have my PM.

I can only say No.



If you need something.

Probably I won't have the time.

But if you really need it.

Maybe we could talk.

[jeffh]

Well, in the beginning it was all supposed to be about the sequencer.

And that was a bit 'esoteric', shall we say, but so are these things.

Got my head around it eventually.

Well, this was my first ever attempt at coding a DAW, essentially from scratch, whilst simultaneously trying to do something with it that had never been done before: creating the true bastard child of a horizontal DAW and a tracker... It was a learning experience for me, I don't deny it, but I dare say that it is an unbelievably efficient workflow for people making loopy electronic music, I can hack out a tune in PyDAW in a fraction of the time I could've done it in Reaper or Cubase...

The sound of the synths and the immediacy of the synths were more than a pleasant surprise.

...but, I'd probably authored about 100 plugins before I started work on PyDAW, and I dare say that I've mastered the craft... Most of those never saw the light of day, and those that did never achieved any level of success because:

a) ~10 years ago I was a firm believer in not wasting memory on fancy GUIs, so default host UIs (or at least very basic UIs) everywhere. People don't generally give plugins like that a chance, right or wrong...

b) Although they sounded good, they consumed far more processing power than most people's CPUs had back then, in an era where all plugins generally sounded cack but were light on CPU.

Fast-forward 10-15 years, where I've finally sold out and started making respectable looking UIs, and CPU power has caught up to my algorithms, and I can only win now

I've talked with Kris a couple of times, about other things, very different things. And he keeps bringing your name up.

f**k the bullshit.
Richard Stallman's name comes up too.

Make of that what you will dear readers.

The time is not for shrinking.

Ha! I'll let that one remain an inside joke

This is going to be a really big project. Most people don't believe it can be done.

We are talking here about a new super duper Linux Audio Standard.

Will we fail?

Yes we might!

But how many tried?



If it all falls flat on its face, you can laugh.
The people trying to make this work don't even expect that much.
But they are trying.

If it all goes down in flames, what the hey.


But in the meantime, behind the scenes, there are people that have the skills, beavering away.


This is such a mad crack.


I got to hand it to you...

Respect

Like they say, Rome wasn't built in a day... I didn't start work on PyDAW until (for example) years after work on Bitwig had started. Despite the huge disadvantage of PyDAW only having one part-time developer vs. corporations having multiple full-time developers, I dare say that it's come a hell of a long way in a very short time period. In 2 more years, surely I will have perfected every aspect of it now that the underlying technologies are already very mature.

PyDAWv4 is going to be great, probably better than anybody imagined; PyDAWv3 was death-by-1000-papercuts, it is generally stable(especially when compared to the competition), but because it grew so quickly, there were numerous small bugs that I couldn't fix because they would break backwards-compatibility or alter the sound of existing projects. PyDAWv4 not only added some really great and innovative new features, but also fixed every known bug in PyDAWv3 by essentially re-writing the audio/MIDI engine and plugin format... The end result is that it sounds better than ever, uses less CPU and memory, and is 24/7 rock-solid stable.

The next step is to take these mature technologies and expand the product portfolio with more DAWs and more plugins.

[jeffh]

That can be arranged.

Big promises, I know.

But I got Wusikstation that converts pretty much anything to .sfz.


Whatever.

You have my PM.

I can only say No.



If you need something.

Probably I won't have the time.

But if you really need it.

Maybe we could talk.

No worries bro, I was asking because 99.99% of my experience with sampler instruments was Kontakt .nki format, so SFZ was kind of new to me. However, I think I nailed down SFZ support, and it only took me 2 days to write it all and work out the bugs, so it's probably not going to be the doom-and-gloom I was expecting (but SFZ is still a clusterf.ck of a format for sure)

[codec_spurt]

Well it's been fun playin'.

Fo' sure y'all.

Can we kick it?

Yes we can!

[jeffh]

I said the other week that I might release PyDAWv4 maybe next weekend... but now I've decided to delay it for somewhere between 2 weeks and no more than 2 months...

Usually when software (especially audio software) gets delayed because the software crashes, has bugs, munches CPU, etc... This is actually quite the opposite. Right now, PyDAWv4 is so stable, sounds so good, and uses so little CPU, that I feel compelled to keep piling the features on

I'm going to try to add during the extra development time:

* Full automation for per-audio-item effects (would be epic, right?)
* Even more aggressive CPU and threading optimizations for the audio/MIDI engine to give even the crappiest of PCs a fighting chance of running PyDAW
* Alternate tempo per region and maybe tempo automation
* Even more plugin improvements
* Sample accurate (or close to it) time stretching

^^^^of course, if any of these bugger out the release or take too long, then I will drop them for now and plan for a later release...

[stanlea]

Nice ! While you're at it, please add

- LV2 support
- VST support (wine and native)
- integrated coffee macheene

[jeffh]

Nice ! While you're at it, please add

- LV2 support
- VST support (wine and native)

Probably not happening ever... BUT... As mentioned earlier:

* PyDAW's internal plugin format was completely re-written for PyDAWv4 and made super-awesome (and could even be released as an open plugin format that's shockingly easy to implement)

* The existing PyDAW plugins all received some nice new features, and all of them now use far less CPU and memory... (and Euphoria even has SFZ support now + can load up to 100 samples). They've even made huge advances in sound quality, really nice smooth sounds or gritty sounds alike, and I've added some nice presets to showcase it all...

* After PyDAWv4 is released, I plan on adding exciting new plugins frequently (like, maybe one new plugin a month or so?). With the new plugin format + my DSP library making it sooooooo easy to write plugins with very few lines-of-code, it's almost trivial to turn an idea into a quality plugin. Over time, PyDAW will have an absolutely huge collection of built-in plugins. Instead of the dismal rate of most LV2 and VST plugins crashing in most Linux hosts, I will be able to guarantee a stable and smooth experience...

- integrated coffee macheene

Dude, that's been in there since PyDAWv2, RTFM

[jeffh]

I said the other week that I might release PyDAWv4 maybe next weekend... but now I've decided to delay it for somewhere between 2 weeks and no more than 2 months...

Usually when software (especially audio software) gets delayed because the software crashes, has bugs, munches CPU, etc... This is actually quite the opposite. Right now, PyDAWv4 is so stable, sounds so good, and uses so little CPU, that I feel compelled to keep piling the features on

I'm going to try to add during the extra development time:

* Full automation for per-audio-item effects (would be epic, right?)
* Even more aggressive CPU and threading optimizations for the audio/MIDI engine to give even the crappiest of PCs a fighting chance of running PyDAW
* Alternate tempo per region and maybe tempo automation
* Even more plugin improvements
* Sample accurate (or close to it) time stretching

^^^^of course, if any of these bugger out the release or take too long, then I will drop them for now and plan for a later release...

Nevermind, not doing any of that stuff just yet

In other news, I've released PyDAWv4 for Linux (no PyDAW-OS or Windows/Mac images just yet, those will come later).

Since posting that, I discovered a ton of small bugs, as was to be expected with a re-write of this magnitude. I fixed them all, but that made me decide just to release it in it's current state, rather than piling on another mountain of bugs/features and risking turning into another Bitwig, Ardour3, etc...

Downloads are here:

http://sourceforge.net/projects/libmods ... aw4/linux/

Updated screenshots here:

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

There's probably more value in just diving in that attempting to provide a comprehensive change list, but these are a few of the highlights:

* Fixed all kinds of undesirable behaviors and small bugs in PyDAWv3 that I couldn't fix because they would alter existing project sounds and/or break backwards compatibility
* Massive re-write of the audio engine and plugins, now more stable, efficient and better sounding than ever.
* Sample accurate automation
* Euphoria now supports SFZ files
* Many improvements to the plugins, including new features and sonic improvements
* Aesthetic improvements, dare I say one of the nicer looking DAWs anywhere?
* ...and much, much more...


Going forward, the development model is going to change... I'm going to take a more disciplined approach, which means fewer releases to allow more regression testing, and certain areas will be off-limits for any new features until the next major release. The focus of the next set of minor releases will be fixing any/every bug I discover, and adding plenty of new synth plugins...

[codec_spurt]

In other news, I've released PyDAWv4 for Linux

Whoohoo!

[jeffh]

Thanks. I give a try and tell you.

OK : compilation went fine, but the dependencies were broken (due to Audacity dependency). After installing dependencies, it's ok but there's an issue with the window manager (gnome classic for me). There is no way to have the bottom of the window because there is no slider in the pyDAW window.

So, I started dual-booting the Official PyDAW Developer Workstation(tm) with Fedora 19 and the default Gnome3 desktop, because I'm going to start providing RPM packages at the next release... The monitor resolution I do the development on is 1920x1080, but I always test against a 1366x768 laptop as the minimum resolution to run PyDAW, but always using Ubuntu + Unity, which makes the best use of vertical space of any DE...

At one point, whilst admiring how Gnome3 manages to waste about 3 feet (1 meter) of vertical screen space with an unnecessarily large title bar and menu bar, I then had a flashback to the moment in time when I read this post of yours... Then I realized that you were almost surely referring to the condition that happens when the minimum window size is bigger than the available screen size...

This should now be fixed in my latest Git (on github, not sourceforge), and possibly PyDAW works on even lower resolutions now... If you don't want to go through the hassle of cloning my Git repository, it will probably get released next weekend...