Linux...anybody using it?

Audio Plugin Hosts and other audio software applications discussion
Post Reply New Topic
RELATED
PRODUCTS

Post

urlwolf wrote:Jeff, just to understand what you are aiming for with pydaw... You mention you wanted to get away from reaper et al.

Could you list the points you hate, and how you want to solve them?

I'm asking because now I need to decide if I want to make an investment in reaper (it works well)...
I don't have problems using wineasio, reaper, and windows vsts.
Typically I will select some instruments, perhaps U-he TyrellN6,
Native Instruments Razor, ArtVeras Wusik based Drumatoxin,
with a diversity of sounds, and use a sequencer or arps,
or both, to drive the sounds, and add melodic tracks and ambient fills
as desired, later. And Yoshimi, Hydrogen, Hexter, Whysynth,
can run paralell to Reaper, with Rakarrack, and Calf Plugins as fx
destinations for any L or R output.

One can also look at Reaper for it's impact on the market.
Most every DAW for windows has free or limited versions now.
The hobbyist, and day-job musician can test the full Reaper extensively,
and buy a $60 license that covers a sizeable time span. And they keep
older versions available, so you can go back to a working release,
should a bump in the road occur specific to you. I've had two bumps,
or so I thought, in five years, cost me about twenty minutes...
then later discovered both were based on user laziness/ignorance :-o
(yes the Reaper pdf now has a place in my Solar System :hihi: )

The plugin bundle that reaper provides, is worth the $60,
so you can consider the rest a free factory bonus. :wink:

So all the Reaper doom and gloom has a break in the clouds.
Use what works, what you like, what suits achieving your goals,
and keep the tunes coming :)

I hope all the DAWs get better and better and better 8)

Post

urlwolf wrote:Ok, something that could be trouble...
On the io|2, Midi out light is never blinking, the manual says it should blink.
The midi in light is red.
Jeff, could you check yours?
Look in qjackctl Setup page, Periods/buffer needs a 3
for usb gear, a 2 for pci

If it is already 3,

Try booting without the alesis, and without other usb devices.
Then plug in the alesis. run command

arecord -l

you'll see something like this, but with your alesis listed,
(not my m-Audio), within the brackets

**** List of CAPTURE Hardware Devices ****
card 0: M2496 [M Audio Audiophile 24/96], device 0: ICE1712 multi [ICE1712 multi]
Subdevices: 0/1
Subdevice #0: subdevice #0

back at qjackctl setup page, on the right, where you see

Input Device >
Output Device >

click the ^ and > widgets to see if your alesis
is shown, should be like the content inside the brackets on your
command output.
Fill it in, in qjackctl, if it is not there, and restart qjackctl

Cables:
Midi out goes to midi in
Midi in goes to midi out
I label mine with pretty colored tape :lol:

When usb cables get switched around, the ID may get lost, but just check
the above location. For guitarist/keyborders using different interfaces,
that option is a feature. 8)

aplay -l will show your audio outputs

cat /proc/asound/cards

should list soundcards/chips your linux kernel sees,
similar to the aplay command output
Cheers

Post

jeffh wrote:
In Linux? Under WINE? Are you sure about that, or was that a first impression?

EDIT: I think the Reaper forums explain it well:

http://forum.cockos.com/showthread.php?t=117332
It probably isn't wise to base any judgements about Reaper/Linux issues on user discussion. As with any forum, some people are fools. Also consider that 99% of comments there are from Windows only users, and they don't want the devs using up time that could be used for feature requests on Linux porting and Linux support. Yes, They're fools.

Justin actually offered a bounty for anyone interested in porting Reaper to Linux. Also, I remember at some point he said that he wouldn't mind going open source, if there were a business model to work from that made sense. I think that Cockos isn't against the idea of porting to Linux, but being a three man dev team, they likely don't have the manpower to spare for it.

As for the other things that you said, some of it is valid opinion, but wrong. :D

Post

urlwolf wrote:ok. Now it launches...
Well, we even have the same interface.

I have selected io|2 MIDI 1. I have ray V on a track, and it's armed. What else could be wrong?

A litle 'led' showing that midi is getting in wouldn't hurt.

What is the easiest way to test midi on linux? Equiv. of midiox?
You can verify that the device is connected to PyDAW by opening QJackCtl, clicking the "Connect" button, looking at the ALSA tab and looking for a connection (The "MIDI" tab is actually referring to Jack MIDI, which most apps don't use). If in fact there is a connection to PyDAW, and you have a track record armed, then there's no reason why it shouldn't work unless the notes aren't being sent..

I'll see what I can do about a notification light, but that one may be a bit tricky... I need that and channel metering eventually anyways....
urlwolf wrote:Ok, something that could be trouble...
On the io|2, Midi out light is never blinking, the manual says it should blink.
The midi in light is red.
Jeff, could you check yours?
Like I said, all of my MIDI controllers are USB-only, so I don't have anything I could plug in there to try it (it seems nothing new comes with a MIDI port anymore)... I'm pretty sure that if it was working, the light should be green like the other lights and not red, that kind of makes me think that it's actually something going wrong with the interface, controller, or cable...

Post

sellyoursoul wrote:
jeffh wrote:
In Linux? Under WINE? Are you sure about that, or was that a first impression?

EDIT: I think the Reaper forums explain it well:

http://forum.cockos.com/showthread.php?t=117332
It probably isn't wise to base any judgements about Reaper/Linux issues on user discussion. As with any forum, some people are fools. Also consider that 99% of comments there are from Windows only users, and they don't want the devs using up time that could be used for feature requests on Linux porting and Linux support. Yes, They're fools.

Justin actually offered a bounty for anyone interested in porting Reaper to Linux. Also, I remember at some point he said that he wouldn't mind going open source, if there were a business model to work from that made sense. I think that Cockos isn't against the idea of porting to Linux, but being a three man dev team, they likely don't have the manpower to spare for it.

As for the other things that you said, some of it is valid opinion, but wrong. :D
Eh... but I'm a Tier-1 Elite Linux Genius of Excellence(tm), and I am saying that I **personally** found the experience not to be worth the hassle... and many of those people are reporting that Reaper has unstable audio and dropouts under relatively light load under WINE, which was also my experience, so I can totally back up their claims as a subject matter expert.

The native Linux port they're working on is going to be a fail. They're attempting to wrap a bunch of Windows system calls into Linux system calls rather than doing a proper port, so they are essentially writing their own version of WINE. Several developers already tried and failed to make any significant progress in years now(you can read about it on the forums), and Justin won't work on it himself either because he doesn't care, and/or because the anti-Linux mob on there demands that he not work on anything that doesn't directly benefit them...

Justin is a talented developer for sure, but frankly anybody else talented enough to finish the job probably doesn't need his money and almost certainly wouldn't want to spend that much time furthering somebody else's proprietary application for the prospect of **maybe** getting paid (or maybe not).

Post

jeffh wrote:
sellyoursoul wrote:
jeffh wrote:
In Linux? Under WINE? Are you sure about that, or was that a first impression?

EDIT: I think the Reaper forums explain it well:

http://forum.cockos.com/showthread.php?t=117332
It probably isn't wise to base any judgements about Reaper/Linux issues on user discussion. As with any forum, some people are fools. Also consider that 99% of comments there are from Windows only users, and they don't want the devs using up time that could be used for feature requests on Linux porting and Linux support. Yes, They're fools.

Justin actually offered a bounty for anyone interested in porting Reaper to Linux. Also, I remember at some point he said that he wouldn't mind going open source, if there were a business model to work from that made sense. I think that Cockos isn't against the idea of porting to Linux, but being a three man dev team, they likely don't have the manpower to spare for it.

As for the other things that you said, some of it is valid opinion, but wrong. :D
Eh... but I'm a Tier-1 Elite Linux Genius of Excellence(tm), and I am saying that I **personally** found the experience not to be worth the hassle... and many of those people are reporting that Reaper has unstable audio and dropouts under relatively light load under WINE, which was also my experience, so I can totally back up their claims as a subject matter expert.

The native Linux port they're working on is going to be a fail. They're attempting to wrap a bunch of Windows system calls into Linux system calls rather than doing a proper port, so they are essentially writing their own version of WINE. Several developers already tried and failed to make any significant progress in years now(you can read about it on the forums), and Justin won't work on it himself either because he doesn't care, and/or because the anti-Linux mob on there demands that he not work on anything that doesn't directly benefit them...

Justin is a talented developer for sure, but frankly anybody else talented enough to finish the job probably doesn't need his money and almost certainly wouldn't want to spend that much time furthering somebody else's proprietary application for the prospect of **maybe** getting paid (or maybe not).
I guess only time will tell on whether the port (or port workaround) will be successful. I'm not a Tier-1 Elite Linux Genius of Excellence, so I can't comment on the feasibility of Reaper working properly under Linux. I tried Reaper (and other audio applications) under Wine, and it was a pretty miserable experience all around compared to running any of those applications in Windows. I'm waiting patiently for a solid daw, with plugins that I need, to make it's way to Linux, and I'm hoping that Reaper fares the trip well. Current Windows based daws and plugins have set the bar pretty high for it to be a trivial thing.

I'm glad to see Pydaw and other audio applications come up in Linux, but nothing fits my needs yet. I'm a guitar player first, and a piddler of all other things including electronic, second.

Post

I hear you, the only reason I started writing PyDAW is because I got fed up with waiting for Reaper and Bitwig to bring the proper Windows DAW experience to Linux... I first considered the idea of throwing my hat into the Linux audio ring about a year before I actually did it... and only because Justin was saying that he "might" open source Reaper or at least port it...

I started writing my plugins a little over a year ago, and PyDAW just over 6 months ago... Considering that it's a one-man operation, and that I work full-time and write Linux audio software in my spare time, I think PyDAW compares favourably to Reaper at 6 months into development, and probably any other DAW really... but of course it's going to take some time to conjure up such an experience from scratch, ask the folks at Bitwig :lol:

Post

You might like the Fender Mustang usb modelling amps, which
work fine in linux, easy to use, great sound, and
V1 models should become bargains, as the V2 models are hitting the shops
Smallest model, Mustang 1, used at $50 should be common



for reaper in linux, an older wine, V1.4 or older, wineasio,
older nvidia graphics, and m-audio pci soundcard, are goodest luck.
Can be had cheap if you watch the sales, ebay, craigs etc
Cheers

Post

jeffh wrote:I hear you, the only reason I started writing PyDAW is because I got fed up with waiting for Reaper and Bitwig to bring the proper Windows DAW experience to Linux... I first considered the idea of throwing my hat into the Linux audio ring about a year before I actually did it... and only because Justin was saying that he "might" open source Reaper or at least port it...

I started writing my plugins a little over a year ago, and PyDAW just over 6 months ago... Considering that it's a one-man operation, and that I work full-time and write Linux audio software in my spare time, I think PyDAW compares favourably to Reaper at 6 months into development, and probably any other DAW really... but of course it's going to take some time to conjure up such an experience from scratch, ask the folks at Bitwig :lol:
Yea, Bigwig jumped the gun a bit (read: shitload) on the announcements, didn't they?

Mucho applause for taking things into your own hands. I have to admire that, and I wish you luck. Yea, I remember early Reaper versions. It took a while for things to start to get intersting. I finally jumped on at v2. Just curious, what were you developing before you began with audio? I'm just getting into programming myself, and if I make it that far, the stuff that I want to develop will be for Linux.
Last edited by sellyoursoul on Wed Mar 20, 2013 1:16 pm, edited 1 time in total.

Post

Whoops, where is the delete function?

Post

I actually began developing on Windows a little over 10 years ago, and I took the much harder route of beginning as a DSP/audio developer... Audio development is much harder than regular development because there's strong aspects of math and science involved (much more so than ie: web development), and it's much harder to debug than a normal application which will be more straight-forward...

If you do decide to start developing audio and especially if in C/C++, just understand that it's going to take a long time to get good at it, probably years... I've seen people get discouraged before, but nobody has ever mastered it without a lot of hard work and perseverance...

Post

jeffh wrote:I actually began developing on Windows a little over 10 years ago, and I took the much harder route of beginning as a DSP/audio developer... Audio development is much harder than regular development because there's strong aspects of math and science involved (much more so than ie: web development), and it's much harder to debug than a normal application which will be more straight-forward...

If you do decide to start developing audio and especially if in C/C++, just understand that it's going to take a long time to get good at it, probably years... I've seen people get discouraged before, but nobody has ever mastered it without a lot of hard work and perseverance...
I'm mostly interested in general programming, but I'm sure that I will want to at least tinker with some audio stuff somewhere down the line. Any way, I have a long way to go before thinking about any of that. I worked through some beginner C materials before coming across some good books that use C++, which is what I'm working on now, learning general programming concepts. I know that I have a long way to go before doing anything too exciting, but the learning process has been very interesting up to this point. I guess that's all that I can ask for.

Post

jeffh wrote:
codec_spurt wrote:Does not like having the length changed of the loop at all when it is playing. Crashed and disappeared as before. Had to kill the process to get rid of it.
You mean like going from loop_mode::region to loop_mode::bar ? That's really odd if that's what you meant, I do that all the time and have never seen a crash...
Yes, the input region in the upper right hand side where you can switch between region and bar. The one that has the arrows in the input field to increment and decrement the number of bars. This was the only thing that made it consistently hang or disappear. But it was ok when the seq was stopped. Btw, it would be good to include in the documentation that there is a minimum of 4 bars and a maximum of 16 - some people (like me) might think things are not working properly when they can not input values outside of these bounds.

And talking of 'bounds'. Back to the whole starting at '0' thing. This IS confusing. I can understand why as a programmer this comes naturally to you, but I just want to say (one last time), most of your users will not have the programmer's mindset and get confused when they see '15' in the timeline when they are really on bar '16'. It confused me anyway, even after programming arrays myself. Different mindset.


As to the instability...

Bear in mind I had to re-install and was loathe to run update manager and update the kernel again. Though as I mentioned the Catalyst drivers installed perfectly. On the whole though it was more stable and I really punished it with routing fx and changing parameters like a madman. I wouldn't call it unstable, hopefully the problem I've been having with changing values for the regions is not some kind of heisenbug. :) I don't know. Maybe it's just my setup.


jeffh wrote: If you don't mind, could you please try launching PyDAW from the terminal by typing "pydaw2" (without quotes) and hitting enter to launch it instead of clicking the launcher button? If there is a crash, it should print something to the terminal that can help me figure out what's going wrong...
No problem. I will try that next time I run it.


jeffh wrote:
codec_spurt wrote:Lots of other niggles. The audio arrange page was showing stuff differently and a reboot of the program was always necessary for it to update. Crashed a couple of times more, but not too bad considering I gave it a pretty thorough work out. Whenever it would start misbehaving I would just re-start the program.
I should mention that if something is changed on the "audio edit" tab, you have to click the "save changes" button for it to take effect... (not optimal, I know, I'll eventually get a better way to do it, young software, etc... blah, blah, blah...)... If that's not what you meant, is there a simple way to reproduce the problem? It had an issue with that once, but I thought it was fixed, or at least I can no longer reproduce it...
Yes, I figured that out. Not such a problem for 'young software'.
No, I don't know what was happening before, but this is what I meant:
When you would add new audio tracks, the region markers would change and were nonsensical to me at least. When I closed and reloaded PyDaw2 then they corresponded correctly to the regions/bars. I am talking specifially about the Audio Seq page and the timeline at the top that changes depending how many bars you have in your region.

If that makes sense. Sorry, like I said, I should have made notes and took screenshots, but I got so into making the music that I just ploughed on with that. You can take that as a compliment, btw. :)


jeffh wrote:
codec_spurt wrote:Here is a little 2 minute demo done entirely from scratch this afternoon.
As stated 2 posts ago... Nice :)
Thanks. In fact I liked it so much, I put it up in the cafe. I really like the rawness and grittiness you can get with the synths and fx. And I mean that in a good way. So much just sounds right out of the box. It took me no time at all to figure out the routing and soon I was mixing like a champ. Lot of fun.


jeffh wrote:
codec_spurt wrote:If I had had something like this as a sample or template project file, it really would have helped me immensely to get my head around how this program works.
The reason there isn't is because projects aren't 100% portable between 2 PCs... The sequencing and synth patches transfer fine, but audio samples in the sequencer or in Euphoria won't be found unless they exist on the destination PC in the same location...

Most DAWs have this same shortcoming, but I actually do intend to make projects completely portable sometime soon by caching all of the files in the project dir... One of the many advantages of having complete control over my ecosystem...
I understand. But the same effect could be achieved by just dropping the included drum loop wave and cutting the track in half. It would suit exactly the same purpose. Even if you just included a kind of template track with four on the floor midi tracks and two or three regions. It really makes a lot of sense once you figure it out and it is very fast to work with. But figuring it out was the hard part for me.

Of course, it would be ideal if you could make it portable as well, but there's plenty of time for all that!



cheers.

Post

codec_spurt wrote: The one that has the arrows in the input field to increment and decrement the number of bars. This was the only thing that made it consistently hang or disappear. But it was ok when the seq was stopped.



Oh........................

Actually, that's pretty much just an indicator of the current playback position, not a setting for how many bars to loop...

Crap, that wasn't meant to be changed during playback, it probably is crashing because of it, my bad... Currently the only loop settings are Region, Bar and None, but I will eventually have more granularity to it (young software, excuses, excuses, blah, blah :D)...

But I will at least fix it so that it won't allow changes during playback, because obviously there should never be a way that users can crash the application...
codec_spurt wrote: Btw, it would be good to include in the documentation that there is a minimum of 4 bars and a maximum of 16 - some people (like me) might think things are not working properly when they can not input values outside of these bounds.
Just out of curiosity, what values did you want to set it to, and why? I can change the allowable range, I just didn't think that anybody would want one smaller than 4 or bigger than 16....
codec_spurt wrote:And talking of 'bounds'. Back to the whole starting at '0' thing. This IS confusing. I can understand why as a programmer this comes naturally to you, but I just want to say (one last time), most of your users will not have the programmer's mindset and get confused when they see '15' in the timeline when they are really on bar '16'. It confused me anyway, even after programming arrays myself. Different mindset.
Yeah, that's actually a remnant of the interaction between the programming side of the house, how the data is stored and so on... Programming wise it's not feasible to make it one-based instead of zero-based, but I can make the various tools and timelines one-based, but I haven't done it yet just because it's HUGE undertaking and I've had bigger fish to fry...

But I do see your point...
codec_spurt wrote:hopefully the problem I've been having with changing values for the regions is not some kind of heisenbug. :) I don't know. Maybe it's just my setup.
That's probably something I can fix relatively quickly... I never found that bug because I already knew it didn't work that way, so I never tried... but I do appreciate you finding it, and I vow to have a quick fix for it....

codec_spurt wrote:Yes, I figured that out. Not such a problem for 'young software'.
No, I don't know what was happening before, but this is what I meant:
When you would add new audio tracks, the region markers would change and were nonsensical to me at least. When I closed and reloaded PyDaw2 then they corresponded correctly to the regions/bars. I am talking specifially about the Audio Seq page and the timeline at the top that changes depending how many bars you have in your region.

If that makes sense. Sorry, like I said, I should have made notes and took screenshots, but I got so into making the music that I just ploughed on with that. You can take that as a compliment, btw. :)
Screenshots please, I think we're probably not experiencing the same thing :)


codec_spurt wrote:Thanks. In fact I liked it so much, I put it up in the cafe. I really like the rawness and grittiness you can get with the synths and fx. And I mean that in a good way. So much just sounds right out of the box. It took me no time at all to figure out the routing and soon I was mixing like a champ. Lot of fun.
I'm glad you liked it :)

That's really what I'm going for, software that more accurately reproduces the hardware workflow and sound... You know, like not spending a whole day setting up your project, just picking it up and playing with it... and the hardware "instant sound quality", ie: relatively few knobs, but every combination of knob positions sounds good, rather than the software mentality of "a knob for anything and everything, let the user find the 0.01% of knob position combinations that sound good....

codec_spurt wrote:Of course, it would be ideal if you could make it portable as well, but there's plenty of time for all that!
Yeah, it's definitely a priority to have those kind of things, we'll get there soon enough... ;)

Post

Alsa midi connected to pydaw, still no midi nor lights.
I bought the io2 mostly to get midi. I'm sure it works on win, too lazy to try now...

Maybe time to buy a USB master keyboard?

Here's another reason to disregard linux for audio. On the linuxmusicians forums and wiki, it clearly says "Buy the io2, by all that is holy! this one works on linux." Yeah, right. Maybe it did at some point in time, for some user who didn't need midi.

I admire what you are doing Jeff, and I'll keep fighting till I can record a track on pydaw, but things are not looking good. I've been on linux for years, and this is difficult for me. A windows user will have started trashing things in forums about 2 weeks ago...

Post Reply

Return to “Hosts & Applications (Sequencers, DAWs, Audio Editors, etc.)”