22 Apr
2011
22 Apr
'11
12:18 a.m.
On Thu, Apr 21, 2011 at 10:40:14AM +0200, Julien Claassen wrote:
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".
Hmm, maybe calling them classes
was misleading, since I didn't exactly
mean it in that way (with methods etc.), but rather was seeking a
non-specific to talk about these concept.
[...]
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.
Perfectly correct.
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.
I see them as being separate.
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.
Key definition would vary
according to the type of parameter being
manipulated. The handler should also display critical information about
this parameter in a straightforward manner. Something like:
"Name: OSC1 Freq, unit: Hz, range: 20 - 20000, Value: 900"
"Name: WaveForm, Type: List, 1. sin, 2. tri, 3. sqr, 4. saw, Value: Saw"
There should always be the option to input the value directly, bypassing
the decrement,increment keys.
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...
What use-case do you have in
mind?
I realise it's ambitious, but I see a possible design goal for our
dream-interface as being able to populate itself, thus offering a
convenient, mostly toil-free way for developers of audio software (I
mostly have synths and plugin hosts in mind at this point) to offer a
text interface.
See my reply to the FUSE idea further down this thread to get a feel of
how crazily I'm dreaming right now. :)
Cheers,
S.M.