From: Steve H. <S.W...@ec...> - 2003-02-25 09:57:56
|
Als...@li... Bcc: Subject: Re: [Alsamodular-user] Future of AlsaModularSynth Reply-To: In-Reply-To: <3E5...@gm...> On Tue, Feb 25, 2003 at 12:36:55 +0100, Lukas Degener wrote: > >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 Yes, and I can add what metadata is missing where its needed. > >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. That sounds workable. Before you start designing how the UI should work you should play with a Nord Modular (try one in a shop or something), the way the UI works on that is really neat and well integreated: http://www.clavia.se/pictures/nordmodular/patchwindowlarge.jpg without taking up very much screen realestate. > >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 :-) ) What some of the windows s/w modualrs do is alow you to create "paramter patches" where you drag a set of UI objects around to make a custom UI for your patch. I think this works really well. > 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 would go for a complete redesign, theres a great quote about how no piece of software works right until its been rewritten at least once ;) It sounds like the stuff your proposing would require a major overhaul at the every least anyway. FWIW I'd love to work on AMS, but i really just dont have the time (it would mean learning c++ and qt for one thing). I can contribute modules though, if you make them LADSPA compatible. - Steve |