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
Message
Re: [analogue-sequencer] Direct key table option
2004-10-15 by Robert van der Kamp
Attachments
- No local attachments were found for this message.