From: Chris C. <ca...@al...> - 2004-06-28 19:39:10
|
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 |