Re: [Rosegarden-devel] Multiport recording - feature design

[Chris C. <ca...@al...>]

On Monday 28 Jun 2004 7:16 pm, Pedro Lopez-Cabanillas wrote:
> The note duration detection is based on a single map (m_noteOnMap,
> member of SoundDriver). The map handles a event for each noteon
> received, and it's updated with the note length when a noteoff is
> received. When you record from several input sources, two musicians
> can collide in the same note, and one is lost (and the other note
> may have a wrong length).
>
> How to solve this? One map for each subscription to the input port?
> Where? Move the m_noteOnMap(s) to the driver level? (ArtsDriver
> uses this trick, too). Any idea is welcome.

I'm not sure about "solving" this, as in fact it seems like rather a 
fundamental problem with the whole idea (that admittedly I should 
have thought of but didn't).  So long as these events are ultimately 
destined for the same channel on the same MIDI device, which if 
they're stored in the same segment they must be, then note on/off 
events on the same pitch originating from separate performers will 
always end up being bungled, and there's nothing you can do about it.

The only options are (1) to always automatically split into multiple 
tracks when recording like this -- which is the multi-track recording 
goal, but we were presumably trying to avoid having to go the whole 
hog with that at the outset; (2) to permit a single track to contain 
notes that play to more than one channel or instrument, with the 
associated GUI confusion; (3) to live with the note on/off bungling 
on playback, on the assumption that if you know enough to be doing 
this and you care about the problem, you can just split the track 
yourself.

(1) would be fine but is really a bigger project than we should 
probably be doing now.  (2) is IMHO a bad idea all round, and (3) is 
fairly unsatisfactory from a user perspective, although it might be 
tolerable if the feature wasn't widely advertised anyway.

To answer the question you were actually asking: m_noteOnMap is a 
SoundDriver data member but it's not referred to in any SoundDriver 
code and there are no public SoundDriver methods using it.  Ergo, 
there's no compelling reason it should be a member of SoundDriver 
rather than the subclasses.  And it's a bit of a hack anyway; 
conceptually it's really a map<ChannelNo, map<Pitch, MappedEvent *> > 
but the channel number and pitch have been rolled into a single int 
for brevity.  I would see no problem with unrolling them, giving a 
more complex definition but probably simpler usage, and making it 
obvious how to include another level of indirection (say to map from 
origin port to channel number to pitch to mapped event).  The problem 
is more that I don't see how this would help, since the events would 
then all be sent off to the same channel on the same MIDI device 
anyway.


Chris