@atarikai said:

I know I can target individual mice and keyboards with [hid] but is there a way to keep the linux Xserver from using them as input?

Old thread, I know, but for anyone else who stumbles upon it...

I think what you want is the `xinput` command. First, find out what devices you have:

$ xinput list
⎡ Virtual core pointer                        id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ Logitech USB Trackball                    id=8    [slave  pointer  (2)]
⎜   ↳ Wacom Intuos3 6x8 eraser                  id=9    [slave  pointer  (2)]
⎜   ↳ Wacom Intuos3 6x8 cursor                  id=10   [slave  pointer  (2)]
⎜   ↳ Wacom Intuos3 6x8                         id=11   [slave  pointer  (2)]
⎜   ↳ Logitech USB-PS/2 Optical Mouse           id=12   [slave  pointer  (2)]
⎣ Virtual core keyboard                       id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard                 id=5    [slave  keyboard (3)]
    ↳ Power Button                                id=6    [slave  keyboard (3)]
    ↳ Power Button                                id=7    [slave  keyboard (3)]
    ↳ Unicomp  Endura Keyboard                    id=13   [slave  keyboard (3)]

You can detach the device, preventing it from controlling the X pointer/keyboard, by using `xinput float`, e.g.

$ xinput float "Logitech USB Trackball"

(or use its numeric ID.) The control stream will still come through via HID. In fact, you can use `xinput` to access the control stream as formatted text as well:

$ xinput test "Logitech USB Trackball"
motion a[0]=1176 a[1]=607 
motion a[0]=1177 a[1]=608 
motion a[0]=1177 a[1]=609 
motion a[0]=1177 a[1]=610 
button press   1 
button release 1

The `xidump` command from the Linux Wacom Project can be used in a similar way.

To reattach the floated device and regain control of the X pointer:

$ xinput reattach "Logitech USB Trackball" "Virtual core pointer"

You can detach keyboard devices as well, but watch for the Enter key getting (virtually) stuck!

Hello,

Thanks for your help. Ok I see how to operate.

I'm wondering if it's possible to do such a Bome's MIDI translator, or MIDI stroke-like patch : with those two, the keyboard shortcut is sent "somewhere in the system", i.e. in a layer that is directly accessible by any active application. I don't think they use specific API for specific applications. This is my feeling as I used them with various applications without any additional stuff to install.
Thus do you think it will be possible to make an API between the MIDI->keyboard patch and any application ? an API taking the keyboard order, and putting it in "basic system layer=keyboard entrance" to where any application is constantly listening to ?
(you probably understand know that I'm not informatician... ).

Thanks bye

My goal is to play the notes of the Kaossilator Pro from an external midi keyboard.
The problem is that the Kaossilator Pro (Korg) can receive CC messages ONLY for the PadX - PadY controls. It does not understand midi notes.
So I decided to try to face that problem with puredata (it is my very first patch...)
I want to receive the midi in notes from my keyboard and convert them to the corresponding CC values and send them to the kaos pro.
In my settings, the kaos receives pad X values on CC#26. So, in order to play the notes, I have to send the following values:
1st note: 0, 2nd note: 10, 3rd note: 19, 4th note: 27, 36, 44, 53, 61, 70, 78, 87, 95, 104, 112 and 121, for the last note (with a 2 octaves scheme set on the kaos).

If I set the kaos in C major, the notes would be:
C4: 0, D4: 10, E4: 19, F4: 27, G4: 36, A4: 44, B4: 53,
C5: 61, D5: 70, E5: 78, F5: 87, G5: 95, A5: 104, B5: 112
C6: 121

The algorithm (in C++ style) is easy:

switch(midi note received from keyboard on Channel 1)
{
case 60: // Note 1 = C octave4 (in C major)
send value 0 to CC#26 on Channel 1;
break;
case 62: // Note 2 = D octave4 (in C major)
send value 10 to CC#26 on Channel 1;
break;
case 64: // Note 3 = E octave4 (in C major)
send value 19 to CC#26 on Channel 1;
break;
case 65: // Note 4 = F octave4 (in C major)
send value 27 to CC#26 on Channel 1;
break;
case 67: // Note 5 = G octave4 (in C major)
send value 36 to CC#26 on Channel 1;
break;
[...]
case 84: // Note 15 = C octave 6 (in C major)
send value 121 to CC#26 on Channel 1;
break;
default:
do nothing;
}
send midi note velocity to CC#27 on channel 1;

The problem I face is with the velocity.
For example, if I play one note on the keyboard, the patch sends the correct value to CC26 and also sends the velocity to CC27. If I release, velocity is set to zero (on CC27) and the sounds stops. That's OK.
BUT if I play one note(let's say a C), hold it, play another one (let's say D), then release C (and keep D on), the release of C will send a zero velocity signal on CC27 and sound will stop, even if D is still pressed... as a newbie with puredata, I don't really know how to face that issue. Does anyone have a solution for that?
use a counter maybe?
Furthermore, I have absolutely no idea whether there is a much easier way to implement a switch/case statement with puredata or if what I did is OK. The patch is attached.
Thanks in advance!

http://www.pdpatchrepo.info/hurleur/KaosPatch.pd

Hi there, Bonjour,

I've got a simple switch circuit hooked up to PD via my arduino. The switch is supposed to change the RGBcolour of the gemwin. The PD2Arduino part works fine, but I am having troubles with my [gemwin] patch.

I have a projector (with a native res of 1024 x 768, 70Hz) connected via VGA to my PowerBook G4 as a virtual desktop. Not in mirror mode.

On my iMac (intel duo core with PD-extended 0.41.4), this patch works great.

However, on the computer I need to use, my PowerBook G4 (power pc with PD -extended 0.41.4), the GEM window opens, but is all white and unresponsive. The only error message I get in the G4's Pd window is "GemWindow Activate err=0" , but I get that message in the Pd window of my iMac as well, and the patch works fine there.

In trying to troubleshoot the probelm, I have found that my G4 creates a responsive [gemwin] up until the "dimen 700 700". After that, all white. And it kind seems to mess up PD in a larger way because if I cose the patch, and open the [gemwin] help file, I keep getting a blank, white window. I have to completely restart PD in order to get even the [gemwin] helpfile working.

I've tried doing fullscreen on both the G4's desktop and the projector desktop and the same problem occurs, the [gemwin] is all white.

I've tried sending the "reset" message to the [gemwin] object to clear it's cache or whatever, still nothing.

There's no other [gemwin] or gem patch going on in the background.

I 've attached my patch to this post, if anyone want a give it a try. Thanks for any help you can offer. Merci d'avance!

http://www.pdpatchrepo.info/hurleur/random_colour.pd

You should be able to daisy chain MIDI keyboards using the Thru inputs. If each one is on a separate MIDI channel then you should be able to have sixteen keyboards connect to one MIDI input on your computer. You could use a MIDI to USB converter if you need it (most MIDI keyboards these days should have a USB out, though). So if you have two USB ports, that should be enough. Also, if you have keyboards with a wide enough range, you might be able to save a few bucks and just split the keyboard in Pd via [moses] so one kid plays on the low keys and another plays on the highs. Or maybe you can find a creative way to have one play the keys while the other fiddles the knobs/sliders.

I don't really know the best way of getting 20 headphone outs without using an expensive headphone distribution amp. Maybe someone else has an idea there. But as far as [dac~] is concerned, you can give it arguments for each output. So [dac~ 1 2 3 4] will create four inlets corresponding to the first four audio output channels.

hi guys! so i've had an oxygen8 for a few years now and i see them everywhere, so i'm sharing this handy little patch i made.

basically you're stuck with 8 knobs, and two sliders (modwheel and data entry). all this patch really does is takes the keyboard's input, numbers those 8 knobs and 2 sliders in sets of 10, and lets you switch between those sets with the hradio for up to 120 different controller values. the key input is passed straight through so even when you switch between various controls you can play the keyboard consistently.

even if you don't have an oxygen8, this patch will give you a little selfcontained set of sliders that you can use as a midi controller... so it's still useful for when you're not at home with your keyboard, or if you don't even have one.

basically all this patch does is take those 10 controls and lets you switch between 12 sets of them. it's useful for me in ableton so when i need to map more parameters than i have knobs for, i can assign more, and the numbering system is much easier to stay on top of than the default control values for those knobs (it's like 17, 80, 74, no consistency it seems).

on linux you should be able to jack the keyboard to pd's midi in, then jack the output to wherever you want. i'm currently on windows and i select usb keyboard in for input, and loopbe for output.

the numbers do nothing but change when you switch the hradio - the sliders are the corresponding controls (with the mod wheel as slider 9 and the data entry knob as slider 10).

come to think of it i don't think i tested the pitch bend wheel, i've been using this patch almost entirely for parameter controlling and not playing the oxygen8 notes at all. [notein] is patched directly into [noteout]

any questions/comments/ideas please, post them. this is a real quick patch i put together that worked almost better than i wanted it to but it can be very expanded upon. i was going to add symbols so you could tag/name all 120 controls but i was having trouble figuring out a way to store them and recall them, and send/receive to the symbols... so i just scrapped that.

basically all i do is make a tiny pd window and make [SCET], and just have that sitting at the bottom of the screen under my DAW (in this case ableton).

i haven't run into any conflicts yet for the most part but it's possible the controller numbering system might conflict with certain apps/synths/etc.

cheers guys!

http://www.pdpatchrepo.info/hurleur/SCET.pd

i see...well, no you are definitely able to modify your movie/gemwin via the patch, while it is playing.

sounds like you have your movie (or rather your gemwin) filling the whole screen rather than being windowed?

if you send the message [fullscreen 0( to [gemwin], before creating the gemwin, you get a separate window. you can always define position, size and look of this window.

check out examples/Gem/advanced/15.GemWin.pd in the help patches for all the nice things you can do to the gemwin.

in osx 10.4

To access Keyboard Viewer:

1. Choose Apple menu > System Preferences and click International.
2. Click Input Menu, then select the checkbox next to Keyboard Viewer.
3. Select the On checkbox next to the language whose keyboard layout you want to use.
4. Choose Show Keyboard Viewer from the Input menu on the right side of the menu bar (the one that looks like a flag).

This topic is a total joke.
There is a keyboard viewer and a character viewer in OS X. the character viewer displays all characters in the world where you can copy/paste them into your current document and the keyboard viewer shows where on your (local) keyboard that character is in any font. You can display both apps in the menu bar if only you activate (click) to do so in the keyboard control panel.
Seriously, if you don't know how to use your computer, how will you be able to do anything with it?

Hi flo, and thanks for your answer+patch! I'll open your patch as soon as I write this post.
-No, I don't want to build a 9*9 gemwin. I said so, only to semplify my example...
000000000
111111111
etc.
Infact I think to use a standard 500*500 gemwin.
You asked to me "where the video is shown": my idea is to show the video onto gemwin, but to show only the right half of the entire video; while in left half of the video you should see the "overlap" and translation of the columns of pixels snapped every 40ms. That means...I don't try to resize the video into the right half of the gemwin. I try to show the entire video in the entire gemwin, but where in the left half of gemwin you can also see these "echoes" of the central vertical axis.