Linux...anybody using it?

[StudioDave]

All right, Jeff, that's looking *good* in the Audio Items section ! I'm wrapping up the review, hopefully I'll get a final draft done by tonight. I really have only a few minor criticisms at this point, PyDAW's definitely come along to a very usable condition.

I'll check out the new stuff asap, thanks for the heads-up.

Best,

dp

[StudioDave]

Audio Item enhancements look great, Jeff. Btw, some of my criticism is more in the nature of a request or three, e.g some presets for Way-V, some more predefined fx (chorus, flanger, etc), MIDI data display in the Item block (like the audio item display), minor stuff.

In the critical way:

I note that on playback the cursor stops at the end of the last item in a region and skips the first item of the next. It catches up by starting at the second item in the following region (or looping region). Audio is unaffected, the cursor simply skips tracking the item. Let me know if that's not clear.

Also having erratic behavior with the envelope editor, it gets hinky about when/where I add/delete breakpoints. Sometimes a change near the start of a curve winds up forcing all following points to the end of the curve, piling them up in a nice vertical line.

The quantize/transpose/velocity etc editors in the piano-roll editor appear to affect only the entire item. Something like "Edit only selected events" would be nice.

Despite this avalanche of complaint I'm somehow managing to have a lot of fun with PyDAW. Compliments to you & your associates, keep the good work coming in and I'll try to keep up with it.

Best,

dp

[urlwolf]

I was attracted by pydaw from day one.
I'm a hobbyist, I don't want to spend time configuring the DAW. So no jack, direct alsa really motivates me.

However, it looks like pydaw wants to connect to jackd by default:

pydaw2 --help
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jackdmp 1.9.9
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2012 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
Cannot create thread 1 Operation not permitted
Cannot create thread 1 Operation not permitted
Cannot create thread 1 Operation not permitted
JACK server starting in realtime mode with priority 10
Cannot lock down 82274202 byte memory area (Cannot allocate memory)
audio_reservation_init
Acquire audio card Audio1
creating alsa driver ... usb_stream:1|usb_stream:1|1024|2|48000|0|0|nomon|swmeter|-|32bit
ALSA: Cannot open PCM device alsa_pcm for playback. Falling back to capture-only mode
JackTemporaryException : now quits...
Cannot initialize driver
JackServer::Open failed with -1
Failed to open server
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started

pydaw: Error: Failed to connect to JACK server

-------
I don't have jack running. I'd like to stay that way

Is there any way to tell pydaw to force-use direct ALSA?
Thanks

[glokraw]

I was attracted by pydaw from day one.
I'm a hobbyist, I don't want to spend time configuring the DAW. So no jack, direct alsa really motivates me.

You could use Windows 8, with the classic shell, instead of the
tablet gui, and never install jackd.

http://www.classicshell.net/



Several folks here like Win 8 a lot to host a daw.

[jeffh]

e.g some presets for Way-V

LOL, I know... I keep telling everybody I'm doing it soon but I never do

some more predefined fx (chorus, flanger, etc)

That's going to be part of PyDAWv3, the comb filter can achieve pseudo-flanger-ness, and I'm planning stuff like formant filter, morphing filters, vocoder, etc...(and why not a chorus while I'm at it?) for PyDAWv3.

MIDI data display in the Item block (like the audio item display), minor stuff.

That's a bit trickier... One of the key features of PyDAW(and one of my biggest gripes with Cubase and Reaper), is that PyDAW items can have a note longer than the item which enable all sorts of syncopated rhythms that are a PITA in other DAWs... So to properly represent that, I would need to draw note lines that hang off the end of the item, which while feasible, probably won't look very good...

I note that on playback the cursor stops at the end of the last item in a region and skips the first item of the next. It catches up by starting at the second item in the following region (or looping region). Audio is unaffected, the cursor simply skips tracking the item. Let me know if that's not clear.

I'll try to make it a bit smoother... It's actually a total hack right now, there is no sync with the back-end, I'm just running animations off of a timer and hoping nobody can notice the imperfection in the sync

Also having erratic behavior with the envelope editor, it gets hinky about when/where I add/delete breakpoints. Sometimes a change near the start of a curve winds up forcing all following points to the end of the curve, piling them up in a nice vertical line.

Yeah, I'm not quite sure I understand exactly what you're doing and the expected result vs. actual result... A before and after picture might help...

The quantize/transpose/velocity etc editors in the piano-roll editor appear to affect only the entire item. Something like "Edit only selected events" would be nice.

Ah... yes... I forgot about that... It does work on selected notes if you use the list editors, but I haven't yet built the infrastructure into the piano roll for it to work there... I'll put that in the top-secret PyDAW-TODO.txt file on my PC...

Despite this avalanche of complaint I'm somehow managing to have a lot of fun with PyDAW. Compliments to you & your associates, keep the good work coming in and I'll try to keep up with it.

I'm glad your enjoying it, most of the ideas/goals I set out with are finally shaping up into an actual downloadable product... and I think it's just me developing PyDAW again now, I'm not sure what happened to my little helper

[jeffh]

However, it looks like pydaw wants to connect to jackd by default:

...

I don't have jack running. I'd like to stay that way

Is there any way to tell pydaw to force-use direct ALSA?

I'm planning on ditching Jack support completely in PyDAW v3 in favor of direct ALSA (and clearly you are somebody who can appreciate why I would want go that route), but for now it only supports Jack for audio. The reason for that is because PyDAW and it's plugins were forked from the DSSI example host and example plugins, which used Jack exclusively and no option for ALSA.

Audio in PyDAW v3 will be configurable by selecting an ALSA device, then PyDAW will create an audio input track for all of the inputs on that device...

If you wanted to run PyDAW without installing Jack on your current system, you could use PyDAW-OS on a flash drive from here:

http://sourceforge.net/projects/libmods ... /pydaw_os/

I recommend following the instructions here for the best experience when using a live USB flash drive:

http://pydaw.org/wiki/index.php?title=PyDAW_OS

[nofrets]

Are you talking about removing the dependency on JACK, or removing support for it altogether? I can think of a few cases where it would be handy to use a JACK input to get audio into PyDAW from another app.

[jeffh]

Are you talking about removing the dependency on JACK, or removing support for it altogether? I can think of a few cases where it would be handy to use a JACK input to get audio into PyDAW from another app.

Removing it altogether...

I'm not so much concerned about interoperability with other audio apps, if PyDAW can't do something that app XYZ can, then I should be adding that capability to PyDAW, not relying on app XYZ to do it for me... I have long had the hardcore DSP know-how, and now possess the Qt wizardry to write anything in the way of Linux audio applications, and I truly believe that I can deliver a much smoother and more integrated user experience by doing so. Stuff like Jack and session management are just a PITA to people like myself recently coming over from the Windows world where everything "just works", and nobody wants or needs virtual cables running everywhere.

Considering that PyDAW was meant to be a very complete all-in-one solution(and is quickly living up to that promise), what exactly would you want to record in from another application that couldn't be done better/more-efficiently internally within PyDAW?

[kmatheussen]

I was attracted by pydaw from day one.
I'm a hobbyist, I don't want to spend time configuring the DAW. So no jack, direct alsa really motivates me.

You have to configure the soundcard anyway. With jack, you only have to configure your soundcard one time, not in every program you use. Alsa is a complicated system, meant for low level access to the soundcard. Programs accessing alsa directly often (very often actually) have buggy sound. If all programs accessed alsa directly instead of pulseaudio or jack, linux would be a very frustrating system.

I also wonder what's the big problem having jack running? That's the first operation I do when I start my computer; start jack. It's a one click operation, and it runs in the background till I hibernate the computer. It spares me a lot of frustration trying to make programs run with alsa instead, plus a lot of jiggling with starting and stopping programs since only one alsa program can make sound at the time (at least some of the programs are like that, and especially audio programs that requires very low-level access to the soundcard.).

[kmatheussen]

Stuff like Jack and session management are just a PITA to people like myself recently coming over from the Windows world where everything "just works", and nobody wants or needs virtual cables running everywhere.

It's a waste of time programming alsa directly. You should instead start jack directly from PyDAW. Ardour does that in OSX, and MixBus does the same in windows. There is an option for starting jack automatically in the jack_client_new function.

It's completely optional whether people wants to use the session management and routing features of jack, so those are not arguments against using it.

[StudioDave]

I'm not so much concerned about interoperability with other audio apps, if PyDAW can't do something that app XYZ can, then I should be adding that capability to PyDAW, not relying on app XYZ to do it for me...

Csound
SuperCollider3
Pure Data
Common Music
AVSynthesis

Fold all that into PyDAW, Mister Wizard.

In my review I point out that PyDAW's appeal is limited to certain modes of composition. It is in fact useless for most of the serious work I do, but 1) I'm a long way from your target of the Windows-typical music software user and 2) I'm a long way from the contemporary meaning of "electronic music". Like yourself, I'm an expert (in music theory, performance, and composition), with considerable wizardry of my own, and for PyDAW to even start replacing my workflow it would require at least the following additions:

The twenty-plus MIDI transforms I use all the time in Sequencer Plus Gold, with range delimitation.
The phase-vocoder and waveguide opcodes from Csound (and a few dozen more I use less frequently), e.g. the reverbs from Csound and PD, the FM synths from Csound and PD, etc.
The OO coding routines of SC3, entered and evaluated a la CM or SC3.
Auto-compansion in time and frequency domains.
Graphic patching language a la PD for creating new synths and compo routines.
Direct support for time-sync'd 3D graphics and video, with parameter union a la AVSynthesis.

That said, I'll say again that I find PyDAW to be coming along very well and it is proving to be an effective self-contained environment for making beat music and contemporary EDM.

@kjetil:

How's it going, old friend ?

The matter of JACK is a non-issue wrt PyDAW, just leave it (and jeffh) alone. JACK works abysmally with PyDAW, a clear indication of the design's unconcern for the JACK graph. PyDAW follows LMMS and SunVox in that regard, they don't do so well with JACK either, nor do they need to. The Linux audio world is flexible enough to bear non-JACK-savvy apps, even apps that have no interest in the apps around them. Jeff has targeted a certain core audience for PyDAW, i.e. Windows users coming into Linux looking for a replacement for Cubase and Ableton, and he has made it clear that he has no interest in any other opinion, plan, design, or whatever. Leave it be, let him develop his software as he sees fit, and time will tell whether his decisions are fruitful enough to multiply the PyDAW user base. If the users decide PyDAW isn't worth their time it'll sink on its own. But frankly, I see a need for such an app, and I think Jeff's doing a nice job getting it into shape. His opinions re: JACK are just his opinions, you can safely ignore them.

Best,

dp

[kmatheussen]

@kjetil:

How's it going, old friend ?

The matter of JACK is a non-issue wrt PyDAW, just leave it (and jeffh) alone. JACK works abysmally with PyDAW, a clear indication of the design's unconcern for the JACK graph. PyDAW follows LMMS and SunVox in that regard, they don't do so well with JACK either, nor do they need to. The Linux audio world is flexible enough to bear non-JACK-savvy apps, even apps that have no interest in the apps around them. Jeff has targeted a certain core audience for PyDAW, i.e. Windows users coming into Linux looking for a replacement for Cubase and Ableton, and he has made it clear that he has no interest in any other opinion, plan, design, or whatever. Leave it be, let him develop his software as he sees fit, and time will tell whether his decisions are fruitful enough to multiply the PyDAW user base. If the users decide PyDAW isn't worth their time it'll sink on its own. But frankly, I see a need for such an app, and I think Jeff's doing a nice job getting it into shape. His opinions re: JACK are just his opinions, you can safely ignore them.

Best,

dp

Hi Dave,

I guess my posts were a little bit harsh. I'm very interested in seeing PyDaw succeed.
I think it's very good that someone does something else than to
reimplement Cubase. I wish Jeff all the luck and success he can get,
and so far he seems to do everything right. But throwing out jack would probably
be a mistake. Perhaps not a big mistake, but there's no reason to do so.
It's simpler to start jack from PyDaw directly (without the user noticing
that jack is being used), than programming Alsa. It was only meant as
a friendly advice, nothing more.

[jeffh]

Csound
SuperCollider3
Pure Data
Common Music
AVSynthesis

Fold all that into PyDAW, Mister Wizard.

I'm not familiar with all of those, but I think they're mostly modular GUI-based programming languages? I actually used to use Reaktor 3/4/5 a lot, but TBH I'm not really a fan of the approach as it can be done so much better in real C/C++ code...

In my review I point out that PyDAW's appeal is limited to certain modes of composition. It is in fact useless for most of the serious work I do, but 1) I'm a long way from your target of the Windows-typical music software user and 2) I'm a long way from the contemporary meaning of "electronic music".

...but, we are dealing with a DAW developed (mostly) by one person, where the first lines of code were being written just over 6 months ago:

Step 1: Appeal to the Deadmau5's and Skrillex's of the world
Step 2: Appeal to the Curt Cobain wannabe's
Step 3: Profit
Step 4: Appeal to Dave Phillips

The twenty-plus MIDI transforms I use all the time in Sequencer Plus Gold, with range delimitation.
The phase-vocoder and waveguide opcodes from Csound (and a few dozen more I use less frequently), e.g. the reverbs from Csound and PD, the FM synths from Csound and PD, etc.
The OO coding routines of SC3, entered and evaluated a la CM or SC3.
Auto-compansion in time and frequency domains.
Graphic patching language a la PD for creating new synths and compo routines.

I feel you, but... I practice "Gall's Law", which states to first build a simple system that works, and then evolve it into a complex system... Today I mostly have a simple system that works, but all of those features skip a few important evolutionary steps

Direct support for time-sync'd 3D graphics and video, with parameter union a la AVSynthesis.

To be completely honest, I'm not so much into video editing, that would be one for PyDAW v15 due out in 2018, ie: once I've already conquered everything and there's nothing left to add, then we can talk about video

That said, I'll say again that I find PyDAW to be coming along very well and it is proving to be an effective self-contained environment for making beat music and contemporary EDM.

...and I understand it's not going to be for everyone, it's mostly aimed at one (large and growing) group of people whose needs are IMHO under-served by Linux and even by the available Windows software. If I can better serve them than Windows, Linux and open source win, and there's still Ardour for people recording bands...

JACK works abysmally with PyDAW

I think "abysmally" is kind of a strong word, it performs pretty well on my entire array of < 2y/o PCs

a clear indication of the design's unconcern for the JACK graph.

True, guilty as charged...

Jeff has targeted a certain core audience for PyDAW, i.e. Windows users coming into Linux looking for a replacement for Cubase and Ableton, and he has made it clear that he has no interest in any other opinion, plan, design, or whatever. Leave it be, let him develop his software as he sees fit, and time will tell whether his decisions are fruitful enough to multiply the PyDAW user base. If the users decide PyDAW isn't worth their time it'll sink on its own. But frankly, I see a need for such an app, and I think Jeff's doing a nice job getting it into shape. His opinions re: JACK are just his opinions, you can safely ignore them.

^^^^This. I have invested a lot of time and effort in the past year to my plugins, and the last 6 months into PyDAW... and I have yet to regret a single design decision.

[jeffh]

I guess my posts were a little bit harsh. I'm very interested in seeing PyDaw succeed.
I think it's very good that someone does something else than to
reimplement Cubase. I wish Jeff all the luck and success he can get,
and so far he seems to do everything right. But throwing out jack would probably
be a mistake. Perhaps not a big mistake, but there's no reason to do so.
It's simpler to start jack from PyDaw directly (without the user noticing
that jack is being used), than programming Alsa. It was only meant as
a friendly advice, nothing more.

No worries brother... as I've told you before, I'm a fan of Radium as well. I appreciate the advice, and if ALSA proves to be more trouble than it's worth, then I won't follow through with it...

...but Jack is buggy, and the #1 problem child for a lot of people, while adding nothing of value for my use case. It fails to start, fails to stop, jackd has to be killed etc... which us Linux geeks know how to fix, but Windows users can't be bothered with...

[StudioDave]

Step 1: Appeal to the Deadmau5's and Skrillex's of the world
Step 2: Appeal to the Curt Cobain wannabe's
Step 3: Profit
Step 4: Appeal to Dave Phillips

Wisdom !

Indeed, I ought to be the last man on your list, wrt the intent of PyDAW, though it certainly has its appeal for certain compo modes I do like to explore. Great appeal, I should add. You are doing a great job, sir.

... I practice "Gall's Law", which states to first build a simple system that works, and then evolve it into a complex system... Today I mostly have a simple system that works, but all of those features skip a few important evolutionary steps...

Understood. I was just playing Dave Dreams Out Loud. You said you wanted to know about programs XYZ, there they are. And of course I know it's a little on the ridiculous side to suggest them as parts & parcel of PyDAW, but OTOH you mentioned Reaktor, which I think now provides a Lua language interface to the Reaktor API. (Correct me if I'm wrong about that.) That sort of thing appeals to musicians who want to move beyond the MIDI interface but probably can't/won't go whole hog to learn C/C++. And I agree with you re: coding music & sound in C/C++, but these days if I want to compose that close to code I'll opt for SuperCollider3 or Common Music for a composition environment, with instrument design in Csound. Btw, those systems are all natively language-based, their direct use is via code. SC3 is based on Smalltalk, Common Music is LISP-based. Csound is also from an older language model, but its internals are all written in well-tended C with some C++ (IIRC). Wrt instrument design, it is based on old-school modular synthesis with a completely flexible architecture (and a massive number of highly optimized audio/MIDI synthesis/processing opcodes). So if my synth blows up it won't be Csound's fault.

Direct support for time-sync'd 3D graphics and video, with parameter union a la AVSynthesis.

To be completely honest, I'm not so much into video editing, that would be one for PyDAW v15 due out in 2018, ie: once I've already conquered everything and there's nothing left to add, then we can talk about video

Entered into notes 050313, "jeffh willing to talk about video with release of PyDAW15, 2018, exact date unspecified".

JACK works abysmally with PyDAW

I think "abysmally" is kind of a strong word, it performs pretty well on my entire array of < 2y/o PCs

Yeh, you are right. The two desktop boxes here are beyond past due for rehabilitation, I'm taking your gear as a base list for replacements.

Btw, I've also been running the latest ISO image on the dual-core laptop, very nice performance there, given it's running from a USB stick. Most comfortable environment so far is the local build on Ubuntu 12.04 for i586, with KXStudio's overlay. Unfortunately the machine is max'd with 3G memory, not much for really stretching PyDAW (or much of anything else).

Okay, gotta get back to the review. We're looking at heavy weather for a couple days here, perfect for kicking it in the Caribbean with PyDAW.

Best,

dp