Dear,
On Thu, 20 Jan 2000, Michel Jullian wrote:
> - Since you want to reach as many users as possible, ease of future porting
> (to Windows in particular) should be a concern even if porting itself is not
> part of your immediate project.
I know, this is why I'm seperating the application core from its
interface, as described in the design document on my website.
> - Since you haven't started implementation yet, for an open source project I
> suggest you use FLTK (Fast Light ToolKit, www.fltk.org) as a portable GUI
> toolkit instead of Qt, as it is non-proprietary, free, open source, faster,
> lighter, permanently feature-enriched by benevolous contributors around the
> world like linux, and allows for opengl child windows so you have a very
> powerful and universal 2D/3D graphics library at your disposal for drawing
> purposes. Portability of FLTK : Unixes (including Linux) and Windows for the
> moment. Mac in a few months. BeOS envisaged. Most importantly you may find
> more people willing to contribute actively to your project with fltk than with
> Qt for cost and license restrictions reasons.
I'll take a look at it. However, KDevelop is a complete IDE for linux, and
I'm using it to develop. It integrates nicely with Qt (documentation
browser etc), which can save me some time.
If I use FLTK, I lose the dialog editors and other helpful mechanisms
offered by KDevelop. On top of that, FTLK doesn't seem to have a signal &
slot mechanism and a strong widget hierarchy (perhaps I'm wrong, I just
took a quick look).
Qt also has support for openGL.
> - You need one library (librarian's database) per code-generating plugin :
> this way you can have a saol plugin and e.g. a CSound plugin, each with its
> own library of modules (UGs, macros, instruments and orchestras).
I think it might be better the other way round: define a set of primitive
building blocks in the SML standard, which a code generating plugin must
support, or it is not a code generating plugin. That way, the library is
not strongly connected to code generation. It's just a tree of SML tags.
The standard could advance to 2.0, 3.0, ... as more primitives are
proposed and accepted.
> - It seems fair that an orchestra should only contain intruments and buses,
> but you should allow the mixed use of both UGs and macros in lower-level structures.
This is supported in the philosophy.
> - Pins should be labelled.
They will be.
> - Modules and pins should be "tooltipped" so the user knows what they do when
> wandering his mouse over them.
The modules have a caption and the pins are labelled, so I don't see why
tooltips are necessary.
> - You need an input/output side convention (inputs on the left and outputs on
> the right is the most standard, and makes most sense considering we read from
> left to right and screens are generally wider than high)
They are left-to-right.
> - Now this is far-reaching, but maybe to make your tool even more universal
> you could envisage to develop the main functionalities of QOrchestra itself as
> a plugin (dynamic library, interface to be defined). This way a sequencer for
> example could use it to graphically connect e.g. vst plugins together and be
> warned of user input to take appropriate action (e.g. when warned by the QO
> plugin that the graphical representation of a plugin is double-clicked,
> display the plugin's panel), which a separate app communicating only via an
> SML file couldn't do.
I've thought of that too, but the application is already beyond its
initial requirements. Don't get me wrong, I appreciate the comments. But
for now, I want to focus on implementing what I've designed.
Thanks for commenting,
Bert.
____________________________________________________
Bert Schiettecatte (1e lic. Inf)
Vrije Universiteit Brussel
E-Mail: bschiett@vub.ac.be
WWW: http://wendy.vub.ac.be/~bschiett/
-- To be a popular composer, what is it you must do?
Perhaps to learn enough tricks that cause people to
have pleasant sensations without too much stress.
What are the tricks for making that catches on in
a listener's mind, and keeps repeating long after
the performance? -- M. Minsky
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:03:50 EST