Forums > MaxMSP

rebuilding hi device list

May 23, 2007 | 7:27 pm

Is it possible to rebuild the hi device list in a way that will recognise devices that have been plugged in while Max is already running.

At the moment I can only get devices into the list if they were plugged in before Max was launched – this can cause problems sometimes.

Cheers

Nick


May 23, 2007 | 8:19 pm

For me (WinXPpro SP2) I simply have to send "menu" to the HI input to get a new listing after plugging in a USB device.


May 23, 2007 | 9:43 pm

Thanks for that info – I will be passing this patch onto someone on a windows machine, so it should be robust for them.

I’m on Mac, and the list doesn’t change if the devices are changed and menu is sent to the hi object.

Also if I create a hi object in a patch and fill a menu from it, then change whats plugged in and open the hi help patch, when I populate its menu it gives me the list of what was plugged in when the original hi in the patch was queried too.

Only way I have found so far is to quit and relaunch Max.

Anyone else on a Mac getting this?

Cheers

Nick


May 23, 2007 | 10:10 pm

On 23 May 2007, at 22:43, nick wrote:
>
> Only way I have found so far is to quit and relaunch Max.
>
> Anyone else on a Mac getting this?
>
hi has always been like this. I vaguely remember someone posting the
reason why (so you might find the old thread in the archive). It
would be really wonderful if something _could be done about this –
it’s a pain having to restart max if you forget to plug in the usb
device that you absolutely need in a performance. I’m also concerned
that if I provide my software to someone else, they will consider
this to be a bug.

I have another vague memory ( all my memories are getting like that)
that there may be a solution using scripting – perhaps re-
instantiating the hi object using a script will cause the new usb
device to be seen???? (Show s how much scripting I’ve done …)

David


May 24, 2007 | 8:06 am

David Stevens wrote:
>
> On 23 May 2007, at 22:43, nick wrote:
>>
>> Only way I have found so far is to quit and relaunch Max.
>>
>> Anyone else on a Mac getting this?
>>
> hi has always been like this. I vaguely remember someone posting the
> reason why (so you might find the old thread in the archive). It would
> be really wonderful if something _could be done about this – it’s a pain
> having to restart max if you forget to plug in the usb device that you
> absolutely need in a performance. I’m also concerned that if I provide
> my software to someone else, they will consider this to be a bug.
>
> I have another vague memory ( all my memories are getting like that)
> that there may be a solution using scripting – perhaps re-instantiating
> the hi object using a script will cause the new usb device to be
> seen???? (Show s how much scripting I’ve done …)

I don’t know whether this is still true for [hi] in Max 4.6, but at
least in 4.5 it seemed it used Apple’s "HID Utilities". These utilities
are a wrapper around the real (lower-level) HID code and maintain a
device list. There is a function to rebuild the device list, but….
from my own experiments there are two problems with that:

1) it takes quite some time to execute, so in order to be able to call
it while Max is running you’d have to execute it in a separate thread
(there is none so far in [hi])

2) imagine you rebuild the device list while a device is open, it’s
position in the list might change… so building something that updates
the list without affecting currently ongoing data transfers is quite tricky.

All this could be done, but probably not using HID Utilities. That’s why
my [hid] object is still not ready for Mac. The Windows version rebuilds
the device list automatically whenever you plug a device in or out.
On Saturday, June 9 there will be a poster presentation at NIME
conference dealing witht this and some more HID problems, mybe some C74
guys should go there… :-)

Olaf


June 6, 2013 | 12:40 am

just to mention a problem a solution for this old topic that allows not to qui Max on OSX :
[hi] will not recognize the plugged interface anymore if they are disconnected/reconnected
*but*
it will if *all* instances of [hi] objects are destroyed and re-created (using script).
Now, this could be (maybe) easily be fixed in the [hi] object itself, as the procedure above sounds still a bit clumsy when several instances are dispatched in a complex patch.

If one could just click again the "info" button to get the interfaces back, that would be nice.
If one could get a message telling automatically when a usb interface is plugged, this would be even nicer.

@C74 team : a feat request for the next update ?

 


Viewing 6 posts - 1 through 6 (of 6 total)