About the multiple mixed ports in a song: Been studying, hopefully we can move on this challenge now...
Multiple ports and more than 16 channels are not part of a standard midi file. The only way to utilize them is with the 'switch port' and 'switch channel' meta 33 and 32 events. Therefore if a MusE song uses more than one distinct Midi Port, we will utilize that 'port change' meta. This also solves the problem of storing the (old) Song Type sysex in the midi file: If there are multiple ports, after switching the port we include the relevant init sequence from that midi port's instrument, and away we go. The old way our Song Type governed a couple of sysexes to store. The new way each port has independent init sequences: GM, GS, XG, sysexes, controllers, whatever :-) I tested manually storing 'port change' meta events in three tracks, and thankfully MusE exported them and re-imported them preserved. However MusE does not export these port changes automatically. So I'm working on that... It should be automatic. Also I tried opening a pro-quality multi-port midi file from the net, it worked :) Conversely I tried storing 'switch channel' meta in the three tracks and I think MusE exported them OK, but it did not respect them upon re-importing. This I see is because midi events have a 'channel' built right in, and MusE is setting the newly created Track channel using those channels, not the channels from the 'switch channel' metas. I see where, studying this code now, hopefully can make this work, I think I need to be careful to respect our "old" multi-port/channel drum maps here... Also I tried opening a pro-quality midi having more than 16 channels, but MusE appeared to have truncated the channel to 16 and kept them all on the same port. Incorrect. More than one track pointing to the same place. These are 'professional quality' features. If you use multiple Midi Ports in a song, or > 16 channels, then there's not much choice but to use these features. I read they are commonly referred to as 'orchestral' or 'professional' files, because most basic playback environments don't support them. But we're not basic, we're MusE ! We don't support more than 16 channels per se. Increasing the #define MIDI_CHANNELS from 16 is ideal but not a good answer ATM, it may lead to some issues like needing to change class Route's midi channel width to a guaranteed int64 or whatever ceiling we need. Not to mention how more than 16 might automatically work with these metas. So I came up with a scheme when exporting/importing to midi: When exporting, if there are multiple ports, offer the user to export as "Many-Channel" or "Multi-Port", using the meta 32 or 33 respectively. Conversely when importing a midi having more than 16 channels, translate it into MusE multi-port which is equally acceptable. Quietly and simply while inside the file processing loops keep track of which ports were used and use only available ports when translating from many-channel to many-port. This way files having many channels AND multiple ports should be loadable - and playable :-) Does all this look correct, what do you think? Tim. ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
