On August 28, 2013 07:30:54 PM Tim E. Real wrote:
> On August 28, 2013 07:25:33 PM Florian Jung wrote:
> > Hi,
> >
> > can you please explain me what
> >
> > addPortCtrlEvents, MidiPort, MidiCtrlVal etc
> >
> > are for? I don't understand why we need to keep a list of PortCtrlEvents
> > :/
> >
> > I hope you can help me,
> >
> > Greetings
> > flo
>
> Each MidiPort has a "MidiCtrlValListList* _controller" member.
>
> This list holds all midi controller values, SEPARATE from but
> identical to each part's event list.
>
> The purpose of the list is to speed up retrieval of controller values
> during SEEK (FF or REW of cursor).
>
> If instead SEEK had to weed through hundreds of different types of events
> in each part's event list looking for controller events, that could slow
> things down.
> So these separate lists are kept.
>
> When controller values are entered, like via the pianoroll controller
> graphs, the events are added to the part's event list just like notes as
> usual, but these events are ALSO added to these MidiPort controller lists.
>
> The purpose of the addPortCtrlEvents() functions is to ensure,
> during certain operations, that the values in these lists are
> up to date - the values are copied directly from the part event lists.
>
> For example: Suppose you change a midi track's output port or channel.
> Now the MidiPort's controller list is holding STALE invalid values from
> some other previous track's part.
> So addPortCtrlEvents() is called to update the MidiPort's controller list
> directly from the track part's event list.
> Note that there is a corresponding removePortCtrlEvents() which
> is sometimes called before addPortCtrlEvents() is called, especially
> in this example of changing a track's output port or channel.
>
OK now for the bad stuff:
I've explained it several times but it's so wide-ranging and complex,
I'm not sure how much you remember, so it is worth repeating now.
MidiCtrlValListList is a "list of lists": A list of MidiCtrlValList, one for
each midi controller number in use on a port.
Each MidiCtrlValList holds the graph, as well as a current 'manual' value.
Long ago MidiCtrlValList was a simple STL map.
Time was the key and midi controller value was the data.
But this made it impossible to determine who put the value there.
That is, if you erase a graph value, while another graph in another part
on the same output port and channel also has a value at that time,
you can't just erase the value from the list 'cause another part has a
value there as well.
So I had to make the list a multimap, and each data items is a structure
containing the value AND a pointer to the part who put that value there.
Thus when erasing graph values, it quickly can just erase what's needed
from the list while preserving other values at that same time value,
put there by other parts.
The whole concept of allowing two DIFFERENT graph values at the same
time value on two parts on the same port and channel is ideal but *flawed*
My multimap fixed the immediate problem, but still the whole
idea of two different values is *arbitrary* which is bad policy for MusE.
The driver comes along and sees multiple values at a time, so it
arbitrarily picks the first one (I think - I believe I do not send out
driver multiple values at a time).
Naturally you might say why don't we just make all points on these
graphs on the same output port and channel more consistent:
both graphs should be *identical*
But, I'm not crazy about that idea - it's changing user's data behind
his back, I prefer to keep graphs intact: If user changes a track's
output port or channel, we would discard all of its part graphs in
favour of what? Another track's part graphs? Switching port/channel back
again, his previous graph is lost. Makes no sense and is also arbitrary.
So what can we do, eh? It's so arbitrary....
Why not mute controller graphs if the track is muted, giving the user
some control over the situation? Remember: Multiple recording 'takes'
on the same port and channel are common for MusE-ers.
Well, remember my post a while back about muting controllers?
Turns out we can't really do it without affecting the midi knobs/sliders.
So we mute only notes for now :(
Hmm... Darn must revisit - can I do it? Good argument here, muting would
really help with reverting back to STL map....
Flo, I know one solution for reverting midi controllers to STL map is this:
==========================================================
After each erasing operation(s) (graph etc), the track list shall be
reiterated and this MidiPort's MidiCtrlValList *refreshed*
but only at the particular time values involved, erasing if nobody
else wants a value there.
So we have our STL map - simple natural "one value per time value".
And we can eliminate some other stuff too like some of those
portCtrlEvent functions - or else some of their parameters.
I was planning to try this.
...
I still might not be able to do this for a while.
What say you Flo? Can you rig something up? Know what I mean?
You get to kill some stuff too! Yay.
Reiterating tracks and parts after each erase (or 'group' of erases) is
fairly fast? We ignore tracks not on the same output port and channel,
and look for parts bounding the particular time value(s) involved.
It's still arbitrary, for the driver, you're picking the first part controller
value you find or else erasing from the list, but it's a good step.
OK that takes care of 'erasing' but what about 'adding' policy?
In the MidiPort's controller list we either:
a) If a value already exists at this time value , do *nothing* - the
existing value stands!
b) Replace any existing value!
Well, ye can see this is arbitrary too - STL map wants only one value...
Note that with b) the order of replacing would not be the same
order as removing but that's nitpicking anyway - it's all arbitrary.
I would dearly like to unify our audio controller (which is STL map)
and our midi controller classes. This would be the first step.
If we can eliminate the midi controller multimap crap, great.
Also, recall I talked of making audio and midi controller graphs
more consistent - that is either make them BOTH 'track' controllers
or make them both movable 'part' controllers.
I had thought making them both movable 'part' controllers would require
using STL multimap for audio controllers.
But you know, if you can rig up a fast track re-iterator and refresh
these reverted-to-STL-map MidiPort controller lists quickly... Whee...
Thanks Flo!
Tim.
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Lmuse-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmuse-developer
