[Alsamodular-devel] Re: [Alsamodular-user] Future of AlsaModularSynth

[Lukas D. <AFB...@gm...>]

>
>
>sorry for the late reply, but I have been out of office for a while.
>
Glad to see some traffic again on this list :-). And thx for detailed 
comments on the raised issues.
Be warned. This is, as usual, an even more detailed reply. Hope no one 
falls asleep while reading :-)

>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.
>
Well, actualy we already three different designs :-) the "old" stable 
one, the one in cvs head, and the one proposed in the uml diagram i 
posted. There is not a single line of code for the later one yet, and 
atm i'm not quite sure when and to what degree i will start working on 
coding an actualy working prototype of it. More on this at the bottom of 
this post.

>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.
>
There might already be a solution that is rather simple: if i understood 
Steve correctly, (some) ladspa plugins store additional meta info in xml 
files that are distributed alongside with the plugins. I think it could 
make sense for ams to use this information (where available). In 
addition, i think it would also make sense to have information on the 
gui appearance (which widget should be used for what job, etc) stored in 
some human readable xml files (not unlike the approach used for ladspa, 
but with a less complex syntax).
This would add imense flexibility to the gui behaviour. This would 
apply, for ladspa plugins aswell as for "native" modules. (The uml diag. 
was created with something like this in mind.)

>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) ?
>
I think this, aswell as most other ui issues, should be an user option, 
at least in the long term. If an xml description for a particular gui is 
found, ams would read it to find out what the module should look like, 
which controls should be integrated in its visual instance, etc. A 
seperate dialog/frame would still be available, so if no xml description 
exists, ams would behave just like in 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.
>
definitly ;-).
in the current 2.0.0pre version, this is partly implemented
(hacked would be the better expression :-) )
I think this is usefull because in a "life" situation, once the set up 
of the wires etc is completed, my guess is that the 
parameters/controller bindings are what user is mostly interested in. 
(at least this is my experience). So it should be possible to hide the 
patch editor, and still have all relevant controls handy. It would also 
be handy to have such groups, when it comes to loading/saving "parameter 
presets" (e.g. set up "preset groups" so that you can switch 
throughseveral mixtures in your mixtur trautonium via a single midi 
controller) This is also partly hacked intor 2.0.0pre already.
And those one-and-a-half issue are exactly what ParameterContext is 
there for in the diag.

>I would propose to keep the UI separate from the module as in ams-1.5.x,
>just for reasons of module size.
>
Yep. Size matters. (Pun intended :-) )
Otoh, i think its moreless a question of some clever gui layout/design. 
Propably more work than i invested into the screenshot i posted. but we 
shouldn't bother with this too much. Lets make it an user option.

> 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.
>
dito.

>
>Some short remarks/questions about details of the design proposal published
>by Lukas:
>
>- Why do we need nodes ?
>
Good question. We don't exactly need them. I was just trying to drag 
some of the methods that appear in both modules and ports (with moreless 
the same semantics) into a seperate interface. Another motivation was 
that ports and modules only know what is absolutely neccessary about 
each others interfaces.
Atm i am not too sure about this any more. Same applies for the 
annonymous association between module and ParameterContext. The 
advantages of this pattern are paid for with a loss of type safety.

>- It is important to distinguish between input and output ports. They
>  behave fundamentally different in the processing of the module tree.
>
true. but they both share a very similar interface. i thought it could 
be possible to make the differnce transparent. But i agree that this 
involves difficulties, since their semantics are quite different.

>- What are the 4 Parameters of a ParameterContext ?
>  
>
 - presetSelect:Enum - select(and restore) a saved preset(==snapshot of 
parameter values at a given time)
The elements of this EnumParameter would represent all saved presets for 
this context

 - presetCreate:Action - create a new preset (contains current state)

 - presetDelete:Action - remove the currently selected preset

 - presetStore:Action - store the current state into the selected preset

>- 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.
>
Nearly correct. I thought about droping my current concept of having a 
Parameter subclass for each different type of parameter and replace it 
with a parameter class where the value is always stored as
a float. (like in ladspa) The Parameter would use hints, constraints and 
labels, to make clear  how this parameter could/should be interpreted by 
the gui. The idea behind this is that a module does not necessarily need 
to know how to create a certain parameter. In case of the ladspa wrapper 
that would be  very handy. The wrapper would simply pass a pointer to 
some float value and the parameters long name (which includes the 
modules name/id)  to the parameter factory. As factories are implemented 
on the FrameWork layer, they have access to config data  and can figure 
out which hints, etc should be used for the parameter in question. Of 
course, a module could also do the job alone, if it knows what hints are 
needed.
This implies that there _can_ be parameters without any (mandatory) 
constraints. It also implies that, in theory, a very simple generic 
control could be used by the gui for any parameter, if there are not 
enough informations to make a more refined choice. All such a widget 
would need to be able to, is displaying and editing of a float value.
In case of a "range control",  when user wants to set additional 
boundries, the respective widget would ask its model to remove any 
non-mandatory constraint of the same type and add a new one. simple 
enough, i hope, while still very flexible.

But let's forgett about all that fancy UML stuff for a moment. As 
pointed out in the beginning, there are already three completly 
different approaches to the "big picture" of ams. Only one is actualy 
working so far.

You can still consider the diagram i posted as a sketch of what i would 
like ams to look like somday, but

1.) I don't think anything "presentable" would be finnished until march 14,
otoh i realy would like to have some new features to show of with :-).

2.) I already spent *far* to much time reasoning while i actualy should 
be testing/releasing

3.) Design requirements might change whenever new features are requested.


So what's the conclusion? Maybe instead of 
"throwing-it-all-away-and-begin-from-scratch" i should rather start from 
the last running version in cvs head, add features by priority, and 
resolve "Bad Smell(tm)" issues on the way. I don't know.  I just don't 
know where to start. It seems to me that the design proposed in the 
diagram is ok for a start. But this is not refactoring anymore. It would 
mean a moreless complete rewrite. Does this still make sense?

I mean, if it was the decission of a team of developers, to figure out a 
new design, if there were people saying: "Don't do this, stupid, do it 
the other way!", or "I have this brilliant cool idea, why not try foobar 
here." an this sort of things, i would be happy, since i like that kind 
of work very much.

But right now, i often have the feeling of doing something pointless. I 
couldn't come up with visible results, i only could say smart things 
about how i would like to see things in ams, and all that. And in the 
end i would not even be sure at all, how people would react, when it 
turns out, that i just created a spin-off project, that by coincidence 
carries the name ams, but is infact only another different application 
with mostly redundant functionality.  And i sure don't want to do that.

So, long blabla, short question: What do you think? What should be the 
next step(s)?

Aways hungry for feedback,
Lukas