Analogue-sequencer

I've asked this before, iirc, but I want to give it another 
shot.

1. The P3 has a number of key combinations (press key X+Y to 
do Z) built into the user interface that I optionally liked 
to be replaced with a dedicated key. 

2. Afaik, the P3 has room for additional keys in the key 
scanner hardware.

3. Since I still haven't designed my front plate, I have 
space for, say, a block of 9 addtional keys.

4. As keycombos are added, to my taste for direct keys 
changes, I'd like to be able to change the function of the 
direct keys, by modding the executable myself.




So here's my suggestion:

- Add support for a number of additional keys in the OS, say 
16. I call theys OptKeys (for Optional Keys).

- Add a OptKey table in the OS. This is a vector of bytes, 
one byte for each OptKey (so 16 bytes in our example). 
Default value is all zeroes.

- Define an enum with no more than 255 function codes that 
represent the functions that are called by pressing key 
combos. Codes for other functions can be added too.

- Add code in the OS that scans the OptKeys. When one of 
them is detected as pused down, use its key index (say #5) 
to lookup the function code in the OptKey table. Based on 
the function code, perform the corresponding function. A 
(default) function code of value 0 indicates no action.

- When an OS is released, supply the offset in the binary 
for the OptKey table, so that we users can hack our own 
OptKey functions into the OS, without bothering Colin for 
that. Every one can now have its own optional keys, with 
whatever layout. :)

Is it my breath?  ;)

> 1. The P3 has a number of key combinations (press key X+Y to 
> do Z) built into the user interface that I optionally liked 
> to be replaced with a dedicated key. 
> 
> 2. Afaik, the P3 has room for additional keys in the key 
> scanner hardware.

Yep, but only five.
 
> 4. As keycombos are added, to my taste for direct keys 
> changes, I'd like to be able to change the function of the 
> direct keys, by modding the executable myself.

I'm afraid that's not going to happen, for a couple of reasons.
The prime one is that the schematics of P3 are already available, and the
hardware design is reasonably straight forward anyway, so making the
firmware or source available in unprotected form would mean I lose control
of it.
Anyone could start making and selling P3s, and I wouldn't have the resources
to do anything about it.
It's a risk I can't afford to take.
The second reason is that the firmware is almost full anyway, and there is a
very delicate balancing act that has to be performed in relation to internal
register and scratch ram allocation for any change that is made.
I've got a couple of years practice at doing this, and it can still cause me
the occasional hour of head-scratching to get things added efficiently.
Letting the end user tweak the code himself would lead to an unbootable
firmware image probably 9 times out of 10.

But as you know, I'm always open to suggestions for new features.
If there's a dedicated key that you think would be worth adding, and it
doesn't take more than adding an extra term to an if statement or something,
I can allocate them to the remaining slots in the key matrix, and provide
details on how to access them.

Cheers,
Colin f

On Thursday 14 October 2004 19:32, Colin f wrote:
> > 1. The P3 has a number of key combinations (press key
> > X+Y to do Z) built into the user interface that I
> > optionally liked to be replaced with a dedicated key.
> >
> > 2. Afaik, the P3 has room for additional keys in the
> > key scanner hardware.
>
> Yep, but only five.

Mmm I remember many more, but that's probably pots I 
remember, not buttons. Oh well.

>
> > 4. As keycombos are added, to my taste for direct keys
> > changes, I'd like to be able to change the function of
> > the direct keys, by modding the executable myself.
>
> I'm afraid that's not going to happen, for a couple of
> reasons. The prime one is that the schematics of P3 are
> already available, and the hardware design is reasonably
> straight forward anyway, so making the firmware or source
> available in unprotected form would mean I lose control
> of it.
> Anyone could start making and selling P3s, and I wouldn't
> have the resources to do anything about it.
> It's a risk I can't afford to take.

I see, and of course fully respect this. I was thinking of 
patching the *binary* though. That table must be somewhere 
in the compiled version, and all we need is their location 
and a simple script to patch these 16 bytes (and the 
probably the checksum).

> The second reason is that the firmware is almost full
> anyway, and there is a very delicate balancing act that
> has to be performed in relation to internal register and
> scratch ram allocation for any change that is made. I've
> got a couple of years practice at doing this, and it can
> still cause me the occasional hour of head-scratching to
> get things added efficiently. Letting the end user tweak
> the code himself would lead to an unbootable firmware
> image probably 9 times out of 10.

If there's no space, that's simply it. But maybe you were 
thinking about hacking the sources, while I was thinking 
hacking the binary. This way you have full control, without 
having to change the semantics for the OptKeys for every 
user. They can use that script to tweak it to whatever they 
like. I should have been more clear about that, sorry.


>
> But as you know, I'm always open to suggestions for new
> features. If there's a dedicated key that you think would
> be worth adding, and it doesn't take more than adding an
> extra term to an if statement or something, I can
> allocate them to the remaining slots in the key matrix,
> and provide details on how to access them.

Thanks for the offer. I will surely think about that. :)

Cheers
Robert