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

[Dave O'Toole]

Ok. Well, there are several issues here. 

1. Having non-scalar parameter values
-------------------------------------
i.e. vectors. There's no support for this in the current API. I'm not
sure if there would be any useful way to represent this as a horizontal
tracker column. I can think of ways to do it but none of them are pretty
so far. I suspect this is why, AFAIK, no trackers do this. 

However, I have considered adding such a feature in a way that doesn't
break the tracker. 

        a) have pieces of text that the user can edit, numbered 0x00--0xff :-)
        b) the tracker column ***chooses which block of text to use*** while
OCTAL manages the editing
        c) akin to how the wavetable works, the machine requests a text string
corresponding to a given "block number" 

I think this is better than editing arbitrarily large strings *as
tracker columns,* in that, at least, it is not a fundamentally broken
idea. :-) This could be useful for machines that can accept textual
scripts, and a coder did mention a (possibly amazing) application for
this idea. (I don't want to announce his idea before he gets a chance
to.) If and when this gets implemented, it won't be through trying to
shoehorn vectors into the parameter API. My rationale is that vector
data needs its own editor, usually. Which is where GtkWidgets come in
:-)


2. Having non-hex parameter visual representations
--------------------------------------------------

This is a touchy one. 

The use of hexadecimal digits to represent tracker data is definitely a
tradition, which presents its own obstacles to change. However, this is
*not* an arbitrary choice to be suspended without consequence: hex takes
up less space, which is at a premium in trackers such as OCTAL that
allow many parameters per track. It requires fewer keystrokes to enter,
and hence the user can work faster. And that is the priority. 

There is also something to be said for consistency and not having
different *number systems* in a track. "06".... is this column hex, or
decimal? what about "74"? We could get into color coding etc, but this
would just be silly.

I see that it could be good to reduce the learning curve. Typically,
trackers have not been easy to learn. But I think hex vs. decimal is the
least of our problems there, though it tends to get more than a few hits
in "MOD versus MIDI" flamewars. 

The real difficulty to learning a tracker is not the number system, but
the fact that tracker architecture is so wildly different from what most
users have encountered in their dealings with MIDI and other electronic
music tools. Step-sequencing, discrete channels for polyphony, the
increased control available to the artist... these are more compelling
obstacles to the tracking newbie than is learning to read hex. 

It is my firm opinion that these differences are the source of
tracking's strength: speed, economy of expression, and control. Hence I
am reluctant to make changes that could reduce these strengths, for no
other reason than to make the system look/feel/act more like everything
else. 


3. Having non-integral parameter values and representations
-----------------------------------------------------------
This one has come up before---I can't find the original post, but in
general my argument was that there is no good way to edit floating-point
numbers as a tracker column. (Let alone the fact that they might be like
20 digits.) 




-- 
@@@ david o'toole
@@@ address@hidden
@@@ www.gnu.org/software/octal