HID conflict btw MAx and SuperCollider
I have a USB HID device that needs to be accessed by both Max/Msp and Supercollider at the same time. But when I start Max/MSP, SuperCollider stops getting data from HID. Subsequently, quiting Max/Msp doesn't re-open the HID connection to SuperCollider. I can only get data into SuperCollider after replugging the USB device. Has anyone had the same problem? Are there any solutions?
Also, how exactly does Max/Msp deal with HID? A guess would be that it "grabs" the HID devices somehow, and blocks it, even when it is not accessing the HID devices.
More insight on this would be really appreciated!
Thanks.
Es war der 21.12.2006 23:26 Uhr, als Daniel Grigsby nicht widerstehen
konnte, folgende Gedanken dem Netz anzuvertrauen:
>
> I have a USB HID device that needs to be accessed by both Max/Msp and
> Supercollider at the same time. But when I start Max/MSP, SuperCollider stops
> getting data from HID. Subsequently, quiting Max/Msp doesn't re-open the HID
> connection to SuperCollider. I can only get data into SuperCollider after
> replugging the USB device. Has anyone had the same problem?
Hi Daniel,
today this came up also on the SuperCollider mailing list:
http://www.nabble.com/problem-with-HID-access-while-Max-MSP-is-running-tf286
4530.html
But it works for me without problems - with USB controllers, mouse or Apple
Remote.
Maybe this depends on the platform and/or the versions?
I have Max 4.6.2, SC Wesleyan build (11.30), MacBookPro OS 10.4.8
Andre
--------------------------------------------------
Andre Bartetzki
http://www.bartetzki.de
mailto:andre@bartetzki.de
Tel +49-(0)30-92375877
VoIP +49-(0)30-38108677
Fax +49-(0)30-38108678
Skype bartetzki
--------------------------------------------------
what kind of usb controllers this has worked with? Anything homemade?
Es war der 22.12.2006 4:29 Uhr, als Daniel Grigsby nicht widerstehen konnte,
folgende Gedanken dem Netz anzuvertrauen:
>
> what kind of usb controllers this has worked with? Anything homemade?
It works here with
a little tablet controller (macally icecad),
a gameport-USB (joystick) adaptor,
a keypad/joystick controller (xkeys.com)
as well as with a mouse and the apple remote.
Nothing homemade.
In Supercollider I've used only the language side HIDDeviceService class,
but not the HIDControl ugen on the server.
Maybe that's the point?
Andre
--------------------------------------------------
Andre Bartetzki
http://www.bartetzki.de
mailto:andre@bartetzki.de
Tel +49-(0)30-92375877
VoIP +49-(0)30-38108677
Fax +49-(0)30-38108678
Skype bartetzki
--------------------------------------------------
Quote: Daniel Grigsby wrote on Thu, 21 December 2006 14:26
----------------------------------------------------
> I have a USB HID device that needs to be accessed by both Max/Msp and Supercollider at the same time. But when I start Max/MSP, SuperCollider stops getting data from HID. Subsequently, quiting Max/Msp doesn't re-open the HID connection to SuperCollider. I can only get data into SuperCollider after replugging the USB device. Has anyone had the same problem? Are there any solutions?
As a workaround, you could send the data you are getting into Max to SuperCollider using OSC. Try lp.osc. No, wait a minute, the objects are here:
mz
yeah, that's agood idea. Although, do you think the added latency would be an issue? How much latency might this add?
On 22 Dec 2006, at 22:20, mzed wrote:
Just checking: the actual OSC network objects are obsolete under Mach-
O, correct?
-- N.
Daniel Grigsby wrote:
> yeah, that's agood idea. Although, do you think the added latency
> would be an issue? How much latency might this add?
The polling interval of hi. If SC is not polling, but just sending
buttons immediately, I'd do it the other way around.
If you reffered to latency with OSC, I guess its less than microseconds
or on other words practically doesn't exist... (Why should it?...)
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
thanks for all the comments.
Here's some more details on the problem:
I notice the same behaviour when using HIDexplorer [1] instead of SC3.
The behaviour disappears when removing the "hi" object from the Max externals
folder.
I have a strong impression that the "hi" object is "grabbing" the HID devices
somehow, not letting the data through to other applications, and doing this
at startup of Max (so no patch is loaded, and the "hi" object is not used at
all...)
Maybe whoever wrote the "hi" object can comment on how it is implemented?
Es war der 24.12.2006 20:17 Uhr, als Daniel Grigsby nicht widerstehen
konnte, folgende Gedanken dem Netz anzuvertrauen:
>
> thanks for all the comments.
>
> Here's some more details on the problem:
>
> I notice the same behaviour when using HIDexplorer [1] instead of SC3.
>
> The behaviour disappears when removing the "hi" object from the Max externals
> folder.
> I have a strong impression that the "hi" object is "grabbing" the HID devices
> somehow, not letting the data through to other applications, and doing this
> at startup of Max (so no patch is loaded, and the "hi" object is not used at
> all...)
Again, no problem on my system (OS 10.4.8 on Intel, Max 4.6.2 and Max
4.5.7).
Max with [hi], HIDExplorer and SC3 do not disturb each other. I can poll a
HID controller with these three at the same time.
Do you have the latest version of [hi]?
Are there other (older) hi-objects in your Max search paths?
Andre
--------------------------------------------------
Andre Bartetzki
http://www.bartetzki.de
mailto:andre@bartetzki.de
Tel +49-(0)30-92375877
VoIP +49-(0)30-38108677
Fax +49-(0)30-38108678
Skype bartetzki
--------------------------------------------------
Quote: nick rothwell / cassiel wrote on Sat, 23 December 2006 03:40
----------------------------------------------------
>
> On 22 Dec 2006, at 22:20, mzed wrote:
>
> > http://www.cnmat.berkeley.edu/MAX/downloads/
>
> Just checking: the actual OSC network objects are obsolete under Mach-
> O, correct?
>
> -- N.
>
>
----------------------------------------------------
Right. We're not supporting otudp anymore, in favor of udpsend and udpreceive that come with Max 4.6 and is downloadable for max 4.5. They're just a vehicle, though. OpenSoundContol (the object and the protocol) are certainly supported.
mz
On 25 Dec 2006, at 01:16, mzed wrote:
> Right. We're not supporting otudp anymore, in favor of udpsend and
> udpreceive that come with Max 4.6 and is downloadable for max 4.5.
That's what I thought - thanks for the clarification. (I'm working
with a group using Max 4.5 on PPC, while I have 4.6 on a MacBook Pro,
so I'm trying to work out a way of keeping the CVS codebase common
between them.)
-- N.
thanks for all the info everyone.
daniel.