Re: [LAU] Editing zynadsuxfx/yoshimi patches?

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