Forums > MaxMSP

midiin activity

May 13, 2012 | 7:53 pm

when does midiin listens to data which is received at the OS level?

always, or only when a valid port is selected?

or only when the port is selected where the data is coming in?

i need to decide what makes more sense:

[midiin] – [s foo] – 100x [r foo] (with variable names in order to switch 99 of the r´s off)

100x [midiin] of which are 99 turned off by, for example, choosing an invalid port (such
as "thisportnamedoesnotexist" or "-1")

-110


May 13, 2012 | 11:01 pm

[midiin] listens to the selected port. If this port doesn’t exist, [midiin] hears nothing. Be aware that Max does not frequently update it’s portlist; what Max tells you is not necessarily the port status known by the operating system (CoreMidi).


May 13, 2012 | 11:09 pm

How about midiin to forward (with a midiflush in between if you expect note data)? That way you can just use a ‘send’ message to forward the data wherever you want.


May 14, 2012 | 1:15 am

using [forward[ instead of making the [r]s dynamic is not an option, because
the [midiin] is somewhere centrally existent in the runtime and the 100
destinations, of which only 1 or 2 will be activated at the same time, would
need to tell that [midiin] who they are … but they can be instances of the
same subpatcher …

i tend to just have a midiin directly in each of those 100 subpatches, but
only if it is sure that i can make it easily not receiving anything when
turned off or routed to a non exsiting port or whatever.

and of course it would be fine when that will work across max4-max6,
win and mac. :)


May 14, 2012 | 9:49 am

It’s interesting that Max doesn’t allow setting the port to "OFF" like other midi applications.

So I would simply use a gate after each midiin.
Compared to audio the efficiency aspect of midi can usually be ignored.


May 14, 2012 | 11:47 am

100 instances … on g4 computers …


May 15, 2012 | 8:47 am

Roman Thilenius wrote:
i tend to just have a midiin directly in each of those 100 subpatches, but only if it is sure that i can make it easily not receiving anything when turned off or routed to a non exsiting port or whatever.

OOPS, I was wrong in my first answer. If [midiin] is set to a non-existing port, it actually falls back to the first port in the list. So you cannot be sure that it won’t receive data.

You could create a dummy port like ‘no_port’ and send the message "port no_port" to all of your 100 [midiin]s. This makes them all deaf. But it is not fully reliable because once the port exists someone could send data to it from another application. I think the only 100% reliable way is indeed a gate after the [midiin] or another object that can block data.


May 15, 2012 | 9:08 am

Setting to a non-existing port doesn’t work for me, ie. the message seems to be ignored (?)

Edit: Overlapping post, I didn’t see the last answer.

BTW, I think it’s a major flaw of the max midi port management.


May 15, 2012 | 2:54 pm

okay – what about setting it to simply another port than the one used, where the user knows that on this port is no incoming data? will midiin do something? like .. waiting? or like … still getting the data on the active port but not outputting it to the patch?


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