Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7520 discussions

Start a nNew thread

Re: [LAD] [LAU] So what do you think sucks about Linux audio ?

by josef.jurek＠gmail.com

Mr. Wang; please do not post HTML to the list. Thanks.

12 years, 10 months

Re: [LAD] [LAU] So what do you think sucks about Linux audio ? OP reply.

by Charles Z Henry

On Sun, Feb 10, 2013 at 3:56 PM, Alexandre Prokoudine < alexandre.prokoudine(a)gmail.com> wrote: > On Mon, Feb 11, 2013 at 1:52 AM, Charles Z Henry wrote: > > > I think that linux is much more well known and it's easier than ever to > get > > started. So--might I suggest to do something more for student outreach? > > What do you think would make a difference? > > Off-top of my head, try to get involved with Google Summer of Code. > > The graphics folks are traditionally well represented there: Blender, > GIMP, Krita, Inkscape, Scribus, OpenCV et al. Less so for video, and > even less for audio. > > Alexandre Prokoudine How about sponsoring good ol fashioned senior projects? Big and visible events like Google Summer of Code will be good for some students who want a summer project on their resumes, but there's a comparatively larger number of students who need to do a senior project every year. Likewise the art and music students need to create some kind of senior year portfolio or recital. I'm sure many of you in academics can (and do) encourage your students to work with Linux. We may not need funding like GSOC, just some way to get more recognition of using linux as a platform for academic projects. Chuck

12 years, 10 months

Re: [LAD] [LAU] So what do you think sucks about Linux audio ?

by Paul Davis

On Sun, Feb 10, 2013 at 5:05 PM, <gerald.mwangi(a)gmx.de> wrote: > Auto mode for JACK latency is a good idea. > I have another proposition: a dedicated graphical front-end for jack > session. It could help users setup their workflow , by providing a list of > all the jack aware programs installed, categorized by type (sampler, daw, > synth). The program should aid in setting up a project , eg firing up > ardour with several tracks, firing up synths (lv2 instruments/hosts incl) > with presets selectable from the front-end with a preview sound. The > front-end could trigger the synth in question with a midi note when > selecting a preset. Lv2 plugins, that is pure audio effects, could also > listed with the ability to directly send a signal from the audio interface > through the selected plugin to quickly hear what it does. One could then > associate the selected plugin with, say a track in ardour, and another > plugin with a track in hydrogen or so. > what you are describing is basically the "monolithic app" experience (from a user perspective) but created using a set of independent applications and processes. speaking personally, i think there are better things to do with our time.

12 years, 10 months

Re: [LAD] [LAU] So what do you think sucks about Linux audio ?

by Paul Davis

On Sun, Feb 10, 2013 at 5:48 PM, <gerald.mwangi(a)gmx.de> wrote: > Hi > > > > > -- Sent from my HP TouchPad > ------------------------------ > On 10.02.2013 23:30, Paul Davis <paul(a)linuxaudiosystems.com> wrote: > > > On Sun, Feb 10, 2013 at 5:05 PM, <gerald.mwangi(a)gmx.de> wrote: > >> Auto mode for JACK latency is a good idea. >> I have another proposition: a dedicated graphical front-end for jack >> session. It could help users setup their workflow , by providing a list of >> all the jack aware programs installed, categorized by type (sampler, daw, >> synth). The program should aid in setting up a project , eg firing up >> ardour with several tracks, firing up synths (lv2 instruments/hosts incl) >> with presets selectable from the front-end with a preview sound. The >> front-end could trigger the synth in question with a midi note when >> selecting a preset. Lv2 plugins, that is pure audio effects, could also >> listed with the ability to directly send a signal from the audio interface >> through the selected plugin to quickly hear what it does. One could then >> associate the selected plugin with, say a track in ardour, and another >> plugin with a track in hydrogen or so. >> > > what you are describing is basically the "monolithic app" experience (from > a user perspective) but created using a set of independent applications and > processes. > > speaking personally, i think there are better things to do with our time. > > > Well just for the initialization of the project. The diversity experience > of the multiple programs , ecosystem shall still be preserved > (1) your HTTP-only email confuses even gmail, and is probably inappropriate for a technically oriented mailing list like this one. (2) i'm not really that interested in preserving the "diversity experience". i think it is much more valuable for developers, who get to work on their own custom, standalone apps rather than being forced into a framework as happens with plugin developers. there are a LOT of "linux audio apps" that would be much more useful as plugins than they are as standalone JACK clients. but this is only helpful for users, and puts limitations on developers. look around you to see the result ....

12 years, 10 months

Re: [LAD] [LAU] So what do you think sucks about Linux audio ?

by gerald.mwangi＠gmx.de

12 years, 10 months

Re: [LAD] [LAU] So what do you think sucks about Linux audio ?

by gerald.mwangi＠gmx.de

12 years, 10 months

[LAU] So what do you think sucks about Linux audio ?

by Kjetil Matheussen

William Light: > it's interesting to me that free (source and/or beer) music software > on > OSX and windows has come further than it has on Linux. off the top of > my head: > > http://psycle.pastnotecut.org/portal.php > http://www.buzzmachines.com/ I'm very interested in knowing what you're missing from Psycle and Buzzmachines that Radium doesn't have...

12 years, 10 months

Fwd: [LAU] So what do you think sucks about Linux audio ?

by drew Roberts

Oops, mistakenly replied direct instead of to list. Forwarding. ---------- Forwarded message ---------- From: drew Roberts <zotzbro(a)gmail.com> Date: Sun, Feb 10, 2013 at 8:55 AM Subject: Re: [LAU] So what do you think sucks about Linux audio ? To: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> On Sun, Feb 10, 2013 at 8:37 AM, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote: > On Sun, 2013-02-10 at 12:17 +0100, Jörn Nettingsmeier wrote: >> On 02/10/2013 01:59 AM, gerald.mwangi(a)gmx.de wrote: >> snip > > Using Linux, keeping the workflow can become a PITA, just by updating > the DE ;), there are no updates for a 8 track analog recorder. So just buy an already setup, tested, and warranted computer from someone who knows what they are doing. Then, ***do not update it yourself*** - use it as is just like a dedicated piece of equipment. Down the road, get that same person who knows what they are doing to update it for you or build you a new one. I am not saying that these problems do not exist, and things can get better for those who don't mind knowing a bit. I am saying thought that for the person who does not want to know anything, they can avoid the knowing somewhat if they will take an approach along the lines mentioned. > > IMO the issue is "stand alone" vs "computer". > > Regards, > Ralf all the best, drew -- http://freemusicpush.blogspot.com/

12 years, 10 months

LV2 Synths & Hosts : MIDI binding

by Harry van Haaren

Hey all! I have a simple enough question, but I don't know the best practice for solving it, so figured I'd ask. There's an LV2 synth running in a LV2 host. The synth exposes its operation trough control ports. Option 1: The plugin can bind incoming MIDI events to these control ports values, allowing "standard" MIDI maps to be made for the synth. Use cases include using the synth on another machine with the same hardware: easy operation, layout identical to before. Downside: these MIDI binding values are hard coded in the plugin, and can't be changed. Also the host may update the control port (which has been effected by the MIDI stream) and causes a parameter jump. Option 2: The host has to implement its own form of binding the MIDI events to the control ports. Downsides: the plugin has no control over what causes what effect, so no standardized maps can be made. Application specific MIDI mapping... which is nasty. I think the "safe option" is number 2, each application sorts this thing out itself, and the user has to map the same synth per host. The MIDI mapping situation on Windows and MacOS is terrible (IMO), with various different "software re-map" features like Novation Automap, and Bores midi translator just getting in the way even more. Can anybody see a solution to using the same MIDI map for the same instrument in different software, without hard-coding it in the plugin? Or another solution? -Harry

12 years, 10 months

Re: [LAD] [LAU] jackdbus eating 100% cpu after a while

by Florian Paul Schmidt

Hi James, On 02/09/2013 01:11 PM, James Stone wrote: > Hi Flo, I am also running Ubuntu 12.10 and using jackdbus. It is > really nice for things like playing along to youtube videos.. On my > computer, I noticed that jack does have a tendency to lockup after a > while when jackdbus is running. I had the feeling that it might be > something to do with latency, as I found it is impossible to start > jack at very low latencies with jackdbus running. I was using 128 > samples which seemed to be OK, but at that latency, the lockups > occurred after some time. I tried increasing latency to 256 > samples/44.1k. Following this, it seems to operate fine (at least I > have had no more dropouts), but it is all a bit fiddly to get it to > work properly, and I would probably disable pulse if I wanted to do > serious recording etc without the mixing capabilities that jackdbus > adds.. James I use very large period sizes, 1024 or even 2048. The problem of jackd starting to eat 100% cpu occurs usually when I'm done with my current work (recording something or fiddling around) and just leave it running idly. Then when I return to my computer after a few hours jackd sits there happily eating cpu. It has the side effect of heating my room, but heating with electricity is expensive and thus I'd rather avoid it ;D Have fun, Flo -- Florian Paul Schmidt http://fps.io

12 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev