Hi all,

I'm having a strange problem with arrays. I'm using [tabread] to read from an array, and every read from an odd-numbered index is returning 0. It's a bit like the array data is "double-spaced", i.e. I have to double the index to get the index I actually want.

For example, if I store {1, 2, 3, 4, 5, 6, 7}, I get back {1, 0, 2, 0, 3, 0, 4}. The array graph looks normal, and examining the array as a list looks fine as well.

On saving and reloading the patch, however, the array graph changes, showing every second value as 0 and the array contents are spread out. The list view also has a 0 at all the odd-numbered indexes. What's worse, [tabread]ing the array contents reveals that it's now quadruple-spaced, i.e. {1, 0, 0, 0, 2, 0, 0}!

I used Pd recently on Windows XP and Mac OS X and don't remember arrays behaving like this. I'm using Pd 0.40.2, compiled from source, on Gentoo GNU/Linux, kernel 2.6.19-gentoo-r5 for AMD64. I was using 0.39 when I first noticed the problem and grabbed the latest source. Could it perhaps be a 64-bit thing?

Thanks for any help you can offer,
screwtop

@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!

Hi Simon,

Fun idea - yes, it can be done (I found it usable on a wired Ethernet LAN). I'd recommend using UDP mode for the netsend/netreceive, since you're dealing with events and you want the lowest latency.

In the netreceive help patch, note that the "send foo" stuff is actually a message box, it's not a send object - that's why your receive doesn't see anything. Open the netsend and netreceive help patches, then click the "connect localhost 3001" message for netsend. Then, twiddle the number in the netsend patch and you should see the messages printed to the main Pd window.

If you hook up a number box to the netreceive's output and delete the "foo" from the netsend's message, you should see the number changing in the netreceive patch itself.

Hope this helps!

The metro's input is the tick period in milliseconds, so, yes, lower number = faster. You can convert from BPM to milliseconds using [expr 60000 / $f1]. In general, you convert between frequency and period by taking the reciprocal, i.e. F = 1 / P, and P = 1 / F.

I feel the same on the math front, BTW. But fun stuff like this is a pretty good incentive to learn.

Nope, spoke too soon: arrays work within the patch, but when saved and reloaded it is corrupted again.

However, that SourceForge page now contains a note that this seems to be fixed in version 0.41.

...and here's a simple patch to show how to use it [attached].

http://www.pdpatchrepo.info/hurleur/metronome-test.pd

I have a similar story. I put together a prototype based around [metro] that outputs basically musical timecode as bars, beats, sub-beats, and ticks. You specify the tempo in BPM and it does the rest. The important formula is:

beat period in ms = 60,000 / BPM

(there are 60,000 ms in 1 min, and period = 1 / frequency)

It's pretty rough at the moment but usable (changing the number of ticks per sub-beat on the fly isn't as smooth as I'd like). It seemed like a good first step in trying to build a sequencer. Let me see if I can attach it...

Feel free to use and adapt as you wish. It's a good idea to use a number with many divisors (e.g. 6, 12, 24) for ticks/sub-beat, so you can get duplets, triplets, quadruplets, etc.

Hope this helps!

screwtop

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

Ah-ha:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1532439&group_id=55736

Downloaded the patch, applied to 0.40-2 without any problems, arrays now work as advertised.

Sorry for the noise - hope this might help others.

screwtop

I had a look around the code, and I think it is a 64-bit issue. Reading the comments in src/m_pd.h, there seem to be some assumptions made about storage sizes, e.g. long is the size of a pointer, float is at most the same size.

I guess using double instead of float would satisfy that constraint (64-bit long is the same size as a 64-bit pointer), right? I don't like the chances of that being a simple clean change to make, though...surely someone else must have seen this if it really is a problem on AMD64...so is it just me?

Cheers,
screwtop