On Thursday, January 5, 2017 12:14:47 AM EST you wrote:
> On Wednesday, January 4, 2017 5:30:13 PM EST Michael Oswald wrote:
> > Hi Tim,
> > 
> > > Also, in your first message I'm unable to reproduce the
> > > 
> > >  importing bug thing. I'll keep trying though.
> > > 
> > > I hate to ask, but... video?
> > > Seems impossible that moving a part onto a drum track would
> > > 
> > >  suddenly 'GM-ify' the track's drum map permanently.
> > > 
> > > Check that the track's patch (program) number really does
> > > 
> > >  correspond to a patch that the drum map is for.
> > > 
> > > If all else fails, try 'reset track's drum list'.
> > 
> > I did some more research and what looks weird to me is that the drummap
> > file is different and lacks information.
> > 
> > E.g. old drummap from 2.2.1:
> >    <entry>
> >    
> >        <name>Kick Emad Head</name>
> >       
> >       <vol>100</vol>
> >       
> >        <quant>16</quant>
> >        <len>32</len>
> >        <channel>-1</channel>
> >        <port>-1</port>
> >        <lv1>70</lv1>
> >        <lv2>90</lv2>
> >        <lv3>110</lv3>
> >        <lv4>127</lv4>
> >        <enote>36</enote>
> >        <anote>36</anote>
> >        </entry>
> >      
> >      <entry>
> >      
> >        <name>PantherSnareCentre</name>
> >        <vol>100</vol>
> >        <quant>16</quant>
> >        <len>32</len>
> >        <channel>-1</channel>
> >        <port>-1</port>
> >        <lv1>70</lv1>
> >        <lv2>90</lv2>
> >        <lv3>110</lv3>
> >        <lv4>127</lv4>
> >        <enote>38</enote>
> >        <anote>38</anote>
> >        </entry>
> > 
> > The problematic drummap:
> >   <entry idx="36">
> >   
> >        <name>Kick Emad</name>
> >      
> >      </entry>
> >      <entry idx="37">
> >      
> >        <name>PSnare Sidestick</name>
> >      
> >      </entry>
> >      <entry idx="38">
> >      
> >        <name>PSnare Centre</name>
> >      
> >      </entry>
> > 
> > So the whole information didn't get stored somehow.
> 
> I made it that way. If you save a drum map it only stores
>  what you /changed/ in the map. Default instrument entries
>  will 'peer through' the unaltered entries.
> 
> Before you throw up a yellow card, yes it would have been nice
>  to store the 'whole complete' drum map even with unaltered entries.
> But... When I sat down to do that (I tried it), I realized it would
>  have meant storing /all/ entries for /all/ patches everywhere,
>  ie. the 'complete' drum map ie. when you reload it, all entries
>  on all patches are bold text.
> What to do: If you really want all the entries and all information
>  stored for one or more patches...
>  try ...
> 
> Oops, sorry, I meant to add some menu entries:  "Set whole patch",
>  "Set field", and "Set row", to compliment the "Set column" and
>  "Promote to default patch".
> You'll select "Set whole patch" to set the whole map for /this/ patch
>  (bold text), while "Promote to default patch" sets it for any patch.
> Then you'll save it. Sound good?

OK This is added now:
Drum editor list: Added 'Set field', 'Set row', 'Set list' to right-click menu.

So the idea is that if you really want to save the entire drum list
 WYSIWYG - even if some items have NOT been changed,
 choose 'Set list' which will highlight ALL items. Then save the drum list.
Now when you reload the drum list again, ALL the items should be there.

Again, the orginal idea was to save ONLY what was changed
 so that such maps could be loaded on top of default items.
For example suppose you just change the volume column for 
 one or two rows. Save it, and now you can load that map
 'onto' any track while keeping all of that map's original items
 such as 'Sound' name, quant, len, enote, anote etc.

Hope you find it useful and lemme know if any trouble or suggestions.

Remember that it is all patch-centric now. The bold text is only 
 for THIS patch, while italic text is for the default patch (all patches
 that were not specifically set).
If there is NO instrument map for the current patch (<unknown>), 
 it FALLS BACK to the GM map. Thus you MIGHT be accidentally 
 manipulating the GM map rather than the current instrument's map.
It may seem confusing at first. I plan to add something in the map 
 that shows the user exactly what map source they are looking at.

Caveat: 
If you have more than one track on the same port and channel and 
 you are wondering why changing some map items on one track does 
 NOT affect the others, use the track's 'Copy list to all selected tracks'  
 right-click option. Unfortunately it can't be automatic at this point.
Yes, I did include FULL code for yet ANOTHER level of manipulation -
 Instrument Overrides - such that any map changes are reflected
 to ALL tracks using that instrument.
But... I felt it was too much to put on the user's shoulders:
The map's right-click menu would grow to include all the options 
 you see now - PLUS a complete extra set of those commands just 
 for the Instrument Overrides level.
Too much, me thinks. Too complex in the code, as well.
So that code is DISABLED for now.

I hope what we have now is satisfactory.
Maybe I can find a way to simplify the Instrument Overrides someday.

Tim.


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Lmuse-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmuse-developer

Reply via email to