octal-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: nicolas . leveille
Subject: Re: [Octal-dev] text format for param?
Date: Thu, 22 Jun 2000 08:52:36 +0200
User-agent: IMP/PHP IMAP webmail program 2.2.0

Quoting Neil Nelson <address@hidden>:

> 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.

on this particular point:

Trackers have almost always used the hexadecimal convention in the interface. 
This had the advantage of being able to stick more numbers in a few columns.
Some trackers have the possibility to switch hexadecimal to decimal for example 
in row numbers. Anyway tracking is a kind of sound/music hacking so I think 
nobody was ever bothered by that. 

If someone wants to change this, make it at least swichable. ;)

-Nicolas Léveillé (Knos)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]