Re: [Octal-dev] octal's tracker heritage [was re: text params]

[Bullwinkle J. Moose]

If i understand corectly, (and i may not ...) mostly this about the best way to
display information for the user?  Hex is fast, Space saveing, and can requier
less typing than decimal digits (but does it realy do it that much better?), but
it is not exactly easy for a new user, and more importantly, it, in general, 
tells
very littl about the paramiter, sort of. Take as an example, a pitch shifter.  
One
Pitch shifter machine might allow users to shift a pitch up or down in half step
increments.  Another Pitch Shifter Machine, from a different source, might allow
for shifting up or down in quarter step increments.  But the both display BF as
potential value?  How would the user tell them apart?  Well, one posible 
solution
would be to allow machine to specify the display format (this could be swithed 
on
and off from a menue or dialouge box so users who prefer to do so could use the
straight hex values).  Adding to each machine that wished to take advantage of 
the
feature, a pointer named somthing like Display_Value, that would point to sting
representing how the machine auther feels best, and most acuratly represents the
value would be one way to it.  For example "0.25" or "1.5" or "+1/2" or anything
the machine auther feels best describes the value.  A status bar at the bottom 
of
the window could state the currently active cell represents the number of steps 
to
shift up or down.  0.25 ot 1/2 would then be far more meaningfull what ever hex 
or
decimal value could be put in. By haveing the machine send the string, no tables
would be needed, the machine could simply have a function that returned the
appropriate string for the given input value.  Putting that into a function 
could
also allow Octal to get the string for the next value, potentialy speeding 
things
up, but i don't thing it would take to long even with out that, i think anyway.
Aditionaly, it then allows the machine to pick out how best to state the value 
of
what ever odd-ball paramiter might be in question.  And ofcoarse Octal could
ignore all of this in 'Expert Mode' or something similar (i,m shure other items
could also be done differently in a 'Simple Mode' or 'Expert Mode').

Also, finding the right values in general might be done easily by allowing the
user to scroll up and down the available values useing perhapse the < and > 
keys?
Then, even with hex values, they would have an idea of what the maximum and
minimum values are, combined with what the status bar says about the what the
value is and what the user can infer from the name of the machine.  That, even
with hex values, would make it more 'user friendly', and useing the key board to
scrol would eliminate the need find a widigit that would work well and be easy 
to
use, and at the same time take up very little space, since compact display sizes
seems to be a priority.

But probably the best and most usefull thing Octal could do would be to allow 
the
user to hear what the values do.  Buzz 1.1 does this when ever a vaule is 
changed
in perticular collum, it has the machine generate the tone for that particular 
set
of paramiters.  So weather or not the value is displayed in decimal, hex, or 
even
Greek, the user can hear and know Exactly what that value will produce.  It 
would
be nice if the GUI had a button on that would sound the tone for the current row
with out haveing to change any of the values.  It would also be nice if a patern
could be played threw while in the patern editor window, so the user could hear
exactly how that patern sounds, and  make chages right away with out haveing to
switch around between windows and not have mute (and later un-mute) other 
paterns
in order to hear only the patern curently being worked on.
Ofcaorse, that really only works with generator machines, effects machines would
need to have some sort of default tone to run threw them, and/or allow the user 
to
select a specific patern from a generator machine to run threw the FX machine in
order to see how the paramiters set fot it sound.  (If you wanted to get realy
fancy/flexible, you could have a directory with various sound samples that the
user could change, or some other way for the user specify an arbitray sound 
sample
to play threw an FX machine to see how its current paramiter sound, but that may
not be nesecary / worth the effort).  In the end, being able to actualy hear 
what
the parmeters do will be far more usefull than and Hex value, decimal value, or
descriptive string.  It is rather analagous to the colour pallets on most 
graphics
app.  The could only allow you to enter digits, since that is The program is 
going
to represent the colour internaly anway.  But nearly all of them allow you 
choose
by seeing the colour on screen and clicking on it (eventhouhg some do also allow
you to enter in numeric values, since in some instance that can be quicker and
easier).

It sort of all comes down to the clash between the needs of power users and 
novice
users.  An interface that is very easy for a novice to figure out can easily be
cumbersome to, and get in the way of, experienced users.  It is posible to cater
to one goup, but that puts out the other.  Or a program can provide a box of 
some
kind where a user can tell the program at what level they are, and the interface
can then adjust to them, rather than the other way around.

Where in the development cycle to begin adding the addition feature to deal with
novice user is another discusion...