Hi, I've been implementing a function to b̶a̶c̶k̶w̶a̶r̶d̶s̶ go back or f̶o̶r̶w̶a̶r̶d̶s̶ fast forward in a MIDI file, and for this I have to send several events from programs, controllers, sysex to make it sound correctly, the problem is that too many events can be generated, I've already discarded the events that are being cancelled, but even so they can be too many, taking into account that there are 16 channels and 127 controllers, it could be 2032 unique events (2080 if we include: programs, channel pressure and pitch bend, without counting innumerable sysex), so what is the maximum number of events I can send at one time? Or how many events every 16 milliseconds? AlsaMidi gives me an error with more or less 1000 events, but I would like to know for other MIDI devices.
Carlos
set the type of the post as
Technical Question — 9 months ago
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
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.
, 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
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?
I don't understand this question, I have seen this function in any midi player.
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?
I don't understand this question, I have seen this function in any midi player.
0
Undo
Votes
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.
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.
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.how many events [can I send] every 16 milliseconds?
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.)
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.AlsaMidi gives me an error with more or less 1000 events
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.)
Carlos
marked this post as Resolved — 9 months ago
- Page :
- 1
There are no replies made for this post yet.
