From: Tim <te...@ro...> - 2012-09-28 22:22:57
|
Hi Florian. When I create a New Drum track and point it to a Port which uses the GS or XG instrument, the drum maps in the Drum Editor still show the default GM map. I saw you made maps for GS and XG. Stepping through the code I see Track::_drummap is still holding the default GM map, and the drum list's ourDrumMap and so on depends on _drummap. Stepping futher I see _drummap is initialized from the static iNewDrumMap[ ] which is started with the default GM map, which seems correct, but nothing happens after that, and I found no references in the code to the port's instrument, where the real drum maps are located. I'm looking for the place where they should be copied over to iNewDrumMap[ ] - or somewhere... Can you help - what could be wrong? Thanks. Tim. |
From: . T. <ter...@ro...> - 2012-10-10 06:10:49
|
Hi Flo. Wow I keep discovering new things about the new drums. I never noticed the right-click menu on your drum tracks. When was that added... So this means they DO load and save maps contrary to what I thought? Nice work, you really put a lot into it. You know, while poking around I noticed they way you structured the drum maps was different than muse-evolution. Look closely at muse-evolution and see there are no drum tracks! Only midi tracks and each has a button 'show drum map'. This button simply turns on the drum map in the pianoroll editor. That is, there is no separate drum editor - the pianoroll can be instantly switched to show/hide the drum map or piano KB by clicking the track's 'show drum map' button. So it struck me that we could apply that to OUR pianoroll too - except with a difference... Yes, I said our pianoroll. What I'm getting at is mapped piano keys for regular midi tracks (non-drum). You know like this key makes this sound, that key makes another sound. Thus the piano keyboard drawing will have (hideable) note names as well, perhaps coloured in ranges like I've seen before in pro software. So in muse-evolution the drum maps were kinda put into the patches and it seemed to me it would not easily support this idea. However Flo your implementation is different - you put the maps OUTSIDE the patches. So it seemed to me yours would support being used for pianoroll. Now here's the thing: Named ranges. A wee bit different from named drum notes. But what you've given us is very close. And then I realized maybe not so easy, what about layers - not just contiguous ranges but overlapping ranges. (Mr. Jordan Rudess would approve!) Just some ideas. Thanks. Tim. |
From: Florian J. <flo...@we...> - 2012-10-12 15:09:37
Attachments:
signature.asc
|
Am 10.10.2012 08:10, schrieb . TERMTECH: > Hi Flo. > > Wow I keep discovering new things about the new drums. > > I never noticed the right-click menu on your drum tracks. > When was that added... > > So this means they DO load and save maps contrary > > to what I thought? > > Nice work, you really put a lot into it. > You know, while poking around I noticed they way you > > structured the drum maps was different than > > muse-evolution. > > Look closely at muse-evolution and see there are no drum tracks! > Only midi tracks and each has a button 'show drum map'. > This button simply turns on the drum map in the pianoroll editor. > That is, there is no separate drum editor - the pianoroll can be > > instantly switched to show/hide the drum map or piano KB by > > clicking the track's 'show drum map' button. > > > So it struck me that we could apply that to OUR pianoroll too - > except with a difference... Yes, I said our pianoroll. > What I'm getting at is mapped piano keys for regular midi tracks > > (non-drum). > > > You know like this key makes this sound, that key makes another sound. > > > Thus the piano keyboard drawing will have (hideable) note names as well, > > perhaps coloured in ranges like I've seen before in pro software. > > So in muse-evolution the drum maps were kinda put into the patches and > it seemed to me it would not easily support this idea. > > However Flo your implementation is different - you put the maps OUTSIDE > the patches. So it seemed to me yours would support being used for pianoroll. > > Now here's the thing: Named ranges. A wee bit different from named drum notes. > > But what you've given us is very close. > > > And then I realized maybe not so easy, what about layers - not just contiguous > > ranges but overlapping ranges. (Mr. Jordan Rudess would approve!) > > > Just some ideas. Hi Tim, Whut :D? i didn't really understand what you mean. Could you explain it differently, or possibly even create some mock-up GUI or sketch or similar? greetings flo > > Thanks. > Tim. > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Lmuse-developer mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-developer > |
From: Florian J. <flo...@we...> - 2012-09-29 18:09:38
Attachments:
signature.asc
|
Am 29.09.2012 00:22, schrieb Tim: > Hi Florian. > > When I create a New Drum track and point it to a Port which uses > the GS or XG instrument, the drum maps in the Drum Editor still > show the default GM map. I saw you made maps for GS and XG. Hi Tim, you have to set a patch=program=drumkit, too. (such as "electric kit 1", "jazz kit" etc.) this is because different kits can have different drum names. (Don't forget to store it to the track! Just selecting it from the combobox will not help. More details: The new style drum tracks look at the *first* program change event on the track. If there are multiple, the rest gets ignored, and if there is none, then nothing is done.) > > Stepping through the code I see Track::_drummap is still holding the > default GM map, and the drum list's ourDrumMap and so on > depends on _drummap. > > Stepping futher I see _drummap is initialized from the static > iNewDrumMap[ ] which is started with the default GM map, > > which seems correct, but nothing happens after that, and I found > no references in the code to the port's instrument, where the real > drum maps are located. I'm looking for the place where they > should be copied over to iNewDrumMap[ ] - or somewhere... Track::_drummap is updated when you change instrument type or program. However, if you set no (known) drum program/patch, then MusE will fall back to some default drum map (can't remember where it's located). iNewDrumMap is never changed. This is only a default value in case that the "instrument + patch"-combination is not known to muse (that is, not mentioned in any file) (If you also want to know where the _drummap is changed: Whenever MidiTrack::auto_update_drummap() is called, the track looks which patch it has, and then _drummap is set accordingly. MidiTrack::auto_update_drummap() is called from TrackDrummapUpdater (in trackdrummapupdater.cpp). That's just a helper class which connects to songChanged(), and iterates through all tracks, calling auto_update_drummap on its way.) Greetings, flo |