Re: [linux-audio-dev] Project: modular synth editor

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Project: modular synth editor
From: Alfons Adriaensen (fons.adriaensen_AT_alcatel.be)
Date: Thu Jan 15 2004 - 14:32:06 EET


On Wed, Jan 14, 2004 at 06:13:29PM -0500, Dave Robillard wrote:

> Why does the plugin care? Granted, some resources could be saved having
> a mechanism for the plugins to know they're polyphonic; but I don't
> think it's that critical. That seems like an optimization detail to me;
> I can't think of a reason polyphony couldn't be properly handled by the
> host (like I said before, AMS /already does this/)!

> Agreed, would be nice. But still just an optimization detail. Unless
> everyone is willing to start drafting LADSPA v2, it's not really worth
> talking about. And somehow I doubt LADSPA is gonna be changed anytime
> soon (although these problems/improvements would benefit everyone, not
> just a modular synth.... think post processing effects, lots of multiple
> plugins running there).

Well, let me make one thing very clear. For me, optimization is *not* a
detail nor something that should be ignored during analysis and taken
care of later. By then it's probably too late. When I design or analyse
anything that's not trivial, efficient implementation is as much a point
to be considered as are functionality and abstraction. I've seen too many
good applications being crippled during their entire lifetime by early
design decisions that ignored this.

> I don't think this is necessary, and just adds uneeded complexity
> (especially to plugins, which is a Bad Thing(TM)). I'm not familiar
> with the internals of ams all that well yet, but is this really the only
> way to accomplish these things?

The metadata I'll use is transparent for the user, it's related only
to implementation.

> > You can change that color, see main.h. As to the widgets, that will comletely
> > change in the second generation. In fact the GUI will be separate application
> > that can be replaced without touching the audio code.
>
> I know. I have. :D One of these days I might make it use configurable
> and send in a patch, but since AMS doesn't even have a config file that
> I know of....

I introduced main.h in 1.7.x as a point where all that sort of things will
be collected. Turning that into a run-time configuration will be the second
step.

> Once you start doing anything remotely complicated, LADCCA just becomes
> necessary. With this track I've been fiddling with lately it literally
> takes 5-10 minutes just to get the environment properly set up.
> Obviously this is a pretty big problem. It's getting better though.

I'll keep that in mind. One remark though: I will be happy to support any
session management system as long as it is general and uses only standard
interfaces. If it requires a particular window manager, desktop or toolset
for example, it will not be supported.

> > What sort of 'ports' would that be (except for MIDI, but this is already
> > possible) ? But maybe I don't understand exactly what you mean.
>
> I mean ports on the plugins.. take the LFO plugin for a simple example..
> right now, the frequency is a control in the GUI (right click, open the
> GUI, and you'll get a slider). It would be nice to have the option of
> making it a port, so some other part of the synth could plug into it and
> control the frequency of the LFO. So you could, say, make higher notes
> have a faster vibrato or whatever. (Okay, not the best example, but you
> get what I mean).

OK, that maps to the requirement that almost everything that has a slider
must also be 'voltage-controlled'.

> No, it was connected. The synth works fine in all aspect, except when
> notes are _dead on_ simultaneous. I assumed this was because the
> developers don't have a real MIDI controller and never ran into this
> problem. (vkeybd probably has sufficient delay between "simultaneous"
> notes to avoid the problem)
> I'll put something together with a .mid file to show it.

Strange. I'm using AMS in poly mode with a real MIDI controller almost
daily. I'm sure J.S. Bach would complain if some of his notes fall out :-).
Anyway there's no such thing as "dead on simultaneous' as MIDI is a serial
protocol. And even if you play a MIDI file, chords will be serialised at
the ALSA port. Waiting for your example.

> Well.... it appears to me like the "new ams" isn't going to materialize
> any time soon; my point was: if these improvements are made to the
> current AMS, will they all be thrown away for a totally new codebase, or
> is alot of the code going to remain?

Almost all the engine code will be new. Too many things need to change.

-- 
FA


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Jan 15 2004 - 14:34:06 EET