From: Yves G. <yc....@wa...> - 2010-11-17 22:43:44
|
I tried to use Ian'implementation of segment links to make repeated segments visible but found some problems. In this implementation all visible linked segments are symmetrical. All of them are looking to a central reference segment which lies in a special container of the composition and is (currently) not visible directly. When a segment link is created, the original segment is copied in the reference segment, then is moved out of the composition and replaced with a link to the reference. It's easy to see an issue related to this process: - create a segment - open it in notation editor - in main view, create a link of the segment with ctrl-midclick-drag ==> The editor close itself The same issue prevents me to use segment links created on the fly in the notation editor: The edited segment is removed from the composition, and, apart from the possible editors being closed, I find difficult to replace the old original segment with the new one in the parents of the running editor. Moreover, I need to distinguish between original segment and its clones to show the repeating segments in a different colour. Thats why I suggest some modifications to Ian'implementation. They are currently working (most of the time...) in the repeats_and_segment_links branch. There is no more central reference segment outside the visible composition. The original segment if now used as the reference segment and is keeped inside the composition. LinkedSegmentReference and LinkedSegment classes are no more derived from Segment and are renamed LinkedSegmentReferencer and SegmentLinker. They are independent objects owned by reference (original) segment and segment link respectively. The referencer (LinkedSegmentReference) contains the links to all the clones. The linker (LinkedSegment) is a link to the reference. The reference segment is a link to itself and it owns both a referencer and a linker. A clone segment owns only a linker. An ordinary segment owns neither a linker nor a referencer. One and only one referencer must exist in a group of segments linked together. (Maybe to maintain the SegmentLinker (old LinkedSegment) as an independant object is not very useful and it could be merge into the Segment class. The whole code needs some clean up). The repeats_and_segment_links branch should show the same behavior than linked_segment_ian branch (except the unwanted closing of editors) with, in addition, the repeated segments shown in notation editor. Nevertheless there are some issues (which should be solvable) : - It's not as stable as it should be: Moving around segments, mainly repeating ones, while editing them may crash RG. Editing all segments of bogus-surf-jam in notation crash RG (nevertheless, there is no such problem with stormy-riders). - I just realized that copy-draging (or, now, link-draging) segments in the main window, that's the original segment, and not, as supposed, its copy or its clone which is moved with the mouse. BTW maybe that's the reason why, some years ago, the "(copied)(copied) (copied)" string in segment labels always seems to be on the wrong segment. This results in strange things when linking to an already linked segment. - There is some other less important problems... Thanks to any feedback. Yves |
From: D. M. M. <mic...@ro...> - 2010-11-18 08:47:42
|
On Wednesday, November 17, 2010, Yves Guillemot wrote: > The repeats_and_segment_links branch should show the same behavior than > linked_segment_ian branch (except the unwanted closing of editors) with, in > addition, the repeated segments shown in notation editor. This sounds like good news, but at the same time it has me worried about the work Ian has in progress. I'd like to see you two settle on a common approach pretty soon, before getting into too much detail work refining all of this out into a final set of features. I didn't have time to really put your branch through its paces and compare it to Ian's. I did have time to play with repeating segments in notation, and this is very exciting. The layout looks awful, and we need some hack to avoid showing the clefs, but the foundation concept is extremely cool. If we can figure out how to do bar lines properly, this is really going to be something. Now how does this change what Ian is working on for his branch, where he is thinking about introducing the ability to have linked segments take on different transpositions? I'm not paying that much attention to how either of your two approaches really works deep down, so I don't know if this is easy to move back and forth, or something that's going to be very unique to one approach other the other. Let's figure out how to have our cake and eat it too. Both sets of features you two are working on are really worthwhile and exciting, and this all has enormous potential. Especially when we solve the bar line problems. If I catch some time away from studying, I should start looking at that myself, because I've spent the most time researching the underlying issues. We're going to need "performance bars" and "notation bars" in here, and a lot of other refinements too. I expect this to be more fun than smacking myself in the head with a brick, but only just. -- D. Michael McIntyre |
From: Chris C. <ca...@al...> - 2010-11-18 10:26:01
|
On Wed, Nov 17, 2010 at 10:43 PM, Yves Guillemot <yc....@wa...> wrote: > The original segment if now used as the reference segment and is keeped > inside the composition. What happens to the linked copies if you delete the original segment? I assumed that Ian's "peer-to-peer" approach was intended to avoid the problem of having the user keep track of which one was supposed to be the original and having to treat it specially. That seemed like an attractive feature to me. But I can see that, if you do it that way, you don't get to use the structure in situations where there really _is_ a master segment involved, i.e. where you have a segment followed by a number of repeats that are implemented as links. Chris |
From: Yves G. <yc....@wa...> - 2010-11-18 21:01:49
|
Le jeudi 18 novembre 2010 11:25:48, Chris Cannam a écrit : > > What happens to the linked copies if you delete the original segment? > Currently one of the linked copies (the first one in the list) is promoted to reference segment. > I assumed that Ian's "peer-to-peer" approach was intended to avoid the > problem of having the user keep track of which one was supposed to be > the original and having to treat it specially. That seemed like an > attractive feature to me. My first aborted attempt to get segments linked was using an asymmetric scheme. I was even thinking to remove all the linked segments if the original one was deleted. So Ian's approach surprised me first, but certainly it's may be what most users want. > > But I can see that, if you do it that way, you don't get to use the > structure in situations where there really _is_ a master segment > involved, i.e. where you have a segment followed by a number of > repeats that are implemented as links. > The modified Ian's implementation should be both asymmetric and peer-to-peer. Asymetric for the developer's needs and peer-to-peer from the user's point of view. Yves |
From: Ian G. <ilg...@ya...> - 2010-11-18 13:02:08
|
----- Original Message ---- > From: Chris Cannam <ca...@al...> > > I assumed that Ian's "peer-to-peer" approach was intended to avoid the > problem of having the user keep track of which one was supposed to be > the original and having to treat it specially. That seemed like an > attractive feature to me. > > But I can see that, if you do it that way, you don't get to use the > structure in situations where there really _is_ a master segment > involved, i.e. where you have a segment followed by a number of > repeats that are implemented as links. > Ah, it sounds like the classic software engineering debate! Does one go master-slave or peer-to-peer? svn or git? ITunes or Napster? I guess that whichever approach we hit upon, we'll have to fudge it slightly for the other use-case. Off the top of my head, I'm pretty sure that my basic peer-to-peer architecture could be specialised where appropriate (by further subclassing or dumping extra parameters in) to handle the master-slave case. The phenomenon of segment editors sometimes vanishing when changes to segments are made already happens in RG I believe, when you rescale a segment for example (not at my linux machine at the moment so can't verify this, but any segment command which replaces the original will suffer from this I'd have thought). It therefore seems like some ability to reparent an editor on a replacement segment set would be generally useful, not just in the case of linked or repeated segments. I also have a mechanism for copy-dragging the copied segment rather than the original segment, but I didn't commit it before just to retain consistency with the current copy-drag behaviour. It's always struck me that you ended up dragging the wrong thing after any copy operation though. Over the next couple of days I'll update and compile Yves' branch, have a strong cup of coffee, and try to get my head round all the issues. Cheers all, Ian. |
From: D. M. M. <mic...@ro...> - 2010-11-18 21:02:02
|
On Thursday, November 18, 2010, Ian Gardner wrote: > It therefore seems like some ability to reparent an editor on a replacement > segment set would be generally useful, not just in the case of linked or > repeated segments. The "add layer" command does something similar now. You start with a view of segment X, segment Y gets created and the view is repopulated to include it. That had some very serious bugs that Yves seems to have worked out successfully. The view still goes away when the last segment winks out of existence, but we can probably trap this and repopulate the view again. The groundwork is there now, with some testing and debugging of the concept of changing things out from under a live and active view. > Over the next couple of days I'll update and compile Yves' branch, have a > strong cup of coffee, and try to get my head round all the issues. That sounds good. I think we're all closer to middle ground than it sounds like on all of this stuff. Mostly I just want to see all of it come to pass, because this is really cool all around! I have no opinion whatsoever on the peer-to-peer vs. master-slave debate though. I'm going to be far too busy for the next four months to get into anything that deep, I'm afraid. I'm hanging back as a coordinator and paper pusher, but won't be able to do much heavy lifting, or thinking. -- D. Michael McIntyre |
From: Yves G. <yc....@wa...> - 2010-11-18 21:23:33
|
Le jeudi 18 novembre 2010 14:02:01, Ian Gardner a écrit : > > Ah, it sounds like the classic software engineering debate! Does one go > master-slave or peer-to-peer? svn or git? ITunes or Napster? > I hope I didn't start such a debate. > I guess that whichever approach we hit upon, we'll have to fudge it > slightly for the other use-case. > > Off the top of my head, I'm pretty sure that my basic peer-to-peer > architecture could be specialised where appropriate (by further > subclassing or dumping extra parameters in) to handle the master-slave > case. I proposed the first solution I found only. No doubt better ones exist. > > > The phenomenon of segment editors sometimes vanishing when changes to > segments are made already happens in RG I believe, when you rescale a > segment for example (not at my linux machine at the moment so can't verify > this, but any segment command which replaces the original will suffer from > this I'd have thought). This issue is not really important. It was only a way to explain the problem I had. > > I also have a mechanism for copy-dragging the copied segment rather than > the original segment, but I didn't commit it before just to retain > consistency with the current copy-drag behaviour. It's always struck me > that you ended up dragging the wrong thing after any copy operation > though. > That current behaviour give strange results with my code. And I just didn't understand how it works until now. Yves |
From: Yves G. <yc....@wa...> - 2010-11-18 20:22:52
|
Le jeudi 18 novembre 2010 09:47:28, D. Michael McIntyre a écrit : > > This sounds like good news, but at the same time it has me worried about > the work Ian has in progress. > > I'd like to see you two settle on a common approach pretty soon, before > getting into too much detail work refining all of this out into a final set > of features. Probably I forgot to say I copied Ian's branch into mine before doing some modifications. I hope Ian will recognize his code still. > > Now how does this change what Ian is working on for his branch, where he is > thinking about introducing the ability to have linked segments take on > different transpositions? I'm not paying that much attention to how either > of your two approaches really works deep down, so I don't know if this is > easy to move back and forth, or something that's going to be very unique > to one approach other the other. There is only one approach: Ian's one. Mine never works. I only replace the hidden central reference segment Ian uses with one the visible segments already in the composition. Nothing should change about the transposition and other transformation possibilities. Yves |
From: D. M. M. <mic...@ro...> - 2010-11-18 20:48:06
|
On Thursday, November 18, 2010, Yves Guillemot wrote: > There is only one approach: Ian's one. Mine never works. Oh. I've been there before! > Nothing should change about the transposition and other transformation > possibilities. That's easy then. -- D. Michael McIntyre |