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

@forrest There's still a bug in this patch... constant acceleration, no wonder I lose my cursor.

Anyway, more later.

@forrest As someone else was asking about on another thread:

You can easily crash your pd if you haven't fed the right numbers into the number box[es -- (One for every joystick one's prehensile toes may be working)] I'm using to open the [hid] ...

So for anyone seriously using the patch I just sent -- unless you're using two sticks you can get rid of much of it. And then (because the system may well assign different numbers the next time you boot) -- First run:

{print(
|
[hid]

to get the right number[s]

@az Well, audio is messy enough and I can't get csoundapi to work on my 64 pd-extended, so I'm unlikely to be using gem.

But it looks somewhat like what I'm getting to...

movething.pd

Main trouble with that: Sending 'delta $1 0' too seldom makes for slow response; too often loses my little wandering cvn "cursor" somewhere off-screen. Still tinkering with this.

As usual, having to find out my own answers... Some of my thrift store joysicks were simply clunky, some were lacking the right gameport->usb converter. With that fixed, the numbers are reasonably steady and the main problem is using them to move a gui pointer of some sort.

Best so far -- Make a [canvas] and tinker with the properties to have it [say] receive messages as something like 'joyrcv' Then, hook your |hid| outlets to |route abs_x abs_y etc] into a message like
| ; (
| joyrcv pos $1 $2 (

and your canvas will move to the coordinates from the joystick every time you trigger that message. Also, while you're changing the properties, you can color code the canvas and shrink it to a nice portable size like 3X3. Can also make the message read:
;
joyrcv delta $1 $2 -- to simply move that canvas relative to its current position. But to use that I'd need to convert the numbers to a different range, like say dividing and subtracting to get them into low negative, 0, and low positive values.

I find it working pretty well, running two joysticks on it so far.

What you want to do is send a |print( message to the |hid| itself and read the console:
for lines like:

"Device 12:'Logitech...' " --

except yours would say 'Device [?]:'Griffin Powermate' [something] " and that number [?] is
the one you'd need to send to the hradio widget on the help patch.

Instead of an hradio widget I've got:

[bang]
|
[12] ---- (number2 box set to init to number 12, for my gadget)
|
[pd hidstuff] --- (a subpatch where I've put the ugly stuff):

|inlet|
|
|
|bang| |open $1(
| |
|toggle| |
| /
| /
|/
|hid|

The message opens the device at the number you've provided
and the toggle keeps the |hid| object receiving its readings.

My experience of opening the wrong number device, so far -- is that this is probably harmless unless you use the mouse to open the mouse, which then crashes everything [?]

I've set up a used joystick ('logitech wingman extreme digital 3d') on a gameport-to-usb converter, using the patch from flossmanuls -- and printed what [hid] is getting from it...

All the buttons, stick position & hat switch etc show up in the message. abs_x and abs_y give me values ~124-128, which don't change.

Briefly I was getting changes in the x value; they didn't leave that range of initial values, and they didn't seem to have anything to do with movements of the stick. Likewise I get '1' for btn_0 etc and '0' for btn_5 - 8.

Obviously the cord must be intact -- but nothing I do to any of the controls is getting through.

?

For now I've 'solved' my joystick problem via getting a diferent, working joystick.

jstest-gtk shows numbers on two axes running from 0 to -32000

and [hid] gives me the same inputs, 'abs_x' and 'abs_y' as numbers in the range 0-256.

WIth jstest the numbers naturally take some big jumps, but seem consistent with the joystick motion.

With [hid] the values jerk about fairly randomly -- These are maybe the original numbers mod 256 of something?

Is there anything available to bring in the original raw data so I can put it into more linear order?

I think what I need next is some documentation on what commands this can digest... and what it will do with them?

?

Do you know of any built-in (or extension) method to recognize when the mouse pointer is passing over one of a group of cvn rectangles (without necessarily pushing buttons?)

Also, any means of turning off (or diverting) the normal response to a mouse-button push, ie so that these could be used as 'sustain pedal' and/or 'louder/softer' or 'up-to-the-next'/'down-to-the-next' controls?

(ie I'm putting together a design in which I want the mouse pointer to select a particular note-name, playing that note in the octave immediately above or below the last note played. There'd be clusters of cvn's in different colors, each arranged to facilitate playing in a particular key -- and each positioned near the most convenient modulation possibilities.)

?

_

??_

I've been sending midi messages to csoundapi~, running them via csound Fluid opcodes, playing them from the audio outlets on the csoundapi~ object.

This works, but seems a trifle roundabout.

I find old references to a fluid~ extension object, but no such thing actually available.

Was there some better way to accomplish the same thing?