Re: [LAU] Editing zynadsuxfx/yoshimi patches?

From: S. Massy <lists@email-addr-hidden>
Date: Fri Apr 22 2011 - 01:20:23 EEST

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.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Fri Apr 22 04:15:01 2011

This archive was generated by hypermail 2.1.8 : Fri Apr 22 2011 - 04:15:01 EEST