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]
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
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
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.
--
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...
:)
--
> 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
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