Am 29.08.2013 04:23, schrieb Tim E. Real: > 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 >>
> 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).
> [...] changing user's data behind his back [...]
I agree we should not do this.
> 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.
If I understood you correctly, you want to still keep those values in
MidiPort's MidiCtrlValList, turn it into a STL map again and only fix
the refreshing of that list. Right?
> I would dearly like to unify our audio controller (which is STL map)
> and our midi controller classes. This would be the first step.
[...]
> 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 *DEFINITELY* want this.
I thought about the concept of Midi Controllers in the past, too.
The concept of having controllers on a part *is* flawed, because parts
may overlap. So make all controllers track-controllers.
But that's bad as well, because when moving a MIDI part, I usually want
to move its controllers as well. They're part of the music I move. So
make them part-controllers :/
My idea to escape this was:
1. MIDI parts have a special need for carrying controllers themselves;
WAVE parts might have it, as well... We'll see.
=> So let them have part controllers.
the behaviour for overlapping parts is undefined.
2. both MIDI and WAVE (and all other) tracks must have track-controllers
(currently referred to as "automation". I don't like this name.)
These "track-controllers" are *in addition* to the part controllers.
value_sent = value_track * value_part, where value_track ranges from
0% to, let's say, 200%. (Clipping at the maximum, of course).
This will replace the Trackinfo's spinboxes for "Note+", "Velocity"
etc.
3. each *track* will have such a "quick-access" MidiCtrlValList.
MidiPort will *not* have this any more. It will only see the current
values the hardware sees as well.
4. upon every seek, we must iterate through *all* tracks which use that
MidiPort (only non-off tracks, of course). This will be pretty fast,
because i guess there won't be more than 5 Tracks on one MidiPort.
When there are concurrent CtrlValues, behaviour is undefined (first
come, first serve)
5. MidiTracks must have an option to "disable" certain controller IDs
for them.
6. We Clearly state: "When there are overlapping controller graphs (of
the same controller id and (parts of) tracks of the same midiport.
with the tracks having this controller ID not disabled as in 5.):
Then the controller value sent out to the hardware *is UNDEFINED*"
This does not invalidate your considerations above. It just moves them
away from MidiPort, into MidiTrack.
We still need a quick way for accessing "the controller#2-value of this
track at this time".
I guess a
vector < map < XTick, set < pair<value_t, Part*> > > > will be the right
thing to do. (where map< foo, set<> > might be replaced by multimap.)
So what will happen upon seek?
int ctrl_values[128] = {0,0,0,0, ...};
someone calls MidiPort::seekToTick(XTick tick).
FORALL MidiTrack* miditrack WHERE miditrack->outport=this:
FOR i=0 TO 127:
IF miditrack->isCtrlEnabled(i):
ctrl_values[i] = miditrack->getCtrl(i, tick);
MidiTrack::getCtrl(i, tick) does the following:
let "vec" be the above vector < ... >
set<pair<val_t,Part*>> result = vec[i].find_last_smaller_than(tick);
return result.arbitrary_element()->value();
I guess this is basically what we have now, and i'm afraid this is the
best way to do it.
turning the multimap into a map again would force us to (slowly) rebuild
that map after every event modification (or group of...), which is,
well, slow. Unless I missed something of your point ;)
Tim, one really important question: has anyone ever really felt that
seeking is slow, when we just iterate through all tracks, through all
parts, through all events, for finding out the controllervalues to send out?
If that is NOT too slow, when we're facing an incarnation of
"premature optimisation is the root of all evil".
> 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...
I think we just should hide all that multimap crap from the rest of MusE.
class Track needs three functions:
Track::getCtrlValAtTick(XTick tick)
Track::addCtrlValChange(XTick tick, value_t val, const Part* part)
Track::delCtrlValChange(XTick tick, value_t val, const Part* part)
the add and delCtrlValChange functions may *ONLY* be called from the one
central point where changes are made: Song::doRedo[123]
(note: in my audiomsg_overhaul branch on github.com/Windfisch, I'm doing
these changes which solve all problems that might arise:
- there is no ModifyPart any more. A Part pointer will never, ever
change. All changes to Parts are now made, well, to the Part, and not
by replacing the old Part with an updated duplicate of this Part.
- MusE's sequencing thread does not know about "clones" any more. They
have separate eventlists, and only the "central point where changes
are made" knows about their clone-ness and updates *all* parts
accordingly
- there will be no msg{Add,Delete}{Event,Part,Track} any more. Instead,
all kinds of operations are done through song->applyOperation[Group],
which then does what doRedo* does.
i.e., there is no more duplicate code in msgDoStuff(), and the
redo-code for DoingStuff.)
If you agree with me, i can try to incorporate these considerations and
fix the stuff.
Cheers,
flo
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
