[Alsamodular-devel] Future of AlsaModularSynth

[Dr. M. N. <ma...@su...>]

Hello,

sorry for the late reply, but I have been out of office for a while.

Meanwhile I read the postings on the future design of ams and had a
look on the design figure and the VCO skin provided by Lukas. Thanks
Lukas, this already looks quite promising !

The current situation of ams is that we have both my "old" design, which
is quite stable and useable, and a pre ams-2.0.0 which does not yet work and
needs a lot of discussion on fundamental design issues. I'm currently
finishing Scala support in ams-1.5.8 and intend this to be the last
feature added to ams in the "old" design.

The question of whether or not modules should be implemented as LADSPA
plugins is almost as old as ams itself (and has been there also a long
time before ams). Of course it would be great if a commonly used plugin
API could be used for the modules. Steve and I discussed this already a
long time ago. The main difficulty in using LADSPA for modules is the lack
of support for graphical widgets in LADSPA. How would you treat e.g. the
envelope modules and a Dynamic Waves module ? And what about spectrum and
scope viewer modules ? Maybe we can find a solution for this issue at the
LAD meeting next month. Whatever solution we come up with should be as
simple and as close to an existing plugin API (probably LADSPA) as possible.

With regard to GUI and Skins of module interfaces, two important questions
arise:

1) Should the UI of the module be integrated into it's visual instance (as
   it is the case in the VCO UI design of Lukas) ? Or should the module
   appear just with it's I/O ports with the UI being a separate dialog or
   frame (as it is in ams 1.5.x) ?
2) Would we like to allow grouping of parameters beyond module boundaries ?
   IIRC this was the initial goal for the redesign started by Lukas.

I would propose to keep the UI separate from the module as in ams-1.5.x,
just for reasons of module size. In addition to the configuration dialog
of each module, one could add a UI frame in which the user can place the
controls (and views, e.g. envelopes) that are most important for the
respective patch.

Some short remarks/questions about details of the design proposal published
by Lukas:

- Why do we need nodes ?
- It is important to distinguish between input and output ports. They
  behave fundamentally different in the processing of the module tree.
  If you want to change that, you have to find another algorithm for the
  data processing of the module network.
- What are the 4 Parameters of a ParameterContext ?
- As to constraints: All parameters have min./max. bounds that are
  mandatory. The boundaries can be restricted to a smaller range. This
  constraint would be non-mandatory. So as I see it, each parameter has at
  least one constraint (it's initial range) and an additional constraint,
  if the user changes the range.

Matthias

-- 
Dr. Matthias Nagorni
SuSE GmbH
Deutschherrnstr. 15-19    phone: +49 911 74053375
D - 90429 Nuernberg       fax  : +49 911 74053483