I sit here and parse midi or rather reparse midi "from a real parser" that output text JSON content.
When i look at it i can't see there is any timing information with the midi messages for program change.
Does that mean there is no program changes on a single midichannel "in a midi file"?
So there is max 16 programs specified in a standard midi file?
And all start/sent/set at file load?
Best regards Jonas
When i look at it i can't see there is any timing information with the midi messages for program change.
Does that mean there is no program changes on a single midichannel "in a midi file"?
So there is max 16 programs specified in a standard midi file?
And all start/sent/set at file load?
Best regards Jonas
Hello,
All CC events, like note events, and including PC (Program Changes), will have the usual timing bytes present. Therefore PC events can happily appear at any point in a midi file, and a single channel could contain any number of PC commands. It is merely a convenience to keep a channel for a specific instruments, it does make things eaiser to keep track of.
I have certainly had midi files where major instruments were on a channel of their own (and usually a track of their own), but it is not uncommon for lesser, occasional, instruments to come and go on a spare channel. This is somewhat tidier than having them on their own channel when they are there for maybe only a bar or two. They could still be on a separate track, mind you.
If the parser you're using does not show the timing for a PC, then this could be considered a fault.
The parser I use (DECODE) to convert a midi file into text for viewing etc certainly DOES show the timing data for PC events. I would be quite upset if it didn't.
Geoff
All CC events, like note events, and including PC (Program Changes), will have the usual timing bytes present. Therefore PC events can happily appear at any point in a midi file, and a single channel could contain any number of PC commands. It is merely a convenience to keep a channel for a specific instruments, it does make things eaiser to keep track of.
I have certainly had midi files where major instruments were on a channel of their own (and usually a track of their own), but it is not uncommon for lesser, occasional, instruments to come and go on a spare channel. This is somewhat tidier than having them on their own channel when they are there for maybe only a bar or two. They could still be on a separate track, mind you.
If the parser you're using does not show the timing for a PC, then this could be considered a fault.
The parser I use (DECODE) to convert a midi file into text for viewing etc certainly DOES show the timing data for PC events. I would be quite upset if it didn't.
Geoff
0
Undo
Votes
It is common to select programs only at the beginning of the file, but if you need more than 16 programs, it is certainly possible to change them at any time.
I do not know what JSON parser you're using.
I do not know what JSON parser you're using.
I use this json parser to import midi files and reparse the json info to fit my sequenser.
https://tonejs.github.io/Midi/
I can not see any time with the program changes?
So maybe it is losing information?
Or it could be that it create a new channel block for same midi channel. But i have not seen any recurrence of same channel.
https://tonejs.github.io/Midi/
I can not see any time with the program changes?
So maybe it is losing information?
Or it could be that it create a new channel block for same midi channel. But i have not seen any recurrence of same channel.
Hello,
All CC events, like note events, and including PC (Program Changes), will have the usual timing bytes present. Therefore PC events can happily appear at any point in a midi file, and a single channel could contain any number of PC commands. It is merely a convenience to keep a channel for a specific instruments, it does make things eaiser to keep track of.
I have certainly had midi files where major instruments were on a channel of their own (and usually a track of their own), but it is not uncommon for lesser, occasional, instruments to come and go on a spare channel. This is somewhat tidier than having them on their own channel when they are there for maybe only a bar or two. They could still be on a separate track, mind you.
If the parser you're using does not show the timing for a PC, then this could be considered a fault.
The parser I use (DECODE) to convert a midi file into text for viewing etc certainly DOES show the timing data for PC events. I would be quite upset if it didn't.
Geoff
All CC events, like note events, and including PC (Program Changes), will have the usual timing bytes present. Therefore PC events can happily appear at any point in a midi file, and a single channel could contain any number of PC commands. It is merely a convenience to keep a channel for a specific instruments, it does make things eaiser to keep track of.
I have certainly had midi files where major instruments were on a channel of their own (and usually a track of their own), but it is not uncommon for lesser, occasional, instruments to come and go on a spare channel. This is somewhat tidier than having them on their own channel when they are there for maybe only a bar or two. They could still be on a separate track, mind you.
If the parser you're using does not show the timing for a PC, then this could be considered a fault.
The parser I use (DECODE) to convert a midi file into text for viewing etc certainly DOES show the timing data for PC events. I would be quite upset if it didn't.
Geoff
Further to the above, the JSON format seems to be similar in some ways to the musicxml format.
I've looked at a file for one of the latter, and I note that the timing data in the file is really relative to the bar/measure, and not to the start of the file (as is the case with a midi file). So any event at the start of the file, and anything at the start of a bar, would in effect have a zero timing, and might therefore not need to show. This is not unreasonable, although it is not very helpful from the point of view of midi.
Geoff
I've looked at a file for one of the latter, and I note that the timing data in the file is really relative to the bar/measure, and not to the start of the file (as is the case with a midi file). So any event at the start of the file, and anything at the start of a bar, would in effect have a zero timing, and might therefore not need to show. This is not unreasonable, although it is not very helpful from the point of view of midi.
Geoff
Hello again,
I was looking at the JSON format before, and at this time I did process a midi file I had, and I saved the converted (parsed) file to my computer. I've finally trached the file down on my machine, and had another look at it.
It is quite different from the musicxml formal, although it looks rather like xml. This format is NOT based on bars etc, and it OUGHT to include tick times like a midi file, but as you say, it does NOT do so for PCs.
At the start of each track, there seems to be an item for ControlChanges, which starts with a timing item. OK. However, this section does NOT include the 'instrument' item, which is in effect the item for the Program Change. PC is a separate command, at a similar level to Note On, Note Off, and ControllerChange, all of which do seem to have a timing element attached, yet PC it seems does not. Really it ought to.
Yes, if the PC is at the start of a track, then it doesm't matter (too much), but as I've noted above, normal midi files certainly CAN and DO contain PCs within the track, and these MUST happen at the correct time otherwise the playback of the music will come out wrong (instrument-wise).
Long ago I wrote a small utility prog which reports on the contents of a midi file, and among other details this reports that a specific track contains more than 1 PC. At least one of the process or playback progs that I have used will report, on loading a midi file, that there are tracks containing more than one channel, or extra PCs, and offer to split the file to more tracks to ensure that channels and instruments are on seperated tracks, but this is offered as an option and is not essential.
If I was planning on doing anything with the JSON format, I would wish to test it with a midi file containing PCs in the middle, and see just how it handles them.
Geoff
I was looking at the JSON format before, and at this time I did process a midi file I had, and I saved the converted (parsed) file to my computer. I've finally trached the file down on my machine, and had another look at it.
It is quite different from the musicxml formal, although it looks rather like xml. This format is NOT based on bars etc, and it OUGHT to include tick times like a midi file, but as you say, it does NOT do so for PCs.
At the start of each track, there seems to be an item for ControlChanges, which starts with a timing item. OK. However, this section does NOT include the 'instrument' item, which is in effect the item for the Program Change. PC is a separate command, at a similar level to Note On, Note Off, and ControllerChange, all of which do seem to have a timing element attached, yet PC it seems does not. Really it ought to.
Yes, if the PC is at the start of a track, then it doesm't matter (too much), but as I've noted above, normal midi files certainly CAN and DO contain PCs within the track, and these MUST happen at the correct time otherwise the playback of the music will come out wrong (instrument-wise).
Long ago I wrote a small utility prog which reports on the contents of a midi file, and among other details this reports that a specific track contains more than 1 PC. At least one of the process or playback progs that I have used will report, on loading a midi file, that there are tracks containing more than one channel, or extra PCs, and offer to split the file to more tracks to ensure that channels and instruments are on seperated tracks, but this is offered as an option and is not essential.
If I was planning on doing anything with the JSON format, I would wish to test it with a midi file containing PCs in the middle, and see just how it handles them.
Geoff
Hello Geoff
Well it seem it was a bad choice of "decoder/parser", but maybe he will fixit because the project still running on github and i did a bug/issue report.
And maybe same issue with pitchbend information.
I probably could write a parser from scratch, but i remember it to be alot of job, and bit fiddling.
Jonas
Well it seem it was a bad choice of "decoder/parser", but maybe he will fixit because the project still running on github and i did a bug/issue report.
And maybe same issue with pitchbend information.
I probably could write a parser from scratch, but i remember it to be alot of job, and bit fiddling.
Jonas
Well here is the format i decided upon for my own sequenser, possibly could add some more metainfo, do you see anything that is obviously missing?
https://midisequenser.000webhostapp.com/
bumblebee; //Author sequense
Frog fatalism; //Song name
RumpelStiltskin; //Song Author
A dark night in December; //Song info
960; //PPM
PART:1:hgfhgf:0:7:100:4:4; //Track,partname,startbar,endbar, tempo,timesignature
PART:1:5656546:7:14:100:4:4; //Track,partname,startbar,endbar, tempo,timesignature
PART:2:5656546:7:14:100:4:4; //Track,partname,startbar,endbar, tempo,timesignature
TRACK;
1;
NONAME; //Trackname
192:0:1;
176:7:127:1;
176:10:63:1;
176:91:40:1;
176:93:25:1;
176:1:0:1;
176:64:10:1;
144:49:54:552.640000001702;
144:61:59:673.4500000020489;
128:49:818.039999998291;
128:61:841.919999998936;
144:70:47:846.8900000007125;
144:73:61:879.4100000013714;
144:78:60:907.0700000011129;
128:73:936.0000000015134;
128:70:938.2499999992433;
128:78:993.6650000017835;
144:48:30:1386.449999998149;
144:60:56:1420.269999995071;
144:68:45:1507.5700000015786;
144:70:69:1535.794999996142;
128:48:1549.0799999970477;
144:75:57:1578.5649999961606;
128:60:1586.0299999985727;
128:68:1587.019999999029;
128:70:1636.5650000007008;
192:18:16801;
176:7:127:16801;
176:10:63:16801;
176:91:40:16801;
176:93:25:16801;
176:1:0:16801;
176:64:10:16801;
144:49:56:17319.439999996393;
144:61:64:17490.47000000137;
128:49:17593.154999999388;
128:61:17630.13999999821;
144:75:59:17643.439999996917;
144:82:75:17764.594999997644;
128:75:17772.705000000133;
128:82:17875.859999997192;
144:48:61:18510.520000000542;
144:60:60:18590.354999997362;
128:48:18677.67999999778;
144:73:50:18698.86000000115;
128:60:18744.7250000012;
144:75:45:18747.339999998803;
144:80:60:18820.83500000299;
128:73:18844.78999999992;
TRACK;
2;
NONAME;
193:100:16801;
177:7:127:16801;
177:10:63:16801;
177:91:40:16801;
177:93:25:16801;
177:1:0:16801;
177:64:10:16801;
145:45:58:17120.32999999501;
129:45:17276.879999994708;
145:83:62:17337.09499999968;
129:83:17536.1649999948;
145:84:73:17574.48000000004;
129:84:17726.674999995157;
145:43:59:17815.059999997902;
129:43:18001.539999994566;
145:84:69:18025.634999995236;
145:43:64:18215.62499999418;
129:84:18218.814999997267;
https://midisequenser.000webhostapp.com/
bumblebee; //Author sequense
Frog fatalism; //Song name
RumpelStiltskin; //Song Author
A dark night in December; //Song info
960; //PPM
PART:1:hgfhgf:0:7:100:4:4; //Track,partname,startbar,endbar, tempo,timesignature
PART:1:5656546:7:14:100:4:4; //Track,partname,startbar,endbar, tempo,timesignature
PART:2:5656546:7:14:100:4:4; //Track,partname,startbar,endbar, tempo,timesignature
TRACK;
1;
NONAME; //Trackname
192:0:1;
176:7:127:1;
176:10:63:1;
176:91:40:1;
176:93:25:1;
176:1:0:1;
176:64:10:1;
144:49:54:552.640000001702;
144:61:59:673.4500000020489;
128:49:818.039999998291;
128:61:841.919999998936;
144:70:47:846.8900000007125;
144:73:61:879.4100000013714;
144:78:60:907.0700000011129;
128:73:936.0000000015134;
128:70:938.2499999992433;
128:78:993.6650000017835;
144:48:30:1386.449999998149;
144:60:56:1420.269999995071;
144:68:45:1507.5700000015786;
144:70:69:1535.794999996142;
128:48:1549.0799999970477;
144:75:57:1578.5649999961606;
128:60:1586.0299999985727;
128:68:1587.019999999029;
128:70:1636.5650000007008;
192:18:16801;
176:7:127:16801;
176:10:63:16801;
176:91:40:16801;
176:93:25:16801;
176:1:0:16801;
176:64:10:16801;
144:49:56:17319.439999996393;
144:61:64:17490.47000000137;
128:49:17593.154999999388;
128:61:17630.13999999821;
144:75:59:17643.439999996917;
144:82:75:17764.594999997644;
128:75:17772.705000000133;
128:82:17875.859999997192;
144:48:61:18510.520000000542;
144:60:60:18590.354999997362;
128:48:18677.67999999778;
144:73:50:18698.86000000115;
128:60:18744.7250000012;
144:75:45:18747.339999998803;
144:80:60:18820.83500000299;
128:73:18844.78999999992;
TRACK;
2;
NONAME;
193:100:16801;
177:7:127:16801;
177:10:63:16801;
177:91:40:16801;
177:93:25:16801;
177:1:0:16801;
177:64:10:16801;
145:45:58:17120.32999999501;
129:45:17276.879999994708;
145:83:62:17337.09499999968;
129:83:17536.1649999948;
145:84:73:17574.48000000004;
129:84:17726.674999995157;
145:43:59:17815.059999997902;
129:43:18001.539999994566;
145:84:69:18025.634999995236;
145:43:64:18215.62499999418;
129:84:18218.814999997267;
You have attached this message to an old thread, which is confusing.
You CAN have program changes on any channel within a midi file. There can be a max of 16 programs specified AT ANY ONE TIME, but which programs will be active can be changed using Program Changes within the file.
Geoff
You CAN have program changes on any channel within a midi file. There can be a max of 16 programs specified AT ANY ONE TIME, but which programs will be active can be changed using Program Changes within the file.
Geoff
- Page :
- 1
There are no replies made for this post yet.
