Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

[linux-audio-dev] [ANN] Specimen 0.3.0 released

by Pete Bessman

The latest release of Specimen, a midi controllable audio sampler for Linux, adds 4 LFOs which can modulate volume, panning, cutoff and resonance into mix. Additionally, the LFOs can be tempo synced to either midi or the jack-transport mechanism. Available for immediate leeching from www.gazuga.net, or you can download the tarball directly here: http://www.gazuga.net/specimen-0.3.0.tar.gz I'm working on a roadmap for Specimen, and I'm interested in hearing what features people are most interested in having. If there's something you want Specimen to do, let me know; the most popular features will get incorporated first. [pb]

21 years, 4 months

[linux-audio-dev] Sliders

by Thorsten Wilms

Hello again! The discussion about linear or radial mouse movement for knobs finaly got me to mockup an idea i had in my mind for sometime already. For now I call it fan sliders: http://wrstud.urz.uni-wuppertal.de/~ka0394/forum/04-06-10_fan_slider_01.png It's all about concept, not style. The idea is to allow rather small sliders, but on mouse-down lines from top and button appear on one side (important for making the feature discoverable). Outside of the inital slider the pointer position is indicated by the crossing middle and vertical line. The straight horizontal extension is only meant to make reading easier. So up/down is value change, outwards increases precision (can of course be turned for stuff like pan). If the graphics do not fit on the screen, it still can work because the value is indicated by the initial slider and inclination of the center line (well, at least I hope so). Default expansion direction should be reading direction, but moving the pointer out on the other side could make it turn over. Close to the right screen edge the behaviour could be as known from menus. The first mockup has a slider where the dragable part is clearly defined. The second gives a stronger sense of value, but is not clear about where to click (I propose everywhere on the slider area, always grabbing the actual value. No special behaviour like known from scrollbars). It's also more space efficient, because the whole are can be used (with the other one a half button must be spared on both ends each.) For those concerned about precision of pointer movement / inadvertently changes to precision while adjusting value: Instead of linear spreading out, it could be stepped (lines looking like stairs). But that would be much less elegant. Comments, please! --- Thorsten Wilms

21 years, 4 months

[linux-audio-dev] Re: Knobs / widget design

by Juhana Sadeharju

Are you all on vacation because we have 60 mails per day? Horizontal motion is better than vertical. Try it! I can move the pointer horizontally 1000 pixels easily without moving my hand -- I just rotate hand and skew fingers, fast. For vertical motion I have to slide the whole arm on the table -- feels bad and is slow. Juhana

21 years, 4 months

Re: [linux-audio-dev] [OT] marketing hype

by Kjetil Svalastog Matheussen

Alfons Adriaensen: >On Thu, Jun 10, 2004 at 07:24:59PM +0200, Kjetil Svalastog Matheussen wrote: >> >> Tim Hockin: >> > >> > I know Linux people love to claim how choice is our strength, but I think >> > it's bunk. Linux needs a single GUI environment that has a lot of deep >> > flexibility >> >> Yes! I completely agree with this. > >What exactly do you mean by Linux "needing" something ? > >And how are you going to impose that single GUI environment ? >Will you take me to court when I write a new window manager. or >a widget that doesn't have your 'imprimatur' ? > >If you want your freedom to program limited, please goto >Windoze or MAC. But please do no impose your limitations on >others. Ouch, never be sarcastic/ironic on e-mail. I completely agree with you. I though that was clear by my "Oh..." comment which you had cut away. The point was: _i_ actually want to customize everything via scheme-scripts (that is true), which Tim Hockin made (some kind of) a joke about. And by saying that I tried to express that what Tim Hockin perhaps means is ridiculous, does perfectly makes sense for other. We need to have choises/alternatives/anarchy/etc. because we are all different, etc. --

21 years, 4 months

Re: [linux-audio-dev] [OT] marketing hype

by Kjetil Svalastog Matheussen

Tim Hockin: > > I know Linux people love to claim how choice is our strength, but I think > it's bunk. Linux needs a single GUI environment that has a lot of deep > flexibility Yes! I completely agree with this. > (and I don't mean Scheme config files :) Oh... :) --

21 years, 4 months

[linux-audio-dev] Re: linux use (was [OT] marketing hype)

by gml＠xs4all.nl

> Date: Fri, 11 Jun 2004 13:21:05 +0200 > From: Tim Orford <tim(a)orford.org> > > the major weakness in this setup for me is the neccesity to render the > midi before mixing. At least that means all elements of the arrangement > can be visualised and edited in one place, but re-editing the rendered > parts is problematic. ....snip > i wonder if this is a concern to anyone else? I see your point. The difference is that I only use MIDI instruments for certain specific things, where I write the parts on the piano and/or paper enter them in the computer and make a few small edits. But with a specific instrument that I like and don't have to tweak. Whereas the effects and mixes and montages I all do with raw audio. So I never missed the kind of global sessioning because I don't use MIDI that way. > > Despite your comment about the 'mega-application', both Rosegarden and > Ardour aim to be such things, but dont, at the current time, appear to > do anything that the 2 apps you mentioned cant. besides interconnecting with about all other linux audio apps. Which was my point. I have nothing against applications that can do a lot, but I don't like applications that are islands. cheers Gerard

21 years, 4 months

[linux-audio-dev] Ultramaster Juno6, anyone?

by Frank NEUMANN

Hi all, some might remember that two years ago (or so) there was a nice (though at that time closed-source, I think) software synth for Linux called Ultramaster Juno 6, a faith reproduction of the Roland Juno 6. At some point this project disappeared from the websites. When I talked to Marek Peteraj earlier this year, he mentioned to me that he attempts to convince the developers to release it to the public. And right now, while "proofreading" Ico's paper for the next ICMC I found that it has been open-sourced this year and is now available here: http://sf.net/projects/juno6 That's the old source code from 2000, and people have started converting it into a VST instrument recently. I just wonder if anyone has already begun with attempts to e.g. jackify it or otherwise fixing it up for e.g. ALSA Midi input etc. Looks like a very nice small to medium-sized project.. Greetings, Frank PS: If this has been brought up here before - sorry.

21 years, 4 months

[linux-audio-dev] Is ladspa actually la-dsp-a? Is JACK the ultimate solution?

by Marek Peteraj

Lately, while looking at screenshots of a few VST(i) plugins, i began to wonder what makes them different from LADSPA plugins. Not technically, but from the philosophical point of view. VST plugins tend to be rather complex, offering tons of features and eyecandish GUIs, while LADSPAs usually offer limited functionality, no GUI at all(hosts usually provide simple ones to control the parameters). But what's interesting is that each LADSPA plugin usually implements exactly one type of DSP technique, for example, an oscillator, or a delay. This basically leads to a situation where a certain DSP technique is 'isolated' in a separate plugin. Now if we look at an arbitrary VST plugin we'll see that it's fairly complex, and that there's a large amount of creativity involved both visually and featurewise. But if you look at it closer, you'll recognize that each such plugin is actually a bunch of DSP techniques put together in a creative way. Let's look at JAMin. What makes JAMin interesting is that it's basically(although probably not entirely, haven't looked at the code) a collection of LADSPA plugins where each of those plugins implements a DSP technique dedicated to improve the characteristics of a sound in a certain way. So JAMin tends to "package" these DSP techniques into a standalone JACK effect client. Now imagine you'd replace the gtk+ based GUI with a 3d eyecandish GUI. What would you get? A typical audiomastering VST plugin. Except - it's a JACK client. So LADSPA becomes LA-DSP-A and each such plugin becomes a basic building block for a complex JACK effect or synth. The benefits i see: 1. It unifies the way audio is routed from/to/through daws, effects, synths and other audio applications. The VST(i) vs. Rewire situation becomes one - JACK. 2. If offers unlimited flexibility (together with MIDI over JACK) - for example controlling a synth with a DAW via a midi track while letting the DAW record the output of the synth. 3. It simplifies the notion of handling effects, synths etc in hosts for the users. No need for insert vs. send. 4. No need for a GUI standard. Simply write your own Gtk+/Qt frontend whether widget or pixmap based. 5. Allows developers to design complex 'plugins' i.e. JACK effect/synth clients and be creative in picking DSP algorithms and wiring them together *even* if they don't have any background in DSP programming. 6. Allows DSP developers to fully concentrate on the DSP part, only developing the desired DSP technique without caring about the rest. 7. Points 5. and 6. help to accelerate development of complex and high quality effects and synths that we all miss and the win32 and macosx users already have. 8. It would unify the LinuxAudio scene in terms of DSP code - DSP = LADSPA. Political issues: 1. we'd need to centralize the LADSPA scene on the web, using the www.ladspa.org site, building a unified ladspa directory, each entry would describe the plugin(category, author, decription, purpose) 2. the centralised site should make some general suggestions on how to build complex JACK clients out of LADSPAs, for example splitting the JACK client in two parts (GUI/engine) communicating via a standard msg bus system, such as D-BUS, which in turn would make it easier to write different GUIs for the same JACK client, Gtk+/Qt, pixmap/widget based etc. Moreover, it would help to set and improve a standard msg bus such as D-BUS. D-BUS seems to be very attractive since it's binary and comes from the desktop world which would make this issue interdisciplinary(linux desktop / linux audio) - a thing which i believe is crucial for linux in order to become a successful platform. 3. LADSPA should allow to build both complex effects and synths(technical issues? time-stamped events?) Comments? Marek

21 years, 4 months

Re: [linux-audio-dev] Is ladspa actually la-dsp-a? Is JACK the ultimate solution?

by eviltwin69＠cableone.net

On Tue, 8 Jun 2004 20:03 , Chris Cannam <cannam(a)all-day-breakfast.com> sent: >On Tuesday 08 Jun 2004 7:16 pm, Frank Barknecht wrote: >> eviltwin69(a)cableone.net hat gesagt: // eviltwin69(a)cableone.net >wrote: >> > Aaaaaarrrrrggghhhh - knobs. One of my pet peeves. >> >> I actually wrote a knob GUI element for Pd, which normally only has >> sliders. I see one good application for knobs: Visualizing things >> that must not take up much screen space. > >They also have the advantage of a more obvious centre position than a >slider, I believe they can be significantly quicker to read, although >not to edit, and they can be placed in meaningful groups more easily. >I think they're a much better GUI element than people give them >credit for. > Right click on any slider in JAMin and it immediately goes to the default position, whether center or zero. I did this to give you something that works like a detent. They can be easier to read and they may take up less space than a slider but why limit yourself to knobs and sliders. There are other ways to graphically handle controls. Jan

21 years, 4 months

Re: [linux-audio-dev] [OT] marketing hype [was: Is ladspa actually la-dsp-a? Is JACK the ultimate solution?}

by eviltwin69＠cableone.net

On 09 Jun 2004 21:10 , Michael Ost <most(a)museresearch.com> sent: >On Wed, 2004-06-09 at 15:56, Dave Robillard wrote: >> I don't think I could possibly care less who uses 'linux audio'. I >> don't really think anyone else here should either - we should be aiming >> to build the best system possible, period. Not saying "look! popular >> software the people pay money for does this; therefore we must too!" > >I'm with a company trying to make money off of linux audio. While I >enjoy the technical/academic discursion (though lots get the >subject-line only review! %), I'd like to think this list could support >those who mix the market with idealism.... like, well, me. > There's no reason that it can't. Paul wants to make money from Ardour and I don't blame him a bit. >> If anything, we should be looking at the proprietary music software >> world to make sure we avoid repeating their mistakes (ridiculous >> duplication of effort, lock-in, and horrid UIs for example), not >> duplicating them just because. (Not to say we can't take positive >> things from that world too though) > >Should I drop off the list? I ain't the same 'we' you are, I guess. > That was exactly Dave's point. Marek wants some kind of "we" thing going on. He wants us all to march off in solidarity in the direction he chooses and it just doesn't work that way. You want to make money, I don't care, Dave doesn't care, Paul wants to make money... There is no single correct direction here. Jan

21 years, 4 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