Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7501 discussions

[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

[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

[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

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

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

[linux-audio-dev] Re: UI stuff

by Ben

> Yes, it's definitely easier to see the position of a knob > (usually). > The parametric sliders in the JAMin HDEQ are a result of my not > wanting > to use knobs. I think there are probably other ways to replace them > as > well. > > Jan As a rule of thumb, if the parameters are related to each other (i.e. channel level controls) then it is clearer to use sliders because the user can compare the relative levels. If the faders are NOT correlated, then I find it misleading to have them arrayed next to each other. Knobs work pretty well in the "uncorrelated" case because your eye doesn't even try to decipher the relative values. My biggest beef with knobs is the variety of ways the mouse movement is implemented. Most software gives you no clue ... vertically? horizontally? radially? ... and Murphy's law says your first 2 guesses will be wrong. The app "Soundplay" for BeOS takes a novel approach ... the level is shown as a knob but when you grab it, a rectangular box appears behind the knob and you adust it like a fader. This is great because it gives you visual feedback of which direction(s) to move the knob. -Ben Loftis

21 years

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

by Ben

At Harrison we decided to avoid knobs altogether. Instead we use short, fat faders (OK there are a few knob things just to look different) That worked out pretty well. My preferences are: left-click for linear (up & down) adjustment right-click for fine adjust middle-click to return to default (if there is such a thing for this knob) double-click to edit radial just doesn't work for me. -Ben Loftis

21 years

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

by eviltwin69＠cableone.net

On Tue, 8 Jun 2004 21:15 , Fons Adriaensen <fons.adriaensen(a)skynet.be> sent: > >- When I saw the collection of VST plugins that Paul Davis used >to show his VST hosting in Karlsruhe, I asked myself "My god, >do they all look that childish ?". This is just to say I terribly >dislike this eye-candy style, and given the choice between that >and a (maybe boring) set of standard toolkit sliders, I'd prefer >the latter. The ideal is somewhere in between, but certainly not >to the eye-candy side. > Amen! >- Before everything went digital, multitrack mixing desks had >lots of controls and very little space to put them in. Good >layout was absolutely essential, and most of the big name >manufacturers mastered this quite well. It's done by > > - observing elementary aesthetic rules (e.g. color > combinations), Colors must always be configurable. The percentage of color blind people is much higher than most people think. > - removing all useless clutter, > - following the logic of the application, e.g. keeping > things that are related together, > - accepting culturally defined standards, such as that > a signal flows from left to right and from top to bottom. Except in China ;-) > - using hints that are picked up unconsciously, rather > than explicit labeling. > >All of this is practically the inverse of eye-candy. > >- Confucius says: When you see a piece of audio equipment >with the word "Professional" printed on it, then it probably >isn't. > >- The typical VST plugin (talking about the serious ones) >corresponds more to a JACK application than a LADSPA plugin, >not because both have a GUI, but because of the complexity. >This is just a matter of naming. We could start calling a >JACK application a JACK 'plugin' but I'd vote against. >JAMIN is a good example of this. > >- As to LADSPA plugins, we could probably give almost all >of them a very functional and nice GUI by defining a set >of a few dozens of 'widget types'. Then there are a few >options: > >1. the plugin specifies the dimensions and positions of >all the widgets, > >2. the dimensions are standard, and the plugins specifies >the positions only, > >3. the host keeps it own database of layouts indexed by >plugin ID. > Good idea but I'd think that could get real complicated very fast. Jan

21 years

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

by eviltwin69＠cableone.net

On Thu, 10 Jun 2004 02:06 , Lee Revell <rlrevell(a)joe-job.com> sent: >eviltwin69(a)cableone.net wrote: > >> Aaaaaarrrrrggghhhh - knobs. One of my pet peeves. Knobs make absolutely no >>sense in a GUI. There is no easy (or standard) way to control them. Note that >>there are no knobs in JAMin. The parametric controls aren't even knobs. I think >>this was the point he was making. Take a look at T-RackS. Lovely knobs and >>litle glowing tube pictures - how lovely. But a major PITA to use. Trying to >>make GUIs that look like some metal box is counterproductive. Just make the >>thing work efficiently. >> >> >Two words: mouse wheel. I cannot *believe* this has not come up yet. > It did, and it's a damn good idea. Since I don't have a wheel mouse I never thought of it. Gotta go get one ;-) Jan

21 years

[linux-audio-dev] Project ideas?

by michael tewner

I posted here a bit ago about implementing gibson's MaGiC protocol on linux as a final university project. Anyway, I was looking for other possibilities. The project can be fun and all, but has to have some acedemic value (being able to "publish" is a big plus). Perhaps working on that Juno9 VST? I don't have *too* much programming experience, but I learn fast. Any ideas for a interesting program is greatly appreciated. ...Perhaps, it'll make a good list to post online for people that wanna help out linux audio support but don't know what's needed/wanted. Thanks y'all -mike

21 years

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