Regarding one of your questions, I don't believe that there is any specified limit to how many midi events can be processed at once, or in a defined block of time (ticks). Fistly, this would be totally dependant on the abilities on the devices that are receiving the data, and how fast they can do their job. Whatever the practical limit was 20 years ago, it will now be a lot more, and in due course it will be a lot more again. Secondly, the data is just a stream, if data gets blocked due to performance, then it's blocked and it can just wait a little until it can catch up. The effect of any data being 'lost' will be even worse. I assume most (all?) devices have some sort of buffer, which would usually be enough.

I take it that you are NOT in fact trying to play a midi file backwards. This cannot make any sense at all. This is rather akin to reading a book, starting at the last word and reading each word in turn from there until you get to the first work in the book. I don't think that any book would make any sense at all read like this. The story would be destroyed? Especially as you refer to 'sound correctly'!

Of course, you COULD manipulate the data a LOT, so that it was 'sort-of' be played backwards, and still make sense. It this what you mean? You could break the data down into musical events, which would be nested. An event would be a Note On, with it's matching Note Off. A sequence of such note events, preceeded by the PC and controller events that prepare for the coming notes, a sequence of SysEx (Which MUST be played in the correct order else they will not work at all). Each ME (musical event) would need it's internal timings to be reversed such that it now starts when it would have ended and vice versa. The relative timings inside the ME should stay the same? The order of the events within each ME should stay as normal

There should NOT be any discarded events, etc, as you seem to be suggesting, as this cannot BUT change (mess up?) the sound of the music. There should not be any more reason to be playing more midi data than playing the file forwards.

Midi data is not complete musical data. It's a set of instructions, that makes any sense ONLY when done the intended way around. Midi is not like a taperecording of a piece of music, yes, this CAN be played backwards, and it can sound totally HORRID and quite meaningless.

Why do you want to play a midi file backwards?

Geoff

Sorry 😀 , I don't think I translated correctly, what I mean is to jump in time, not play, in search mode, for example, you are playing bar 50 and you go back to bar 25, but in a jump, to change the midi time, and to That's why I have to look for the missing controls and not alter the sound, Alsa Midi sends me buffer full messages when I send more than 1000 events, that's why I ask.

Ah, yes, I understand what you mean.

So, re the example you gave. You were playing 50, and you want to reset back to 25. So you need to redo the relevant commands 1 to 24 to make sure things are set right for 25 again. And anything set between 25 and 50 is cancelled.

Can't see that there's any easy way to do that.

I'd suggest you need software with a special PLAY mode where you disregard ALL notes, but do everything else at extra speed. Then do a full RESET, which should go back to 0, run through to 25 again, then go back to normal speed. Use as much of normal operations as possible, give the system a number of seconds to run through so you don't flood system.

Don't think any normal player would allow this though? I've got a player system that I wrote myself, I suppose something like that could be changed to add such a facility?

Geoff

This is exactly what I'm doing, but even discarding the note events, many events can be joined. How big is the buffer that I mentioned above?

[quotePost id=17675]
Don't think any normal player would allow this though? I've got a player system that I wrote myself, I suppose something like that could be changed to add such a facility?
[/quotePost]

I don't understand this question, I have seen this function in any midi player.

ALSA's buffer size is shown in /proc/asounc/cardX/midi0 when the device is open, and is 4 KB by default.

In general, you have to assume that the speed is no larger than 3125 bytes/s, and that there is not much of a buffer.

[quotePost id=17672]how many events [can I send] every 16 milliseconds?[/quotePost]On a DIN MIDI cable, the speed used is 3125 bytes per second (31250 bits per second and 10 bits per byte -- 1 start bit, 8 data bits, 1 stop bit). Other than System Exclusive messages, a MIDI message is 3 or 2 or 1 bytes long. So the maximum number of messages in 16 milliseconds is 16 2/3 or 25 or 50, respectively.

If you are sending MIDI messages on a USB cable connected to a USB port on both ends, I don't know the details other than it is faster than a DIN MIDI cable.

(Similar: The recent thread MIDI buffer limits discussed how many differnet-channel pitch-bent notes could be sent per second.)

[quotePost id=17672]AlsaMidi gives me an error with more or less 1000 events[/quotePost]Trying to send 1000 MIDI messages when you change position in a MIDI file seems like too many messages to me. I think 100 or 200 messages might be more typical for a busy MIDI file.

Although there are 128 possible Control Change messages, most MIDI devices do not use all of them, and most MIDI files will only send some of them. You shouldn't try to re-send all 128 possible Control Changes on every channel when the position changes. You should only keep track of the messages that are actually contained in the MIDI file, and only send the messages that will have a different value.

(By the way, there are also 16384 possible Registered Parameters and 16384 possible Non-Registered Parameters.)

Thank you, it has been very useful. I had completely forgotten about the registered and unregistered parameters.