Re: [Fwd: [Octal-dev] delay length unit choices, distro issues, etc]

[Neil Nelson]

 Dave O'Toole wrote:

 > * delay lengths.

 > One thing I wanted to point out, that I consider very important (but
 > forgot to put in the docs :-) is the fact that an essential feature of
 > most echo/delay Buzz plugins is the ability to automatically select
 > delay lengths as a function of the size of a tick (sequencer row) as
 > well as other unit sizes. One control selects the unit size (tick,
 > tick/255, ms, sample, etc) and the other selects a particular value
 > within the range. I suspect that I can wrap this into a single "length
 > selector" control, but this isn't definite yet.
 > But this ability to automatically calculate delays (and decays, etc) so
 > that they're related to ticks is very important, and I would encourage
 > its use in OX_API plugins.

All delays are in milliseconds (1 sec/ 1000) multiplied by some defined
maximum for the particular program, or can be made to be so.  I see that
you have given the number of ticks per minute in engine.c such that a
conversion can be made.  In order to maximize the variability of different
maximum delays for each program, which would need to be independent of,
say, a maximum of only 255 ticks, the ticks associated with a particular
value on a display screen may be best computed for display.  However you
prefer this to be done, it is easily implemented.  When you have time,
look at soxecho.c and let me know how it should be done, which can be
then standardized throughout.

>  * questions.

> Here is a questionnaire I first wrote after Avelino posted his plugin.
> I'd appreciate it if you could offer some thoughts/feedback on your
> experience with OX_API.

 > 1. did you use raw OX_API, or ox_wrappers? (c or c++?)

The programs are in c and based on your delay.c and Avelino's svfilter.c.

 > 2. have you been able to test it out?

I have tested the programs on a variety of parameter values, testing for
obvious problems such as the common clicks or interruptions and overall
quality of the sound.

 > 3. as a programmer, how does the API feel? it is easy to use? are there
 > clunky parts? if you could change something about OX_API to make it
 > easier to program, what would you change?

The function areas in these programs appear to reflect similar functions
in the SoX programs such that, I expect, similar functions would be
required in most designs.  The ox_desc function and the params area
will apparently be useful in the GUI that will show their usefulness
later.

 > 4. was the API documentation good? were there any parts that weren't
 > explained well?

The documentation was good enough, and the example programs were very
good.

> * distro issues.

> Neil, the system may have notified you that several of your recent posts
> had to wait for list admin approval because they text was too large. I
> didn't mind doing this, but it does remind me that mailing lists aren't
> the best way to distribute software :-).

> For legal reasons it would be a real pain to have them distributed
> through GNU itself, because they're by many different authors who may
> need release from "work owns my code" agreements with their employers
> (this is made worse by the fact that some of these are ported.) So,
> several options are before us:

> 1. you could put your plugins up at your webpage/ftp site, and I would
> link to them from the Octal page as a directory of "octal people". This
> would also be a fine stopgap solution, because I would like to start
> putting up the names/homepages of people who are developing with
> OX_API... sort of a community-building thing.

> 2. octalmachines.sourceforge.net (this is a nice idea, anyone know how
> much of a headache it would be to allow anonymous/multiple checkins?)

> 3. someone offers some hosting space / ftp for a quick+dirty repository.

The SoX copyright appears to allow use for any purpose as long as the
SoX copyright notice is provided in the programs, as I have done.  I
have, or have intended, to give the software to the Octal project for
inclusion in their distribution.  I.e., my copyright is much the same
as SoX and references the copyright notice in the Octal distribution.

My intention is to convert the more useful SoX effects to Octal, in the
very short run, so we can fill out the Octal distribution.  Octal
without effects and, later, sound sources will not be very easy plug-
and-play.  I would expect that a thorough distribution would be one that
is downloaded, compiled with the GUI and other user selected options and
then be ready to rock-and-roll without much additional work.

Avelino's Psycle appears to be a close model to an eventual Octal
result.  We might easily port Octal to a Psycle GUI.  The machines are
the sound sources and effects that we should be able to grab from a
menu and paste into a machine network.  Hence we need the kind of
effects in the basic distribution I am providing.  You may want to
try out the effects, look at the code, and then we (I) would clean them
up to your specifications and put them in the basic (your) distribution.

It is a bit like this RedHat Linux distribution I am using, RedHat has
gathered together software from may sources to provide an easy plug-and-
play for a variety of user purposes.  You are RedHat, and I am one of
your sources.

Next is the sox mask.c, then a noise generator from mask.c, then sox
phaser.c, then reverb.c, then vibro.c, then a compander, then possibly
a variety of filter programs.  Then its off to Fourier analysis to
provide a multitude of sound sources.

Although, Windows is not particularly open-source, we might coordinate
with Avelino to make Octal the foundation on which the Psycle GUI runs.
Clearly we need a Linux GUI, but there appears to be a close Windows
GUI we could adapt fairly quickly.

Neil Nelson