[PD] [hid] users poll

[Hans-Christoph Steiner]

On Jun 15, 2005, at 1:23 PM, Mathieu Bouchard wrote:

> On Wed, 15 Jun 2005, Hans-Christoph Steiner wrote:
>> So now that there are some people using [hid], I want to ask a  
>> question about how its working for people, specifically about the use  
>> of symbols rather than integers for the event naming scheme (i.e.  
>> "abs" vs. "2"; "rel_rx" vs. "5", etc.).  It definitely takes more CPU  
>> power to use symbols, so I have two questions:
>> Do you notice the extra CPU load from [hid]?
>> Do you find the symbolic names useful, versus numbers?
>
> I think that as long as integers still can be used, there is no  
> problem with supporting symbols. I mean I've seen cases where the  
> enforcing of symbols means having to use [sprintf] all over the place  
> in a less-than-elegant way.

Integers/floats are not supported in [hid] because that would defeat  
one of the main purposes that inspired me to write it: to have a clean,  
straightforward API.  For example, you probably won't need to use a  
lookup table to understand [route abs_x abs_y abs_throttle] but most  
people would need it for [route 1 3 14].  I can't think of anytime  
where you'd need to use [sprintf] with [hid] data, but please try out  
strange, unorthodox configurations and let me know if the symbol scheme  
causes problems.  Its an experiment, every HID API I have seen uses  
integers, but  almost all are aimed at people who think in terms of  
struct, io_service_t, ioctl, etc.

I am planning on writing [darwinhid], [windowshid], and [linuxhid],  
which will output the data straight from the OS, i.e. integers. Those  
objects are for getting data from very esoteric devices, but I would  
discourage using them for anything but the situations where [hid] would  
not work.

> Comparing symbols is fast. [route foo bar baz] is just as fast as  
> [route 55 242 666]. This is because gensym() ensures that if two  
> symbols refer to the same text then they necessarily have the same  
> pointer value. This is a standard: LISP/Smalltalk/Ruby/etc all do it  
> the same.
>
> Actually comparing symbols is much faster than comparing floats, if  
> you run Pd on a 386 or on a PDA.

That good to know. I was thinking strcmp() versus ==. That makes me  
very happy.  So comparing symbols in Pd is basically a == operation  
using the pointer integers, right?  I was thinking I needed to keep  
these symbols as short as possible for efficiency's sake.  Now I can  
happily eliminate the unixy abbrvs:

   		syn = sync
		snd = sound
		msc = misc
		rep = repeat
		pwr = power

These would probably be too long tho:

		abs = absolute
		rel = relative
		btn = button
		ff = force_feedback

If you ever feel like checking out my [hid] code, matju, I'd love  
advice on optimization.  Since it can run up to once every 1ms,  
optimization is key.

.hc

>
> Comparing strings would be slower but Pd doesn't have strings.
>
>
>
> (I haven't used [hid] yet though.)
>
> ,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow |
> | The Diagram is the Program tm| | ,-o-------------o--------------o-.
> `-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) |
>   | téléphone:+1.514.383.3801`---' `-o-- http://artengine.ca/matju -'

________________________________________________________________________ 
____

If you are not part of the solution, you are part of the problem.
                                                                          
                            - Eldridge Cleaver
-------------- 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/20050615/33cc4df0/attachment.bin>