Hello Massy!
OK, taking you up on classes and objects. I'd like to talk about them in
terms of classes and objects, as they are used in programming. So a class is a
description (building plan) for a thing. An object is a thing. There can be
many things of the same type. Classes have hirarchies. Typically explained by
using the realm of animals. You have the class mammal, which has things like:
function give_milk and move and variables like number_of_legs and weight. And
you have virtual functions, those are functions, which have no defned
behaviour in the base class, but must get one in derived classes. So mammal
might have make_sound, which is empty. then we have dog, which has four legs,
a certain way of giving milk and the make_sound function makes "woof".
Sorry, for all those, who knew about that, but I think it's good to be clear
and we are not the LAD list.
OK, so the way I think: We have a general main class, which is likely to
have one instance only (one object). The main class inialises the setup and is
a program thread. So it is abel to handle all the input/output stuff, while
the real program (the engine) goes on in the background.
Then we will need a tree (or two, if we include menus). It must be a tree
with arbitrary number of branches from one node. So we have the root node and
from there we might branch off: effects, oscillators, global settings,
controlers... In each branch we have againnew branches. This tree must be
searchable (so we can do a text-search for parameters or branches. So we can
search for "filter reso" or "oscillator 1". Oscillator 1 has more than one
property, so it would be a branch holding things like: fine tune, waveform,
sync'ed state, etc.
I think, and this isn't really clear yet, that the collapse/expand, search
functions and keys, are part of the main class. So we have a loop somewhere,
which waits for keys and does something. Well one might wrap one's own design
around an existing tree class and put it there. It's a question: Is this
behaviour part of the main interface or is it part of the tree.
In any case, I'm thinking of being able to pass from key-handler to
key-handler. So if you press enter on a parameter, you get handed over from
the main/tree key-handler to that parameters handler. Which in turn may have
sensible definitions for some editing keys. for integers, you might have + and
-, or = or enter to enter a specific number. On a boolean you might just have
enter or some other key to change between true and false, on and off.
Jumping to the commandline: Well if you have all those tree commands on the
commandline as well, you can 0 with the right design - use it to script
things. I'm not only thinking of Yoshimi here, but I suppose this idea is
leaning more towards a general thing. Take the sfz-builder, that Joostein is
writing...
OK, that's that for now, let's talk about navigation and other main/standard
keys later, since they will need some looking at. And in anyway, they are
lower down on the list of things, that really need to be thought about, as in
structure and what we really need.
Warmly yours
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
