Linux-audio-dev February 2013

linux-audio-dev@lists.linuxaudio.org

75 participants
47 discussions

Deciphering jack-smf-utils -- Jack MIDI stuff

by M Donalies

I haven't really looked at the recorder program, but the player is pretty cool. To make it easier for me to understand, I simplified the code somewhat (got rid of lash stuff, reduced output to a single port, etc) so my code excerpts below don't match up exactly with the original code. The first question is a rather stupid one: How long is a Jack frame? If we're running at 44.1 kHz, is a frame 1/44100 sec? Or is it some multiple? Or is it something else? And does the process callback get called at each frame while transport is rolling? process_callback() calls process_midi_output(), wherein we find: port_buffer = jack_port_get_buffer(output_port, nframes); Why the nframes parameter? Is there a separate buffer area for each frame? A little later in the same function we have: last_frame_time = jack_last_frame_time(jack_client); Is this the time of the end of the last process cycle? -- 7:8

12 years, 1 month

making sense of Jack MIDI; or, is this an appropriate use for Jack?

by M Donalies

From what I can tell, the Jack midi interface aspires to hide the underlying Alsa api so an app developer can just use Jack midi and not have to muck with Asla. If this is true, then how do I use Jack in the following senerio: I'm writing a toy gui SMF player that outputs midi events so a program like fluidsynth can play them. Using Alsa sequencer, I put events on a queue with a time and Alsa takes care of the rest. If I just use the Jack midi api, how much of this process can Jack do? I'm assuming "not much," since all the apps that I've looked at the source of use the Alsa sequencer. If I wanted to do the sequencing myself, what would be involved? Or am I completely missing the point of what Jack can do? -- 7:8

12 years, 1 month

Presonus 1818 VSL Was: Re: So what do you think sucks about Linux audio ?

by Felix Homann

Hi Paul, 2013/2/5 Paul Davis <paul(a)linuxaudiosystems.com> > > > so how does this look? > > http://ardour.org/files/aspecs.png > > this looks very comprehensible indeed. You're recommending the Presonus 1818VSL device which looks very interesting. How about the advertised effects like "reverb and delay effects and [...] compression, limiting, semi-parametric EQ, and high-pass filter". Are they done in hardware and accessable from Alsa or are these pure software effects not usable in Linux? Regards, Felix

12 years, 1 month

C/gtk3/cairo meter widget

by Patrick Shirkey

Hi, Before I spend any time to rewrite the gtkmeter.c/h widget for JAMin to gtk3/cairo does anyone have one already finished? Needs to be in C. -- Patrick Shirkey Boost Hardware Ltd

12 years, 1 month

Linux audio articles in LWN

by Dave Phillips

Greetings, Just a pointer to articles I've written to date for the Linux Weekly News. Their policy is to reserve initial viewing for subscribers only, but afterwards the articles are publicly accessible. So, for the interested among ye : A Brief Survey Of Linux Audio Session Managers (January 2013) http://lwn.net/Articles/533594/ The Synthesizers Of Sean Bolton (December 2012) http://lwn.net/Articles/527556/ 21st Century Csound (November 2012) http://lwn.net/Articles/523166/ A Tale Of Two Sequencers [harmonySeq and Softwerk] (October 2012) http://lwn.net/Articles/520348/ Keeping Up With Kdenlive (September 2012) http://lwn.net/Articles/516016/ The Linux Audio Workstation, parts 1 & 2 (August 2012) http://lwn.net/Articles/509958/ http://lwn.net/Articles/510046/ A Survey Of Linux Audio Plugins (June 2012) http://lwn.net/Articles/502183/ A Report From LAC2012 (May 2012) http://lwn.net/Articles/495612/ Interesting to note how quickly things evolve in the Linux world. Stuff I wrote only a few months ago is already outdated by development trends. Keep up the good work, devs ! Anyway, enjoy, and your comments are welcome. Best, dp

12 years, 1 month

So what do you think sucks about Linux audio ?

by Dave Phillips

Greetings, I've been reading a lot of negative (read: vitriolic) commentary about the world of Linux audio development and applications. I won't bother to say where, just "the usual places" will have to suffice. Of greater interest to me is the commentary itself - it seems to boil down to the following plaints and lamentations (in no particular order) : Too many distros. Too many audio-optimized distros. Not enough native plugins, esp. instruments. Inconsistent support for VST/VSTi plugins. Too many unstable/unfinished applications. Too many "standards" (esp. wrt plugins). Poor external/internal session management. Poor support for certain modes of composition (think Ableton Live). Lack of support for contemporary hardware. Confusion re: desktops, and GUI toolkits. Too difficult to set up audio system. JACK is a pain. Too much conflict/fragmentation within the development community. I'm not so interested in comments on the commentary, I have my own, but say what you will about the list. I figure that most denizens of these lists already have ready replies and responses to these and other criticisms, many of which have been voiced here previously. What I'm more interested in is what *you* think is missing most or just plain wrong about the situation. Please, try to speak your piece without flames or dissing other developers and/or their work. Frankly speaking, I've had enough of that crap, and I'm most thankful these days for such forum amenities as "mute user" and autodiscard, along with the standard filters found in mail clients. <aside> I'm reminded of John Cage's comments regarding the behavior of the NY Philharmonic when they destroyed his equipment during the premire of Atlas Eclipticalis, something to the effect that his concerns had ceased to be musical and had become social, i.e. that he had to figure a way to allow people to be free yet behave themselves with respect towards the common goal (e.g. Cage's music and property). I'm going to guess that he was still working on that up to his death. </aside> So, in your honest and bold opinion as user and/or developer, what do we lack most and what can we do without that we already have ? Please feel free to expand your remarks as you like. I'm planning an article on the topic and will likely use selected comments, subject to approval of course. Best, dp

12 years, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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 February 2013