From: Guillaume L. <gla...@te...> - 2002-07-24 23:09:32
|
I've been working on that Event setDuration problem, and I don't think there's a way to avoid re-creating an event. It's not really a big deal either because the copy won't have any performance impact, however I haven't committed that change yet because it seems matrix insert undo is completely broken (open a matrix view on an empty segment, insert a note : the note doesn't go away. If you insert two notes and undo twice, only the the last inserted note will go away). There's also the fact that you no longer can insert a note by just clicking on the matrix without dragging. A rectangle appears, but goes away as soon as you try to insert another note. Most puzzling. *sigh*. -- Guillaume. http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2002-07-25 09:12:41
|
Guillaume Laurent wrote: > [...] it seems matrix insert undo is completely broken The problem really is that we have a mixture of paradigms in the matrix editor. The insertion code first creates a matrix element (view object) containing an event (model object) and then inserts the event into the segment. But the more usual paradigm elsewhere is to create the event and insert that, and then use the refresh logic to observe that the event has been created, allow the view object to be created for it (by the Staff's wrapEvent mechanism) and then position and show that. Because of that dichotomy, we've ended up with nasty code like the setWrapAddedEvents calls in MatrixInsertionCommand which suppress the normal flow of the refresh logic in order to make the insertion code's logic work. Chris |
From: Guillaume L. <gla...@te...> - 2002-07-25 09:28:49
|
On Thursday 25 July 2002 11:11, Chris Cannam wrote: > Guillaume Laurent wrote: > > [...] it seems matrix insert undo is completely broken > > The problem really is that we have a mixture of paradigms in > the matrix editor. Yup. It seems my local changes have broken it (I thought I had reversed=20 everything for my last tests), as it's working here at the office. Can yo= u=20 check if it still works ok for you ? If so I'll just reset to CVS at home= and=20 start again. --=20 =09=09=09=09Guillaume =09=09=09=09http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2002-07-25 10:38:01
Attachments:
diff
|
Guillaume Laurent wrote: > It seems my local changes have broken it [...] Well, I don't think it's worth starting from the "working" command, because it still works the wrong way -- far better to modify the code (including the command) so as to work by adding the event and then letting refresh do the rest, and then worry about whether the details work or not. For example, the attached patch (against current CVS) appears to work for me, and hugely simplifies the code by getting rid of all the disgusting setWrapAddedEvents stuff. It doesn't quite do the right thing for drags leftwards though (i.e. endTime < time in the mouse release event), and there are probably other bugs. Chris |
From: Richard B. <bo...@bo...> - 2002-07-25 10:44:46
|
Chris Cannam wrote: > For example, the attached patch (against current CVS) appears to > work for me Works for me too - so I've committed it. B |
From: Guillaume L. <gla...@te...> - 2002-07-25 11:56:03
|
On Thursday 25 July 2002 12:44, Richard Bown wrote: > Chris Cannam wrote: > > For example, the attached patch (against current CVS) appears to > > work for me > > Works for me too - so I've committed it. I wish you hadn't. Ah well. --=20 =09=09=09=09Guillaume =09=09=09=09http://www.telegraph-road.org |
From: Guillaume L. <gla...@te...> - 2002-07-25 11:55:22
|
On Thursday 25 July 2002 12:36, Chris Cannam wrote: > Well, I don't think it's worth starting from the "working" command, > because it still works the wrong way -- far better to modify the > code (including the command) so as to work by adding the event and > then letting refresh do the rest, and then worry about whether the > details work or not. I really disagree. Debugging undo is way harder, at least for me. I'd ver= y=20 much rather start from a point where undo is working, and your patch brea= ks=20 that. --=20 =09=09=09=09Guillaume =09=09=09=09http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2002-07-25 12:00:56
|
Guillaume Laurent wrote: > I'd very much rather start from a point where undo is working, and > your patch breaks that. When I said it works for me, I was talking about undo and redo as well as the original operation. Under what conditions does it fail for you? Chris |
From: Guillaume L. <gla...@te...> - 2002-07-25 12:06:37
|
On Thursday 25 July 2002 13:59, Chris Cannam wrote: > Guillaume Laurent wrote: > > I'd very much rather start from a point where undo is working, and > > your patch breaks that. > > When I said it works for me, I was talking about undo and redo > as well as the original operation. Under what conditions does > it fail for you? Open Matrix on a new segment, insert several (like 5 or more) items, try = to=20 undo. I generally get random results (each undo will either work or not).= I=20 don't think it's merely an update problem, because closing and re-opening= the=20 matrix view doesn't make any difference, for all I can see. --=20 =09=09=09=09Guillaume =09=09=09=09http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2002-07-25 13:54:03
|
Guillaume Laurent wrote: > Open Matrix on a new segment, insert several (like 5 or more) items, try to > undo. I generally get random results (each undo will either work or not). Were some of them very small items? If so, then I think this may be a consequence of not handling correctly the case where the mouse pointer hasn't moved or moves slightly left instead of right. If we ever pass an endTime that is equal to or less than the start time to the insertion command, the BasicCommand base won't have a chance to save any data and so no undo will happen. If the following undo covers a similar area, it may end up removing more than one element. Does that seem to describe the problem? If so, I think we can handle it and it's nothing to do with the command implementation. Chris |
From: Guillaume L. <gla...@te...> - 2002-07-25 13:56:16
|
On Thursday 25 July 2002 15:52, Chris Cannam wrote: > Guillaume Laurent wrote: > > Open Matrix on a new segment, insert several (like 5 or more) items, = try > > to undo. I generally get random results (each undo will either work o= r > > not). > > Were some of them very small items? No, all long ones. --=20 =09=09=09=09Guillaume =09=09=09=09http://www.telegraph-road.org |
From: Richard B. <bo...@bo...> - 2002-07-25 14:37:48
|
Ok, today's stuff: o Audio VU meters now work - at the moment they are exactly the same as MIDI vu meters. We can always change this later - it'd be nice to have maybe a different look to them and a different response to the MIDI vu meteres. o Live audio levels - selecting your recording source on the mixer and arming and audio track for record will allow you to preview the input level in real time (well, adjusted for JACK latency) o Audio latency dialog - modified it so that it now queries the jack server for its end-to-end latencies and sets values accordingly. You can still set it manually but it's recommended that you probably don't. o Previewing audio files in the AudioManagerDialog - now previewing audio files (so you can hear them) pops up an information dialog with a cancel button. At some point in the near future it might be cool to allow the user to assign audio files on this manager either to keys on your computer keyboard or even to the incoming MIDI stream - then the user could "play" audio files asynchronously over the top of their composition. The infrastructure is all in there for this stuff - it'd just require wiring up at some point. B |
From: Chris C. <ca...@al...> - 2002-07-25 14:50:08
|
Guillaume Laurent wrote: > On Thursday 25 July 2002 15:52, Chris Cannam wrote: > >>Were some of them very small items? > > No, all long ones. Hmm. In that case I think we're looking at a bug in BasicCommand that arose from the recent change to the way the Segment manages its start time. (The Segment now automatically adapts its start time according to the time of the first event in it, but we were relying on the start time as a fixed record for the area we'd need to save and restore.) Will fix. Chris |