[PD] HID and timestamp

[Hans-Christoph Steiner]

That is possible, but 20ms is a lot of latency to add to an instrument.  
  I think generally, you'll be better off trying to reduce the latency  
as much as possible, then use a smoothing algorithm to make things less  
glitchy, though smoothing does add some latency.

As for dropping data, if you are using absolute axes, then dropped  
extra data should fine for the most part since the data are just  
position updates.  Whatever you are controlling will end up in the same  
place regardless if it got all of the messages in between. Of course,  
button clicks would have to be handled so that the coords are outputted  
with the click, and really fast movements could cause problems too when  
data is dropped.

With relative axes like mice, its a totally different story, you need  
to have all of the data in order to end up in the same place.

.hc

On Aug 28, 2005, at 7:39 PM, etienne deleflie wrote:

>
> I'm not sure if this logic is correct, but would it not be possible to  
> introduce a delay that is the size of the maximum number of messages  
> sent in one chunk?
>
> for example. If the system spits out on average 4 messages together  
> (every 20 msecs).... then one could introduce a 20msec delay, and then  
>  use the 4 messages' timestamp to define a smaller delay to spit out  
> the individual messages evenly over that 20msec.
>
> It sounds as though the logic forced by the constraints of the system  
> will be: introduce a delay and get a smooth (in time) set of messages,  
> or have no delay and lose some of the data.
>
> etienne
>
>> hello,
>>
>> Am Sonntag 28 August 2005 23:32 schrieb Hans-Christoph Steiner:
>>
>>> Yes, this is an area that needs some work, but its not an easy  
>>> problem
>>> unfortunately.  Have you tried setting the poll time to 2ms?  That's
>>> about as fast as it can go.  Basically, you can't expect smooth data
>>> out of a device or sensor even it the values were coming out one at a
>>> time.  I recommend smoothing the output using averaging or low-pass
>>> filtering.  Try [hid_average] for example.
>>>
>>>
>>
>> one problem with that is that the actual polling intervall is  
>> somewhat defined inside the device itself.
>> an usb endpoint descriptor contains the _maximum_ intervall period  
>> time. this is the guaranteed period after which the device gets  
>> polled.
>>
>> however, this time can also be shorter if possible. the usb spec say  
>> that this is really only the maximum intervall. but is not guaranteed  
>> to be shorter, anyways.
>>
>> now if you have multiple messages that the device has to send, they  
>> will be sent one after each other as long as the bus active for that  
>> device.
>>
>> (on a sidenote:
>> i have found out that i can be that when a device is polled too fast,  
>> the output gets even slower! i am not sure if that is due to libusb i  
>> use, or if that is a general problem on linux.)
>>
>> in case of multi-axis devices, like mice, tablets, etc..., it can be  
>> that two messages come directly after each other. usually that is as  
>> fast the device can send events, and stops only when either there are  
>> no more messages or the current time-slice on the usb is over and the  
>> next device gets polled (by usb itself).
>> this brings me to:
>>
>>
>>> Going forward, it would be a good idea for [hid] to output one value
>>> per cycle when polling absolute axes like what the Wacom gives you.
>>>
>>
>> what do you do when you have multiple messages at once in the  
>> incomming stream? discard all exept the first/last?
>> i think, if a bunch of messages appears at once, they should be sent  
>> at once (in the order they are read).
>>
>>
>>> Its on the TODO list, but I have had little time recently to work on
>>> [hid] since I am working numerous freelance jobs to pay the bills.  I
>>> have applied for a 1 year fellowship to work on this, let's hope I  
>>> get
>>> it.
>>>
>>>
>>
>> wish you best luck!
>>
>>
>>> .hc
>>>
>>>
>>
>> greetings,
>>
>> chris
>>
>>
>> _______________________________________________
>> PD-list at iem.at mailing list
>> UNSUBSCRIBE and account-management ->  
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>>
>
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->  
> http://lists.puredata.info/listinfo/pd-list
>

________________________________________________________________________ 
____

"Information wants to be free."
                                      -Stewart Brand
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2353 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20050828/1d689862/attachment.bin>