phiol

having found nothing on the max objects site and after searching the max forumm, here it goes.

Is there a way or an object that sends a notification (bang) when a midi device is plugged in the usb hub?

For sure there is an internal update, since when you double click a [notein] or [ctlin], you can see your device and select it.

For efficiency, when a I load a patch, I have a 

Of course this is fine if my usb device is plugged before I load the patch.

So, would it be possible to have a bang, notifying when a usb has be plugged in.

This would be very practical. Especially, when your building patches for other people that do not know MAX.

having found nothing on the max objects site and after searching the max forumm, here it goes. 

Is there a way or an object that sends a notification (bang) when a midi device is plugged in the usb hub? 

For sure there is an internal update, since when you double click a [notein] or [ctlin], you can see your device and select it. 

For efficiency, when a I load a patch, I have a 
[loadbang]
|
[port "E-MU XMidi1X1"]
|
[noteout] 
.

So, would it be possible to have a bang, notifying when a usb has be plugged in. 

This would be very practical. Especially, when your building patches for other people that do not know MAX. 

practical-midi-device-notification-question

Not sure if this is possible with max - is would be good to know if there was a rescan option in max, or ableton and any other program I use for that matter. 

So far unlike plugins - any hardware must be connected and switched on before the program starts.

Not quite sure - so corrections are most welcome.

Not sure if this is possible with max - is would be good to know if there was a rescan option in max, or ableton and any other program I use for that matter. 
So far unlike plugins - any hardware must be connected and switched on before the program starts.
Not quite sure - so corrections are most welcome.


All i know is that for sure something happens when something is plugged/unplugged. If not how would obj. like ctlin-out see them.

And it happens without having to restart max.

All i know is that for sure something happens when something is plugged/unplugged. If not how would obj. like ctlin-out see them. 

And it happens without having to restart max. 

If OS X, CoreMIDI notifies attached clients when the status of the MIDI system changes. I assume this is what C74 use to update their internal representation.

It's certainly possible to write a Max external that will receive CoreMIDI notifications and output those, and I was experimenting with a CoreMIDI object some time ago. I'll see if I can find the code.

It also used to be possible to talk to CoreMIDI via Java, so doing it in mxj seems possible, though Apple have officially deprecated their java-coremidi support as of 10.4.x

>If OS X, CoreMIDI notifies attached clients when the status of the MIDI system changes. I assume this is what C74 use to update their internal representation.

>It's certainly possible to write a Max external that will receive CoreMIDI notifications and output those, and I was experimenting with a CoreMIDI object some time ago. I'll see if I can find the code.

Was it your code? I just searched for one in the maxobject list and found nothing.

>It also used to be possible to talk to CoreMIDI via Java, so doing it in mxj seems possible, though Apple have officially deprecated their java-coremidi support as of 10.4.x

Was it your code? I just searched for one in the maxobject list and found nothing. 

Too bad I don't know java.
Too apple are like that. 

phil hughes wrote on Thu, 13 August 2009 14:06

>Was it your code? I just searched for one in the maxobject list and found nothing.

I didn't release it. I was experimenting with direct CoreMIDI communication to work around a few bugs I was experiencing. I wasn't doing anything with the system-change notifications, but the object was definitely receiving them internally.

Doesn't appear to be on my drive at present, a dig through the archive will be needed. Even then, I'm not sure whether it will be a simple matter to rip everything else out and just output the notification messages.

phil hughes wrote on Thu, 13 August 2009 14:06>Was it your code? I just searched for one in the maxobject list and found nothing. 

Doesn't appear to be on my drive at present, a dig through the archive will be needed. Even then, I'm not sure whether it will be a simple matter to rip everything else out and just output the notification messages.


Thanks . I will search the forum. Bed time for now 3 am.

There is a [coremidi]
Don,t know what it does? 

Thanks . I will search the forum. Bed time for now 3 am. 

https://cycling74.com/forums/index.php?t=msg&goto=43152&rid=6204&S=835b2f1cbb3c8a6bbcfd37bac1b2669b#msg_43152

Where you say you've created the code but nowhere is it to be seen in this thread or any other.

I 've find this https://cycling74.com/forums/index.php?t=msg&goto=43152&rid=6204&S=835b2f1cbb3c8a6bbcfd37bac1b2669b#msg_43152

Where you say you've created the code but nowhere is it to be seen in this thread or any other. 

another solution (which is not as elegant), is to poll midinfo and see if the list of devices changes... if it changes or you find a particular device, then stop polling...

@ the moment I am not concerned w. elegance so your solution seems fine. Only problem is, how do you do it??

Thanks an sorry for my ignorance but I'm here to learn.

@ the moment I am not concerned w. elegance so your solution seems fine. Only problem is, how do you do it?? 

Thanks an sorry for my ignorance but I'm here to learn.  

I agree that this is ugly but here is one way of doing it

I will look @ your patch in a min. but before, here is what I came up with. It works but gosh...

phil hughes wrote on Fri, 14 August 2009 03:39

I'm talking there about the ability to create virtual in/out ports in Max, and at the time there were fewer options to control how that was done. The code I talk about is a command line app that just checks the port ID numbers from outside Max - so no use to you, sorry.

I'm a fan of putting things like input-device selection under user control anyway. So why not put the notification under the user's control too - provide a "rescan MIDI" button next to your port selector that clears and re-populates it? No need to (expensively) poll at all then. Something like:

phil hughes wrote on Fri, 14 August 2009 03:39Hi john 
I 've find this https://cycling74.com/forums/index.php?t=msg&goto=43152&rid=6204&S=835b2f1cbb3c8a6bbcfd37bac1b2669b#msg_43152
Where you say you've created the code but nowhere is it to be seen in this thread or any other.

But in the end, clicking somewhere to fetch your controller is exactly what I was trying to avoid. I remember ,in the pass, when using other software such as Ableton, you did not have to select it. It was plug and go.

When i built patches for friends that's exactly what I want them to experience.

I was just trying (for efficiency and practicality) to get away from this.

But in the end, clicking somewhere to fetch your controller is exactly what I was trying to avoid. I remember ,in the pass, when using other software such as Ableton, you did not have to select it. It was plug and go. 

When i built patches for friends that's exactly what I want them to experience. 

I was just trying (for efficiency and practicality) to get away from this. 

incase someone is still lost with this question, [midiinfo] supports the attributes of autopolling controllers/input/output and thus updates the midilist on change. very useful.

practical midi device notification question