Re: [Octal-dev] text format for param?

[Neil Nelson]

Luka Frelih wrote:

> hey
>
> i'm reading TDG and miss a string format
> for the param type - would be great for machines
> like speech synthesizers or maybe graphics synthesizers
> not to mention karaoke... ;)
>
> i guess you can stuff four chars or two unicode codes
> into one slot...
>
> anyone has an opinion?
>

Yes, I was coding up a flanger plugin from SoX and saw that
fractional values (reals or floats) needed to be approximated by some
integer scaling--e.g., dividing by 255 (0xFF) with a maximum of 2
byte (integer, four digit hex; cf. p. 15 of TDG) precision.
No doubt, these sizes were chosen to simplify the handling of the
parameters and their eventual use in lengthy track tables (historical?).

However--and to emphasize the geeky nature of these parameters
(with `geek' according to ZDTV being a term akin to an advanced
practitioner in popular, modern computer language), both Dave
O'Toole and Avelino have coded hexadecimal values when decimal
would do; true geeks (a term of friendly approbation) code in
hexadecimal.

But of course, the average octal user (hopefully if we want Octal to
be accepted by as many as possible) will likely be ungeeky, and
hence will want to see their tracking tables in an everyday language.
This would require either a translation for user purposes with the
tables
remaining geeky behind the scenes or perhaps an ultra-geeky
(substantially more difficult) method of using, storing, and displaying
common expressions.  And then we would incur additional translation
processing time and then possibly additional complexity in methods to
reduce that additional translation time such as a parameter precompiler.

At the moment, we should likely continue with the current method and
just investigate alternatives to make the parameters more user friendly.

Initially, it would seem that we could store an array of pointers that
look
into a variable length char array that would contain the actual
parameter
information of whatever data type (numeric or string) and then have
a translation utility put and get those parameters according to a preset

parameter type list for each machine type. E.g., a machine may expect
parameters in the order of: string (char), long int, short int, short
float,
long float; and the put/get translator would provide those formats.
(This
could be simplified to either string or numeric with the remaining
divisions
being, say, automatic compression methods.)

However, requiring Octal to then perform the translation for each track
and
row may be an undesirable performance penalty.  The penalty could be
reduced by translating the previous char data to concurrent tables of
different data types and then pointing directly into those tables with
an
additional behind-the-scenes parameter of parameter table (or type;
some switch code might work).  We may waste a little memory with this
method, but we eliminate the translation code with some quickly
performed
parameter precompiling and an addition of a short switch sequence at
each track and row, or we could eliminate the precompiling by storing
the
data into the several data type tables throughout.

Or if we did not like wasting the additional memory, we could place
precompiled parameters in different data type queues (precompiling
may be desirable in this case) such that the next parameter value to be
processed in the ordered run-time sequence would be the next value
in that parameter-que type. And then there is indexing.

Neil Nelson