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.
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
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
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
> 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
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
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
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
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
On Tue, 08 Jun 2004 20:55 , Marek Peteraj <marpet(a)naex.sk> sent:
>It all depends on how you perceive different controls (different knobs
>in different sections etc) and how you learn ot perceive them, i.e. how
>you get to know them and how you get used to them.
>
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.
>
>Virtual 3d guis copy the real world. Try to do it the other way around,
>with widget sliders and one color for both sliders and background(most
>cases). Imagine a hw which would look like that.
>
Why would I want to imagine hardware - we are talking about software aren't we?
>Another such case is animations in UI. They improve usability aswell.
>If carefully adjusted, they help to prevent sudden changes in the UI.
>Animations are not just eye-candy.
>
Sometimes. Rarely. Usually they are just a way to sell a product.
Jan