Re: [Octal-dev] suggested features

[dave]

> What i want is a mixture of all these programms.

> After playing with this little tool there is one conclusion: The
> machine interface is the most importend module of the hole thing.

Do you mean the user's GUI, or the programmer's API?

> VARIABLE MACHINE PARAMETERS:
> think of an volume/pan/frequency...  envelope.
> it would be fine for the user to add/delete points to the envelope at runtime.
> so we need some sort of variable parameter.
> this is also usefull for a sine-wave-generator with  "over waves" -
> (sorry my english is not the best, but i guess you now what i mean).

The current plan for OCTAL is to have all envelopes globally shared and
synch-able; GTK+ already has widgets designed for editing envelopes and
curves. 

> VIRTUAL MACHINES:
> the user can connect some machines and create a new machine of this
> set.
> this virtual machine acts like a normal machine. plus it also can be
> used in other virtual machines.

Easier said than done, with non-trivial machines; what kind of interface
does the new "virtual machine" export? That of one machine inside it, or
all of them stuck together? 

There has been some debate here and elsewhere about whether or not this
"macro" facility is needed in high-level unit generator environments,
given that each individual machine does so much more by itself. Since
machines can multi-track dynamically, and since signals can split
whenever you wish, there isn't as much need to replicate whole identical
groups of machines (i.e., in old UG systems where each voice of
polyphony was a replicated set of units.) 

In any case, this is probably a GUI issue rather than an internal engine
issue.  


> MIXDOWN MACHINES TRACKS PATTERNS :
> Softwaresynthesis consumes lots of cpu-power. (i have 166Mhz Pentium).

> To work around these problems we can mixdown tracks, patterns and
> sequences to waves.

(In buzz this was implemented as a machine; there might not be any need
to add this to the engine)

This sounds like a nice idea at first but I can't help but point out
that it will probably not be used too much by people with recent CPU's.
Plus, since we would now have to store all the recorded sample data from
patterns/tracks/machines, we now need lots of memory. (OCTAL samples are
currently 32-bits long) Since now the engine needs to know where the
pre-recorded material is and whether to play the pre-recorded stuff or
cause the machine to generate, the engine needs to get a lot more
complex to do all this caching. And if you run out of memory (not
unlikely on a slower old machine) then the OS will need to go to disk,
at which point the entire thing falls apart (especially if you have a
slow computer, which is why we did this to begin with :-)

I think a better approach would be a hard-disk-recording plugin (which
can also work from memory) which can play patterns that you've
pre-recorded (and perhaps edited/effected with a sound editor?). Doing
automatic, transparent "pre-recording of patterns" isn't interesting
enough to justify redesigning/complexifying the engine. 

> The Sequence Editor:
> I think of an editor you now from MIDI-sequencers. But instead of this
> unuseable note editor, we use a tracker interface.

I agree with you; MIDI sequencers are unusable and "blobby." Most of
them suck. 

> This leads me to the idea of using an event triggerd synthesizer. The
> advantage of this: you can have an midi-interface. But i don't know
> yet how to realize that.

:-) What besides "events" can trigger a synth..? Well anyway, MIDI
support will be done with a tracker interface. There's no reason we
can't have a MIDI-out machine like Buzz does; for MIDI in control, there
will be inside support in the engine for that kind of input. It'll be
for realtime control of parameters, and probably also recording of note
performances and controller-->track pattern conversions. Beyond this,
OCTAL will not be a MIDI sequencer. 

It's a little early to get to that though... I'm still coding the normal
UG engine and working on the algorithms. 

> WIDGETSTYPES:
> MULTISWITCH: this thing has 2 to n states. each state has a text-description 
> to know the actual state.
> Example: Filter: LOW MID HIGH

The newer, revised version of the OCTAL API Developer's Guide (to be
posted soon) has more details on how OCTAL's API implements choices such
as this, i.e. named-options exactly as you describe here. You might want
to check it out once finished (see the OCTAL home page
http://www.gnu.org/software/octal and there's a link from there) and see
if the ideas in there match up with what you've been saying. 

Anyone up for translations of OCTAL docs? TeX/LaTeX experience a must
:-)