Thanks. Maybe will remap 123 & 125... or switch to a different assignment of notes to keys, ie instead of zxcv being notes c d e f, have zxcvb => c d e f g. Four octaves instead of five, but that's 8 octaves with the caps lock.

[key] does not (on my ubuntu laptop) receive either '{' or '}' (ascii 123 or 125)

'[' and ']' -- yes. All other keys I'd expect, yes. But with the shift key down, nothing from those same two particular keys.

This is only a problem in the extreme high register of a text-keyboard organ but... it puzzles me a lot!

The pd keyboard-mapping music input is working fine; it's the csound6~ file I put together to produce the sounds (& control note-lengths) that has the bug. Nice effect, though..foo.mp3

You'll want something like this (if I've gotten it right) to use the keymap table with midi;
instructions should be (?) in the subpatch pd how-to-use...

scalemapw.pd

Oops, sorry!

ro.pd

[A simple little gadget I thought I'd stashed in pd ro-file, sorry. Lets me connect some wires in a non-obtrusive way and take the final value out the right outlet.]

This could be used to assign midi notes to keys either for producing files or performing, using some other input to handle velocities etc. [I expect to use a joystick for volume, tempo -- and to add a smaller table to associate these numbers (mod 7) with whichever scale I'm using at the moment-- with joystick buttons to modulate in real time...]

ie You can use any arrangement of keys you find useful, not necessarily chromatic, not necessarily linear!

If the subpatch doesn't load, please ask!
keymapw.pd

I needed to rewrite this after I lost my backups installing a new system. Here's the improved version:numberin.pd

You can now enter the number and read it before sending it out.

Save the contents of the subpatch as 'ro.pd' before using. [Clumsy, but fits the space better than any object with a longer name.]

Copying & pasting here changed some things, '' somehow turned to' .' (or vanished? Anyway, 'p3.5' in the adelL line became p3.5 ) [original setting for the delay time to left ear.]

In the following line, likewise, 'p3.125' is an erroneous copy of 'p3*.125' throughout. That is, I changed this from a delay increasing and decreasing once over a minute, to one doing this four times (8 segments) in that same minute.

Simple patch with csoundapi running an example from the canonical csound manual (#267, fluidOut) and a speedup of the delay changes to the right ear;
...
instr 99

imvol init 4
asigl, asigr fluidOut giengine1 ;add a stereo flanger
adelL linseg 0, p3*.5, 0.02, p3*.5, 0 ;max delay time =20ms
adelR linseg 0.02, p3*.125, 0, p3*.125, 0.02, p3*.125, 0, p3*.125, 0.02, p3*.125, 0, p3*.125, 0.02, p3*.125, 0, p3*.125, 0.02 ;max delay time =20ms <---[changed this]
asigL flanger asigl, adelL, .9
asigR flanger asigr, adelR, .9
outs asigLimvol, asigRimvol
endin

Silly, fun -- might be a usable effect somewhere? (Reminds me of the hardware synthesizer that used to get impossible values in some of its settings.)
weirdstuff.mp3

The bug in the logical design: it should have been like this:
cursormv.pd

The whole patch (so far): movething.pd