Announcement

Collapse
No announcement yet.

Wacom: 2 questions

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Wacom: 2 questions



    Hello,


    1. What is the best solution to connect a Wacom (Intuos 3 A5) to Max/MSP 5 ? A HID virtual device seems more responsive than OSC (and many packets seems to be dropped even using localhost). Can anyone confirm this ?


    2. Using the HID virtual device for X, Y (assigned to joystick1 X and Y), I see that the X and Y scales are not reaching the extreme values : the X axis goes from 9 to 65521 and the Y axis goes from 12 to 65535. Shouldn't the scales go from 0 to 65535 ?


    Thank you in advance.


    Amundsen


  • #2


    Hi Amundsen,


    1. At the network level, I don't see why packets would be dropped on a local link. However, I had some reports from some users that the updreceive object was not very robust. So, the "dropped packets" you are observing is really at the Max level. Have you tried to activate the overdrive to see if that changes results?


    Anyway, I can guarantee that if you use OSC with a good receiver, you won't have any dropped packets. Perhaps you could try the CNMAT extensions to see if that helps.


    Also, I would like to add that the Wacom tablet is a bit intensive in terms of events rate of sending. That is a pretty sensitive tool really.


    2. That is correct, I can observe the same thing, but that is not related to HID. To see that, go in the scalings page, and change the Output max scaling to 65535. I've checked the code and it correctly handles the 16 bits values sent from the Wacom driver, so I think what you observe is just a little trim of space on the borders that is not sensitive to the tool.


    Best,

    Cam

    Comment


    • #3


      Hello,


      1. I am already in overdrive mode. Maybe I should try an alternative to udpreceive ?


      2. You're right, I do also loose a small border when using the wacom external in Max.


      Best,


      Amundsen

      Comment


      • #4


        The reason why udpreceive could drop packets is because it is using a non-blocking input to make sure processing won't be stopped if a packet takes too long to receive.


        I have not found an alternative to this object, but on udpreceive's documentation page, I have read that you can send the message "maxqueuesize" followed by an integer to specify the length of the receive queue. The default is 2048, so I would start by doubling this value to 4096 and see if dropping still occurs. This value seems to be related to your computer's processing power, and the complexity of the Max patch.


        Maybe you should give it a try. Please report back your findings!

        Comment

        Working...
        X