Daniel Grigsby

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!

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!

hid-conflict-btw-max-and-supercollider

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?

today this came up also on the SuperCollider mailing list:

http://www.nabble.com/problem-with-HID-access-while-Max-MSP-is-running-tf286

But it works for me without problems - with USB controllers, mouse or Apple

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

--------------------------------------------------

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?

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 Bartetzki 
http://www.bartetzki.de
mailto:andre@bartetzki.de

Tel   +49-(0)30-92375877
VoIP  +49-(0)30-38108677
Fax   +49-(0)30-38108678

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?

a little tablet controller (macally icecad),

as well as with a mouse and the apple remote.

In Supercollider I've used only the language side HIDDeviceService class,

but not the HIDControl ugen on the server.

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?

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:

http://www.cnmat.berkeley.edu/MAX/downloads/

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:

yeah, that's agood idea. Although, do you think the added latency would be an issue? How much latency might this add?

Just checking: the actual OSC network objects are obsolete under Mach- 

> http://www.cnmat.berkeley.edu/MAX/downloads/

Just checking: the actual OSC network objects are obsolete under Mach- 
O, correct?

> 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?...)

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


I notice the same behaviour when using HIDexplorer [1] instead of SC3.

The behaviour disappears when removing the "hi" object from the Max externals 

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 

Maybe whoever wrote the "hi" object can comment on how it is implemented?

http://www.create.ucsb.edu/~dano/CUI/HIDexplorer.zip

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?

[1] http://www.create.ucsb.edu/~dano/CUI/HIDexplorer.zip


Es war der 24.12.2006 20:17 Uhr, als Daniel Grigsby nicht widerstehen

> 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

> 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

Again, no problem on my system (OS 10.4.8 on Intel, Max 4.6.2 and Max

Max with [hi], HIDExplorer and SC3 do not disturb each other. I can poll a

HID controller with these three at the same time.

Are there other (older) hi-objects in your Max search paths?

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?

Quote: nick rothwell / cassiel wrote on Sat, 23 December 2006 03:40

> Just checking: the actual OSC network objects are obsolete under Mach- 

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.

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.

> 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 

> 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.)

HID conflict btw MAx and SuperCollider