Knowing when midiout has sent all data?

Dan Nigrin's icon

My patch currently sends a large amount of sysex data out via midiout. It's working fine, but I'd like to know when all of the data has actually been sent by the MIDI interface. Basically I'd like to know if the MIDI interface is still "busy" sending. Is there a way to tell within Max that this is the case?

Roman Thilenius's icon

i´ve always thought that midiout should have outlets (in the same manner plugout~ has outputs or loadbang has an input), then you could at least tell when the object has finished. (not sure if this is identical with the operating system? as for the interface, not a chance.)

Dan Nigrin's icon

I'd settle for operating system!

Peter Ostry's icon

Check at midiout for number 247.
If you send several strings, then the last 247.

No, I don't mean Boeing 247, they don't fly anymore.

Dan Nigrin's icon

Thanks Peter - but I guess I didn't make myself clear above. I send an entire long list of bytes to midiout in one message, including the final 247. From that moment on, Max is kind of "done," but the OS / MIDI interface are still sending.... I guess it's kind of asking a lot for Max to be able to know that....

I suppose another approach I could use is to iterate through the list of bytes to send, and send them a tad slower.... then I'd know when the last byte has been sent.

Roman Thilenius's icon

one could implement a routine where the user has the option to permamently increase the speed (for sending a preset into a device... you know that a synth has received its preset when it makes sound again) until it stops working, and then he can choose a speed somewhere below that.

i think even if you take the interfaces´ latency and buffer size into account, what does it tell us? it could be busy with something else. not to speak of the receiving device.

one could also split and mirror the outgoing data in the OS and send it back to max using an IAC bus to test things out, but this is not a solution you want in a standalone.

i have similar anxieties with file i/o; it is just ugly when you can not control the order of something. :)

Dan Nigrin's icon

100% agree on all Roman, a tough problem....

I realize now that in my particular use case, the device I'm sending to issues an acknowledgement when the message has been successfully received by it, so at least I can know when the transmission is done. But I have no way of displaying a progress bar or similar to the end user. So I will just block the UI until the app receives the ACK, and only then allow the user to proceed. Not optimal, but will work in this instance.

Source Audio's icon

I would expect that you control timing of
sending of large amount of sysex messages
either by taking midi baud rate into account
or speed that your receiving device can cope
with.
that, together with ack at the transmission ok
could be usefull to create some sort of animation for users,

Dan Nigrin's icon

Yes, I'll cobble something together along those lines, thanks!

Roman Thilenius's icon

a flashing led instead of a progress bar should do it.

did you know that many progress bars in games and even in operating systems are fake, too? (but you remember the discussion about how to have a progress bar in splash screens in max about 15 years ago.)

Dan Nigrin's icon

Actually it was more recently than that (progress bar and splash screens) - only like 4 or 5 years. Just seems like an eternity ago! :-)

Source Audio's icon

at some point in max history I stumbled over progress object
by chance, while copying some externals to stanalone.
did not know it existed at all


Dan Nigrin's icon

Yeah I use that as well - not sure why it's not documented.