From: Richard B. <ric...@fe...> - 2012-08-02 12:38:03
|
Talking of time... to save me some can anyone tell me briefly what I need to do at the sequencer level to get the channel number for a MappedEvent these days? I can see they've gone but for the life of me can't work out where they've gone to. Cheers, R On 1 Aug 2012, at 21:40, "D. Michael McIntyre" <mic...@ro...> wrote: > On Wednesday, August 01, 2012, Ted Felix wrote: > >> Wish I had more time. I'll see what I can do with what little I have. > > Rosegarden really appreciates what time you do have, Ted. It's a lot more > than what I've got, and I couldn't achieve what you do if I had twice the time > in which to do it. > -- > D. Michael McIntyre > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Rosegarden-devel mailing list > Ros...@li... - use the link below to unsubscribe > https://lists.sourceforge.net/lists/listinfo/rosegarden-devel |
From: Tom B. (Tehom) <te...@pa...> - 2012-08-02 16:58:16
|
> Talking of time... to save me some can anyone tell me briefly what I need > to do at the sequencer level to get the channel number for a MappedEvent > these days? I can see they've gone but for the life of me can't work out > where they've gone to. By "sequencer level", I'm not sure what you mean. As MappedEvents come into AlsaDriver, the channel is always the recorded channel, accessed thru MappedEvent::getRecordedChannel(). That used to be only for recorded notes, now outgoing notes set it too. Or do you mean before that, how the channel number is found for it? The dump() methods for MappedEventBuffer descendants do it in various ways. For "normal" events (not time signatures etc), they use a ChannelManager which figures it out. Hope that helps. More detail if you need it. On more general lines, the page http://www.rosegardenmusic.com/wiki/dev:how_a_note_becomes_a_sound may be of some help. It walks you through the whole process of how a note becomes a sound. Tom Breton (Tehom) |
From: Richard B. <ric...@fe...> - 2012-08-02 20:23:38
|
> > By "sequencer level", I'm not sure what you mean. > Sorry, force of habit - I still think of them as two applications... As MappedEvents come into AlsaDriver, the channel is always the recorded > channel, accessed thru MappedEvent::getRecordedChannel(). That used to be > only for recorded notes, now outgoing notes set it too. > So to be clear if I want to find the MIDI channel of a Note On I use getRecordedChannel() too? And if I record a Note On I want to set the same property in a new MappedEvent before passing that back? > Or do you mean before that, how the channel number is found for it? The > dump() methods for MappedEventBuffer descendants do it in various ways. > For "normal" events (not time signatures etc), they use a ChannelManager > which figures it out. > Thanks, this will be useful too. I've been so far studiously ignoring Devices/Instruments but I need to tie this up soon. > On more general lines, the page > http://www.rosegardenmusic.com/wiki/dev:how_a_note_becomes_a_sound may be > of some help. It walks you through the whole process of how a note > becomes a sound. > Great, that was the page I was looking for earlier. Should be enough to help me make a bit of progress. Thanks, R |
From: Tom B. (Tehom) <te...@pa...> - 2012-08-02 20:45:03
|
> As MappedEvents come into AlsaDriver, the channel is always the recorded >> channel, accessed thru MappedEvent::getRecordedChannel(). That used to >> be >> only for recorded notes, now outgoing notes set it too. >> > > So to be clear if I want to find the MIDI channel of a Note On I use > getRecordedChannel() too? Right. > And if I record a Note On I want to set the > same > property in a new MappedEvent before passing that back? Yes, using setRecordedChannel(), and that's exactly how we do it in AlsaDriver::getMappedEventList(). That code might be of some help to you even if you can't directly use it. Tom Breton (Tehom) |
From: Tom B. (Tehom) <te...@pa...> - 2012-08-03 17:40:32
|
Ted: I noticed on the bugs/commit list you were asking about a lock in the iterator::peek() method. > // ??? This lock seems odd. We are returning a pointer to the > // MappedEvent in the buffer. So the caller uses a pointer > // into the buffer after the read lock is released. Is that > // correct? That would mean that this lock only locks the > // container, not the elements in the container. This would > // prevent changes to the "fill" before getting the element. I can shed a little light on it, though not as much as I'd like. I was very conservative about what I changed, as you have noticed with the isMetronome method, "res"/"resize", et al. The lock comes from before my time, so I may not fully understand its purpose, but I'll tell you what I can. One thing with the mappers is that we accept a few glitches if the segment (etc) is being edited while we're playing. It's been that way for a long time and it seems to be tolerable to users. What the lock prevents is grabbing an event just as resizeBuffer reallocates the whole buffer. Then the pointer points into deleted space. And yes, ISTM it should lock in the caller, not in peek. fillNoncompeting is the only caller. It passes the pointer to inserters, but those just (normal) copy the event or (midi) make something else, so that's the full extent of the pointer exposure. I notice you've done a lot of fine work on this, Ted. Thank you. I noticed you commented about the isMetronome method. I fully agree. As I mentioned, I was very conservative in what I changed. Really, the whole "else if (cur->getType() == X)" / acceptEvent maze seems to be the proper concern of the various derived classes. I'm reluctant to edit the code while you are working on the same files, and I trust your judgement. Tom Breton (Tehom) |
From: Ted F. <te...@te...> - 2012-08-06 23:19:33
|
On 8/3/2012 1:40 PM, Tom Breton (Tehom) wrote: > Ted: I noticed on the bugs/commit list you were asking about a lock in the > iterator::peek() method. Thanks for the info. I thought it through a little more and checked in some more informative comments inspired by your points. As for status on Aere's issues, I've been working on figuring out where the Note Off without Note On messages are coming from. Using a hacked up version of seqdemo.c (the ALSA sequencer demo code) I was able to determine that we are getting duplicate note on and note off messages from ALSA. This is not rg's fault. However, whether rg handles them "well" remains to be seen as I've not gotten that far. And whether these duplicate events are in any way related to the missing events is still not clear to me yet. But I am still chipping away at this. Ted. |
From: Ted F. <te...@te...> - 2012-08-09 19:03:44
|
Status update. I've whittled down the Beethoven acid test to a small MIDI file that causes lots of trouble for rg. I've opened a bug report (3555441) for this and will continue to update status there: http://sourceforge.net/tracker/?func=detail&aid=3555441&group_id=4932&atid=104932 My feeling is that the crash (and other problems) when the composition gets expanded (3546135) is higher priority than the Beethoven issue. So I'm going to switch back to that... Ted. |
From: Aere G. <Aere@Dvorak-Keyboards.com> - 2012-08-09 19:38:06
|
Ted: Thanks for the update, and your work on this problem. I agree with your decision on the relative priorities of the problems. - Aere On Thu, 2012-08-09 at 15:03 -0400, Ted Felix wrote: > Status update. > > I've whittled down the Beethoven acid test to a small MIDI file that > causes lots of trouble for rg. I've opened a bug report (3555441) for > this and will continue to update status there: > > http://sourceforge.net/tracker/?func=detail&aid=3555441&group_id=4932&atid=104932 > > My feeling is that the crash (and other problems) when the > composition gets expanded (3546135) is higher priority than the > Beethoven issue. So I'm going to switch back to that... > > Ted. > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Rosegarden-devel mailing list > Ros...@li... - use the link below to unsubscribe > https://lists.sourceforge.net/lists/listinfo/rosegarden-devel -- Sincerely, Aere |
From: Tom B. (Tehom) <te...@pa...> - 2012-09-05 17:32:35
|
I committed a few changes to the edit-controllers branch: * Fixed a bug where percent ranges didn't actually cover the range unless the default value exactly split the range (as PitchBend does but most controllers don't) * Fixed a potential static initialization order fiasco * Brought in the recent trunk/ changes. Tom Breton (Tehom) |
From: Tom B. (Tehom) <te...@pa...> - 2012-09-06 23:52:50
|
We talked about refactoring the mapper classes, in particular moving the special metronome stuff from the base class into the metronome mapper, and making peek's read lock actually do some protecting. I coded that and committed it on new branch refactor-mapped-buffer I've moved the read lock in MappedEventBuffer::peek into MappedBufMetaIterator functions so that it covers the entire scope during which the MappedEvent pointer is exposed. It's not perfect, because caller has to know to do that, but it's much better than my first solution. Tom Breton (Tehom) |
From: Ted F. <te...@te...> - 2012-09-07 01:16:48
|
On 09/06/2012 07:52 PM, Tom Breton (Tehom) wrote: > I've moved the read lock in MappedEventBuffer::peek into > MappedBufMetaIterator functions so that it covers the entire scope during > which the MappedEvent pointer is exposed. It's not perfect, because > caller has to know to do that, but it's much better than my first > solution. Thanks, Tom, all this stuff you've been doing looks really good. Would it be possible to make a copy of the event in order to reduce the time that it is locked? Just a random thought. Not sure if making a copy even makes any sense. Just seems like with all the multi-threading stuff I've been reading, it's not uncommon to copy some data to reduce locking periods. I've unfortunately had little opportunity to work with multi-threading. Hoping to get more into it soon. Ted. |
From: Tom B. (Tehom) <te...@pa...> - 2012-09-07 02:35:37
|
> On 09/06/2012 07:52 PM, Tom Breton (Tehom) wrote: >> I've moved the read lock in MappedEventBuffer::peek into >> MappedBufMetaIterator functions so that it covers the entire scope >> during >> which the MappedEvent pointer is exposed. It's not perfect, because >> caller has to know to do that, but it's much better than my first >> solution. > > Thanks, Tom, all this stuff you've been doing looks really good. Thanks. > Would it be possible to make a copy of the event in order to reduce > the time that it is locked? Just a random thought. Not sure if making > a copy even makes any sense. That was definitely an alternative I had in mind. IMHO it isn't worth it on the balance. Here are some points I considered: * That would be cleaner. * There's no threat of future modifications innocently holding a pointer past the scope of the lock. * If we did that, we'd generally be allocating the MappedEvent (or something resembling it) twice, because the inserting end really wants to do the allocating itself so that it has full control for flexibility. Eg, the MidiFile stuff actually inserts another kind of object, and the channel code inserts not only (a copy of) the MappedEvent we give it but sometimes other MappedEvents to set up the channel. That could be finessed at the cost of some added trickiness. * Sometimes events are merely skipped by later tests after peek() gives us them. Eg for muted tracks, or events that will be played in a later slice, which actually make up the majority of events that the inner loop sees if my music is at all typical. If we allocated it in peek() or immediately after, we'd just have to delete most of them again without ever using them. * The MappedBufMetaIterator inner loop is a hot spot, so I'm reluctant to add an avoidable allocate+delete to it. * We can only get a conflict when we're reading and writing at coarsely the same time, ie the user is editing stuff while playing. That use case is considered less crucial than playing smoothly while nothing is being jiggled. * We're only locking it against resizing the buffer, everything else gets through. > Just seems like with all the > multi-threading stuff I've been reading, it's not uncommon to copy some > data to reduce locking periods. I've unfortunately had little > opportunity to work with multi-threading. Hoping to get more into it > soon. I know just what you mean. I hadn't seriously wrestled with multi-threading before Rosegarden either, though of course I knew about it in theory. Tom Breton (Tehom) |
From: D. M. M. <ros...@gm...> - 2012-09-07 03:02:43
|
On 09/06/2012 10:35 PM, Tom Breton (Tehom) wrote: > * We can only get a conflict when we're reading and writing at coarsely > the same time, ie the user is editing stuff while playing. That use case > is considered less crucial than playing smoothly while nothing is being > jiggled. That's about the size of it. If weird things happen when editing while playing back, it's normally just weird glitches that aren't worth running down. One exception I can think of is the case where somebody has the transport in loop mode so they can work out some drum sequence. We want the next iteration of the loop to be reasonable, and not play notes that have been deleted, etc., so this can be a useful process. Wrapping glitches (ie. annoying pauses) on either end of looping via the transport are acceptable, so long as they're not ridiculous. No idea if any of the above comments were relevant. Just summarizing my understanding of a bit of historical project agreement. -- D. Michael McIntyre |