[LAU] Editing zynadsuxfx/yoshimi patches?

[Julien Claassen]

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