From: Florian J. <flo...@we...> - 2011-12-31 14:01:45
|
Am 31.12.2011 01:03, schrieb Tim E. Real: > On December 30, 2011 8:35:40 PM Florian Jung wrote: > >> Am 30.12.2011 20:18, schrieb Tim E. Real: >> >>> On December 30, 2011 7:14:13 PM Florian Jung wrote: >>> >>>> Hi >>>> >>>> why does populatePatchPopup need to know channel and song type? >>>> isn't it enough if it accepts a parameter "drum", which determines if >>>> we >>>> only want non-drum patches or if we only want drum-patches? >>>> >>> Ooh, careful, IIRC the instrument may need to know the song type >>> >>> and channel in to display appropriate patches suitable for the song >>> type or channel. >>> >> i don't even understand the "song type"... how can be a song "XG" or "GS"?? >> i mean, when a song uses XG, GM and GS instruments, which type has it then? >> > A reasonable question. > It took me a long time to understand it too, by then I just tried to work > within its limits and fix it up. > > Song type: > ----------- > Song type primarily determines what SYSEXs MusE sends out > upon starting or loading a song or rewinding it to start. > MusE sends out an appropriate SYSEX to switch the external hardware > to the correct mode - GS, GM or XG, if the external hardware supports > it of course. I was reluctant to change to default song type from 'NO' > to 'GM' mode. It is indiscriminate towards instruments! They currently > have no mechanism to block or allow. See below. > > Instruments: > -------------- > MusE instrument patches contain four patch flags: GM, GS, XG, and Drum. > By examining the song type and instrument patch flags, MusE determines > exactly what /available/ instrument patches do display. > If an instrument patch contains the XG flag for example but the > song type is on GM, MusE will not display that patch. why not? i mean, either an instrument DOES support that patch, or it does NOT. but the support doesn't depend on the song type, does it oO? > The patch may > contain /both/ the XG and GM flag and in this case will be shown. > The instrument editor SYSEX page is supposed to allow per-instrument > rather than per-song initialization messages to be sent out, like GM, GS, XG, > or whatever else necessary to initialize that /specific/ instrument. > Thus no song type required. > > Well that's the theory I think. In practice I know there's a few bugs... > which? > (If we can get that last bit done then we're on the way. Maybe I'll do that > SYSEX editor bit. I've been promising it for a long time, I studied both > muse evolution and ours.) > we really should. can you do :)? > Notice that we have GM, GS, and XG Instrument Definition Files as well as > specifically named files. The latter are specific custom instruments, and the > former are simply standard files with standard patch names and each of > those patch type flags set appropriately. > > One of the problems is that several of the instrument idf files do not appear > to be set up correctly with those flags IIRC. Possibly because the flags > support was added after the idf files, but also because of sheer confusion > and lack of docs (and previously lack of editor). I fixed a few of them > (including the XG idf) but the rest I do not know about. > as the whole thing seems pretty senseless, i can understand that nobody got it ;) see above: how can an instrument support different patches if you change the song type? the instr. doesn't change, does it? > >> >>> Look at our instrument editor window. >>> Notice that each patch can be marked as being suitable for >>> >>> GM, GS, XG or drum display. >>> >>> So the patch popup uses those settings to determine what to show. >>> >>> I know it doesn't always work as advertised, there's a few bugs I think. >>> >>> As for that whole song type issue, well plans (later) are to eliminate >>> it >>> >>> and let the instruments handle 'type'. >>> >> i probably started this in experimental, dunno... have a look at it, okay? >> > Yes, looked at new drums about 1 month ago. > I was slightly puzzled in a few areas (combining drum lists, E-note/A-note). > Was not a thorough test, I did not try mixing instruments such as fluidsynth > drum mixing/matching, as we discussed months ago, it . Will try. > quick guide: use a GS or XG instrument. create multiple drum tracks on multiple channels. create some parts on both, and open BOTH tracks in ONE drum editor. enter some notes on both tracks, then do window-config->hide_unused or something similar. reorder the list. fiddle around with window_config->group, or show_all etc... change patches (btw, i always forget to really press the "prog" button then :/ maybe we should automatically do that, or offer a different way?) and see how the drum list entry's names change. (of course only if you use drum sounds which actually DO have different names. showing all, even hidden, might help for demonstration). > >> >>> This is how muse evolution did it. There's no song type, the instruments >>> >>> handle the various GM, GS, or XG sysex emitting. >>> >> that's probably better. as i said, what if you mix XG and GM instruments? >> > Yeah, song type, the achilles heel left over from old, I think... > > >> >>> We are almost there, in terms of the instrument editor 'sysex' window, >>> >>> but it is not complete yet (the sysex editor doesn't work yet). >>> >>> Once that is out of the way, work could proceed in removing the song >>> type. There's a lot more to be done throughout the code to eliminate >>> >>> song type, and a few issues to be worked out, but in theory it's >>> doable. >>> >> my actual reason for digging into this was that MIDI tracks only show >> non-drum-patches, but drum tracks show both non-drum and drum patches. >> they only should show drum-patches however... could you maybe fix that >> in release_2_0? >> > As I mentioned, I recall my logic in showing patches was a bit necessarily > twisted and may seem buggy. > IIRC I wanted to allow a drum track to show all patches if it was not on > channel 10 how can "a drum track be on a channel"? this is impossible with old-style-drumtracks, because you can set up channel and port for EACH drumlist entry on its own. and: why should it show all patches? > and the song type was NO. Or something like that which > just worked: It allowed non-standard drum channels instead of fixed at 10, > if song type is NO. > but then other stuff didn't work, because song type should be not at NO for that stuff. honestly, all this (old style) drum track stuff is horribly broken by design. there is just no way to set program/bank for a certain channel/port, because a drum list can be spread on many ports and channels. so you CANNOT use nonstandard (which in fact is wrong. they ARE standard, just not GM, but GS and XG instead.) drum channels, because you need to set the lbank to 127; that's the way described in the GS and XG standards to tell the synth "even if that's not channel #10, this has to be a drum channel!". with my new-style drumtracks this is easy, because they actually behave like midi tracks. you just set up the patch and bank, and there you go. > Let me try to recall my logic. I'm not sure if I should change it here. > There was a reason I did it that way... All patches needed to be shown. > Ah, possibly because of synth instruments which have no patch flags > why do they have none? > thus we cannot discern them between 'drum' or not and hide them. > we could try to only display these with "drum" flag set, and if there are none, then and ONLY then fall back to "display all". > Also throw into this mix song type 'NO', where it is unknown and > 'wide-open' what kind of song you are making and hardware you are > working with, thus all patches should be shown. > in that case you will anyway need to tell muse which instrument you're using, otherwise patch names, controllers and stuff will be displayed wrong (as in the GM standard, but not necessarily as your instrument wants them). and if you have that idf file, muse knows about drum- and nondrum patches anyway. > I should point out here that song type 'NO' means show everything - > that is, no patch flag matching is done, the song is unknown ! > > Yeah, death to song type, good riddance. He he. > yes. really. it's not only totally senseless, it's really confusing and doesn't allow you to use all of muse's features. one feature wants it be at "NO", the other at "GM", the third at "XG or GS"... > Tim. > > greetings flo >> greetings >> flo >> >> >>> Tim. >>> >>> >>>> greetings >>>> flo >>>> >>> > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > Lmuse-developer mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-developer > > |