From: Tom B. (Tehom) <te...@pa...> - 2011-11-29 04:23:07
|
I've been working a lot with controller events lately. I find I repeat the same kind of controller events, largely accents and diminuendos at the ends of phrases. It struck me that rather than write them anew each time and adjust them, it'd be easier to treat them as ornaments. I experimented a little, and it almost works. Triggered segments that hold controller events can be created. Having been created, they mostly behave as expected. The biggest problem is that they can't offset from the current value of a controller. * If a controller currently has a non-default value, they can sound funny. Eg an accent may be too loud or too soft relative to current instrument volume. * They can't leave a controller as they found it, at its original setting. What I propose to do is to make triggered segments' controller events relative to the original controller value. I don't believe that will mess anything up for anyone, because if I understand the situation, controller events largely aren't found in triggered segments now; it takes special effort to create that situation. I suspect that there's no call anyways for the behavior of ignoring current values. If I am mistaken, please speak up and enlighten me. FWIW, triggered segments that hold controller events can be created, but it's clunky: * Not by "Make triggered segment", which strips controller events. * Not by "Paste as triggered segment" in "Manage triggered segments", which again strips controller events. * What works: * First make a triggered segment by any means. * From "Manage triggered segments", edit it * Create or paste in controller events. It's easiest to copy them from another segment using the event editor. Tom Breton (Tehom) |
From: D. M. M. <mic...@ro...> - 2011-11-29 06:03:13
|
On Monday, November 28, 2011, Tom Breton (Tehom) wrote: > behave as expected. The biggest problem is that they can't offset from > the current value of a controller. The "current value" of a controller is really more complicated than it seems at a glance. I guess you could search back in time for the last thing Rosegarden actively set it to, and assume that's the current value, although there can be no assurance that's actually the case without setting up some complicated bidirectional communication between Rosegarden and the MIDI playback engine on the receiving end. I definitely wouldn't take it that far, so I suppose the assumption is the only realistic thing you could do, even though it's imperfect. I don't have any big objection to the spirit of making these things behave relative to the assumed "current value," but I'm also inclined to think that the behavior of stripping controllers out of ornaments is probably fundamentally reasonable due to all of these complications. Try to aim at preserving everything of the status quo while enabling the possibility of having new and separate opportunities for those who specifically want them, and actively seek them out. That's what I recommend. -- D. Michael McIntyre |
From: Tom B. (Tehom) <te...@pa...> - 2011-11-29 19:33:39
|
> On Monday, November 28, 2011, Tom Breton (Tehom) wrote: > >> behave as expected. The biggest problem is that they can't offset from >> the current value of a controller. > > The "current value" of a controller is really more complicated than it > seems > at a glance. I guess you could search back in time for the last thing > Rosegarden actively set it to, and assume that's the current value, > although > there can be no assurance that's actually the case without setting up some > complicated bidirectional communication between Rosegarden and the MIDI > playback engine on the receiving end. > > I definitely wouldn't take it that far, so I suppose the assumption is the > only realistic thing you could do, even though it's imperfect. Yes, I have been wondering how best to go about finding the previous value. Thank you for helping me think about that. If I understand correctly, SegmentMapper handles expanding triggers but doesn't keep an instrument up to date. So I can't get a current value from the instrument. So it probably makes sense to search backwards in events. And for that, I have to search all the segments that hold the same instrument. Then what worries me is how to keep it up to date if a previous controller event is changed. I can't rely on `refresh' being called, because the responsible event might live in another segment. I could make CompositionMapper::segmentModified refresh every later segment that has the same instrument. It'd work but it'd mostly waste time refreshing segments that don't need it. I'll probably do that and then figure out a way to save most of the work. Maybe I'll cache each instrument's controller values at a few times and let those caches control need-to-update. > I don't have any big objection to the spirit of making these things behave > relative to the assumed "current value," but I'm also inclined to think > that > the behavior of stripping controllers out of ornaments is probably > fundamentally reasonable due to all of these complications. I see what you mean. I wasn't going to change "Make ornament". But if all goes well, maybe a related command that captures controller events. > Try to aim at preserving everything of the status quo while enabling the > possibility of having new and separate opportunities for those who > specifically want them, and actively seek them out. That's what I > recommend. > -- > D. Michael McIntyre Tom Breton (Tehom) |
From: D. M. M. <mic...@ro...> - 2011-11-29 06:12:21
|
On Tuesday, November 29, 2011, D. Michael McIntyre wrote: > I guess you could search back in time for the last thing Rosegarden actively > set it to, and assume that's the current value... Don't forget that the last thing Rosegarden set that controller to could absolutely be outside the current segment you're looking at, and even outside the current track. You're going to have to pretty much iterate backwards through the entire composition looking for everything that plays through the instrument in question. If you encounter conflicting values due to someone making some kind of mistake (eg. they moved a part to play via a different instrument, not realizing it conflicted with controllers in some other part) then I guess you just have to pick something and make your best guess. It's pretty ugly, but if you want to wrestle with it, I certainly don't object to your having at it. I just expect what you'll wind up with will be something that works under certain conditions pretty well, but is very fragile, and easily broken. Really, it seems a lot more sensible for Rosegarden to do controllers on some "conductor track" at the global level, on a per instrument basis. Rosegarden definitely gives you the rope to hang yourself with in this respect, since you won't see controllers that are in some other segment, even though they definitely affect the MIDI channel you're using. I think some of the fundamental design decisions were really questionable in retrospect, but we've all inherited that legacy, myself included. -- D. Michael McIntyre |
From: Richard B. <bo...@gm...> - 2011-11-29 07:46:19
|
On 29 Nov 2011, at 07:12, "D. Michael McIntyre" <mic...@ro...> wrote: > I think some of the > fundamental design decisions were really questionable in retrospect, but we've > all inherited that legacy, myself included. Ok I'll bite. Rosegarden has always been a compromise between a notation editor and MIDI editor and latterly an audio workstation too. The whole design is therefore a compromise and we've done nothing more or less than any other piece of software that has to deal with. The tricky part has always been maintaining a balance while introducing new features. It's not one person's vision - it's several - therefore stuff gets funky. I was interested to see what was going to happen with OpenOctave when they were using RG. Since they changed to using Muse (?) I guess they came across similar challenges. I do agree that fundamentally it probably doesn't work as a design but by definition it was never going to. As long as you keep thinking like that it works. BTW has anyone considered splitting RG up? I'm playing around with the Windows port again and I might just end up throwing a lot of stuff away if I can't easily implement it. If that is the case then there might be an opportunity to reexamine the core to see what is really necessary/popular. R |
From: D. M. M. <mic...@ro...> - 2011-11-29 09:46:07
|
On Tuesday, November 29, 2011, Richard Bown wrote: > Rosegarden has always been a compromise between a notation editor and MIDI > editor and latterly an audio workstation too. The whole design is > therefore a compromise and we've done nothing more or less than any other > piece of software that has to deal with. Rosegarden is really unique in its abilities, and there's nothing in either the commercial or free software realms quite like it. I think on some level that's because the Rosegarden Experiment has proven how crazy it is to try to merge all of these features together under the same roof. The thing I was getting at with controllers is one good example. They're Events that belong to a Segment, which is a paradigm that works pretty well for MIDI events that double as music notation artifacts, but it just sucks for controllers when I think about it. I wish I'd thought of this 10 years ago, when it would have been easy to do something about it. Today, we have a long legacy of file compatibility behind us, and we're stuck supporting the original design for the rest of Rosegarden's life, even if we tack on some new design to support from here on. Rosegarden is just full of this kind of stuff, but there isn't much to do about it now. Obviously, the person who is still using Rosegarden today is the person who isn't limited too severely by all these weird quirks and oddities. > The tricky part has always been maintaining a balance while introducing new > features. It's not one person's vision - it's several - therefore stuff > gets funky. We never could keep a clear view of the forest for the trees, and this applies to all of us over the course of development. I certainly don't want to sound like I'm singling anyone out, because I'm due plenty of criticism for short- sightedness and bad decisions along the way, and I've done my share of things to add to the problem instead of solving it. > BTW has anyone considered splitting RG up? I've considered it many, many times. You reach a point where it seems like the only sane thing to do is turn Rosegarden into a notation editor and a sequencer that are divorced from each other, and dump the audio support entirely, because the world clearly voted for Audacity and Ardour on that front. The thing is, if you do that, you've really made Rosegarden a pretty pointless "me too" application in a full field. The ONE thing Rosegarden absolutely kicks ass at is being the one application that does a decent job with MIDI, notation, and audio. You can (and I have) prototype a composition with MIDI, make sheet music with it, record real people playing the sheet music, and mix it all down to a .wav file, all in the same application. Nothing else can do that. If you take that away, what's the point of Rosegarden even existing? But if you leave it, Rosegarden will always find some way to constrain your creativity, no matter which of the three directions your creativity is inclined towards. It's amazing the problems you can work around with this thing, and it's amazing the problems this thing forces you to work around. -- D. Michael McIntyre |
From: Richard B. <ric...@fe...> - 2011-11-29 18:15:50
|
On Tue, Nov 29, 2011 at 10:45 AM, D. Michael McIntyre < mic...@ro...> wrote: I wish I'd thought of this 10 years ago, when it would have been easy to do > something about it. > Not so sure. I seem to remember it getting pretty heated about _everything_ back then! R |
From: D. M. M. <mic...@ro...> - 2011-11-30 08:46:09
|
On Tuesday, November 29, 2011, Richard Bown wrote: > > I wish I'd thought of this 10 years ago, when it would have been easy to > > do something about it. > Not so sure. I seem to remember it getting pretty heated about > _everything_ back then! True that! -- D. Michael McIntyre |
From: Tom B. (Tehom) <te...@pa...> - 2011-11-29 20:23:05
|
> Really, it seems a lot more sensible for Rosegarden to do controllers on > some > "conductor track" at the global level, on a per instrument basis. > Rosegarden > definitely gives you the rope to hang yourself with in this respect, since > you > won't see controllers that are in some other segment, even though they > definitely affect the MIDI channel you're using. I think some of the > fundamental design decisions were really questionable in retrospect, but > we've > all inherited that legacy, myself included. Interesting that you should say that; I was thinking along similar lines recently. It can be confusing to edit controller events and find that unseen events in another segment are resetting or overruling what you're doing. It can be tedious to fix. The model doesn't match the MIDI that it's controlling. Controller events think that they are contained in one segment along with notes etc and that segment is contained in one track. But really they pertain to an instrument. That instrument might be playing multiple segments on multiple tracks. At first I also thought that it'd require radical changes. But then it occurred to me that there's a 90% solution that doesn't require radical changes. It just uses segments instead of creating new structures, commands, and functionality. I'll outline it: * Distinguish three types of MIDI segments, otherwise unchanged. * Mixed :: Just like MIDI segments are now. * InstrumentWide :: Contains only controller events and other things that apply across segments and tracks to an instrument. * Isolated :: Contains only relatively isolated events (notes etc) It isn't philosophically perfect. For instance, notes apply note-offs across segments and tracks, yet putting notes into InstrumentWide segments would defeat the purpose. But note-offs are less confusing than hidden controllers and are a less serious issue. * Give the user a means to make non-mixed segments. Probably just a command to split a mixed segment into InstrumentWide and Isolated. * Make the various functionality respect the type logic. There's a lot but I suspect it's mostly shallow. Like, "Join Segments" would just set the new segment's type correctly. Notation and Widget editors would silently ignore InstrumentWide segments. At this point, event inserters and rulers would just refuse to operate on the wrong kind of segment. * Finally, make controller event inserters use InstrumentWide segments * Rulers other than velocity wouldn't visit Isolated segments. Instead they'd find, lengthen, or create an InstrumentWide segment for the same instrument at the same time. * Similarly, insert pitch bend won't insert into an Isolated segment, it would find or make a suitable InstrumentWide segment. That's about as easy a path as I can think of. I had actually intended to propose and work on that, but making triggered controllers took precedence. Tom Breton (Tehom) |
From: D. M. M. <mic...@ro...> - 2011-11-30 10:01:29
|
On Tuesday, November 29, 2011, Tom Breton (Tehom) wrote: > It just uses segments instead of creating new structures, > commands, and functionality. I'll outline it: I've read your proposal, and I've had a very mixed reaction. I need to take some time to mull all of this over and really think about it before I'm ready to publish an opinion. If nothing else, it's definitely food for thought. I look forward to chewing on this, and it's kind of nice having some spirit of adventure around here again. -- D. Michael McIntyre |
From: Yves G. <yc....@wa...> - 2011-11-30 22:50:04
|
Le mardi 29 novembre 2011 à 21:23:00, Tom Breton (Tehom) a écrit : > >At first I also thought that it'd require radical changes. But then it >occurred to me that there's a 90% solution that doesn't require radical >changes. It just uses segments instead of creating new structures, >commands, and functionality. I'll outline it: I don't exactly know when a change become a radical one so maybe I'm totally wrong, but here is an other way which could solve the problem and is, I think, more user friendly. What we need is a way to multiplex the controllers over the midi channel. Each time the sequencer reads an event, it should be able to read the Id of the related segment. Then the sequencer may maintain a table of the current controllers for each segment, a table of last controllers on each midi channel and memorize the segment of the last event written on each midi channel. Each time the sequencer gets a new event it compares its segment to the segment of the last controller sent of the midi channel and, if necessary, sends again a controller from the table related to the segment just before the event. The advantage of this method is to authorize an easy use of controllers on a segment even if the same controllers are used on other segments connected to the same instrument. The drawback is the need to do most of the work, if not all the work, in real time inside the sequencer. Nevertheless a midi sequencer is slow compared to an audio processor. So maybe this is not totally unworkable. That's just a thought I had while reading your mail and I don't take the time to study it extensively. Yves |
From: Tom B. (Tehom) <te...@pa...> - 2011-12-01 01:55:34
|
> I don't exactly know when a change become a radical one so maybe I'm > totally > wrong, but here is an other way which could solve the problem and is, I > think, > more user friendly. OK, I'm glad to hear other possible approaches. > What we need is a way to multiplex the controllers over the midi channel. > Each time the sequencer reads an event, it should be able to read the Id > of > the related segment. > Then the sequencer may maintain a table of the current controllers for > each > segment, a table of last controllers on each midi channel and memorize the > segment of the last event written on each midi channel. > Each time the sequencer gets a new event it compares its segment to the > segment of the last controller sent of the midi channel and, if necessary, > sends again a controller from the table related to the segment just before > the > event. So if I understand it, this is creating a virtual channel for each segment. So the user can pretend each segment has its own dedicated channel. Right? But does that work? If (say) two notes are playing on the same MIDI channel and we send a pitch bend that's meant to apply to just one of the two, won't they both pitch bend? Tom Breton (Tehom) |
From: D. M. M. <mic...@ro...> - 2011-12-01 10:04:41
|
On Wednesday, November 30, 2011, Tom Breton (Tehom) wrote: > But does that work? If (say) two notes are playing on the same MIDI > channel and we send a pitch bend that's meant to apply to just one of the > two, won't they both pitch bend? I only skimmed the suggestion, but I'm reading it as a way to help keep track of what the "current" value for some controller is, rather than a proposal for how to deal with controller events over there having an unintended effect on something over here. For that, we need... Well, something. I'm still chewing on all of this. I feel like I have a counterproposal to make that would solve these problems in a cheap and elegant way, but I can't get the foggy idea in my head to coalesce into something clear and tangible. I'm just chasing my tail around in circles so far. -- D. Michael McIntyre |
From: Tom B. (Tehom) <te...@pa...> - 2011-12-01 21:22:35
|
> I'm still chewing on all of this. I feel like I have a counterproposal to > make that would solve these problems in a cheap and elegant way, but I > can't > get the foggy idea in my head to coalesce into something clear and > tangible. > I'm just chasing my tail around in circles so far. I'd like to hear it. I'm certainly not wedded to doing what I proposed. If there's a better way I'm all ears. Tom Breton (Tehom) |
From: Yves G. <yc....@wa...> - 2011-12-01 21:37:05
|
Le jeudi 1 décembre 2011 à 02:55:28, Tom Breton (Tehom) a écrit : > >But does that work? If (say) two notes are playing on the same MIDI >channel and we send a pitch bend that's meant to apply to just one of the >two, won't they both pitch bend? > Probably not (I mean it probably would not work). But that will always be the case if two unrelated sources are sending controllers on the same midi channel. The trivial solution being to use different midi channels. I'm afraid I didn't understand what your problem exactly is. You were talking of controllers in triggered segments and of the difficulty to know the current value of controllers in a segment.That doesn't seem really related to several segments sending controllers in the same midi channel. Is your idea to gather all the controllers in an unique segment to get the possibility to precompute their relative values ? Yves |
From: Tom B. (Tehom) <te...@pa...> - 2011-12-01 23:23:54
|
> Le jeudi 1 d cembre 2011 02:55:28, Tom Breton (Tehom) a crit : >> >>But does that work? If (say) two notes are playing on the same MIDI >>channel and we send a pitch bend that's meant to apply to just one of the >>two, won't they both pitch bend? >> > > Probably not (I mean it probably would not work). > But that will always be the case if two unrelated sources are sending > controllers on the same midi channel. > The trivial solution being to use different midi channels. Yes. > I'm afraid I didn't understand what your problem exactly is. > You were talking of controllers in triggered segments and of the > difficulty to > know the current value of controllers in a segment.That doesn't seem > really > related to several segments sending controllers in the same midi channel. Right, that's unrelated. That's from a different proposal, earlier when I was talking about trigger segments. For that, for finding the current value of controllers, I already have written proof-of-concept code. It works for volume right now, just it's not general yet and not optimized at all. Then Michael mentioned that it's a messy situation with controllers applying across segments etc; I agreed strongly and proposed distinguishing {mixed,instrumentwide,isolated} segments. > Is your idea to gather all the controllers in an unique segment to get the > possibility to precompute their relative values ? To gather them, yes, but the reason is primarily a usability issue, not a functionality issue. The biggest specific reason IMO is to avoid the situation where the user thinks the controllers are one way, because that's what the rulers are showing him, but it's misleading because he doesn't see controllers in another segment that also apply. There's also a design elegance rationale but that's less important IMO. Tom Breton (Tehom) |
From: D. M. M. <mic...@ro...> - 2011-12-02 13:23:13
|
On Thursday, December 01, 2011, Tom Breton (Tehom) wrote: > I'd like to hear it. I'm certainly not wedded to doing what I proposed. > If there's a better way I'm all ears. I'm just starting to see the edges of this idea, but what if segments, rather than tracks, owned the instrument? A segment would take a default instrument from the track in the same way it takes a default "create segments with" color, highest and lowest playable notes, transposition, clef, etc., but once it existed, it would maintain its instrument independently of whatever track it landed on, in the same way it owns its other properties. We talked about doing this once before, for an entirely different reason that I'll skip discussing for the sake of focus. We never felt it was worth the pain to implement, but the concept is basically plausible. In that kind of world, how does this controller problem look different? Could moving the instrument to the segment allow us to deal with the controller issue in a more elegant manner than your proposal, which you admitted was "philosophically" awkward? I'm not sure, and I'm ridiculously ready for bed just now, but I'd like to mull this over with you and see if it leads anywhere interesting. -- D. Michael McIntyre |
From: Tom B. (Tehom) <te...@pa...> - 2011-12-02 21:53:36
|
[I'll answer this part out of order; the thread seems clearer this way] > In that kind of world, how does this controller problem look different? Could > moving the instrument to the segment allow us to deal with the controller > issue in a more elegant manner than your proposal, which you admitted was > "philosophically" awkward? It deals with the controller problem perfectly, assuming that it would "clone" instruments as needed. Like, if two segments have the same MIDI instrument at the same time, they each get one playing on its own MIDI channel. You didn't say, but I think that's what you meant. As you say, it seems painful to implement. Your proposal seems to be a 100% but radical solution to which I was proposing a 90% but non-radical alternative. * Pro: It's purer; it doesn't leave any nagging little inconsistencies * Pro: It's easier on the user * Con: It'd be much more work. * Con: Its intermediate stages seem more difficult. Maybe there is a less radical path from here to the 100% solution. I can't think of it right now. > I'm just starting to see the edges of this idea, but what if segments, rather > than tracks, owned the instrument? A segment would take a default instrument > from the track in the same way it takes a default "create segments with" > color, highest and lowest playable notes, transposition, clef, etc., but once > it existed, it would maintain its instrument independently of whatever track > it landed on, in the same way it owns its other properties. If I may add on some ramifications: Seems like we'd need a user command to re-assign an instrument to selected segments. That implies a new widget to select an instrument, and a set of instruments to select from. What is the set of instruments? Right now, exactly the instruments that are visited by some track. But any instruments that any segment is using needs to be kept around, and it'd probably make sense to jump right to keeping a set of instruments. Pretty soon we'd want an interface to manage them. How to edit an instrument? Maybe at first, only via a track visiting that instrument, like now. Eventually we'd want something better. That would require support in our save format. Backward compatibility becomes an issue. Cloning instruments as needed creates some scarcity of MIDI channels. So then we might want to reassign instruments to any channel that's free. Doing that allocation is itself easy: keep a free-list. ISTM the problem is that the way we do MIDI playing now doesn't support "late" logic about instrument channels. IIUC, we dump linearized segments that already know everything they're going to do and we basically stop and start them. But I've only seen that code a little bit, so please correct me if my knowledge here is wrong. Are there any user setups that require a particular mapping of instrument to channel? I don't know of any. If so, either we can't freely assign instruments to channels or doing so becomes more complex. There are surely many places where the code "knows" obsolete assumptions about instruments, tracks, and channels. I've seen a few and I'm sure there are many more. Like, everything using Track::getInstrument(). MIDI and softsynth tracks become little more than default settings for segments and means to select multiple segments. There seems little reason for a Segment to remember its track id. Linked segments presumably have non-shared instruments that default to the original instrument. Presumably every segment would initialize play with its instrument's default settings. No more concern about how a previous segment left the controllers. That's another nice thing that comes from a 100% solution. It disables some "Stupid Segment Tricks" that make controllers a little easier to manage, such as putting the volume controllers for a tutti crescendo into their own dedicated segment and linking or copying that segment everywhere it needs to go. But that might be provided by triggered segments that hold controllers (which I should be working on instead of writing email). How do triggered segments fit in? I assume they don't hold an instrument, so they inherit it from a parent? Its purity probably makes further extension easier. Tom Breton (Tehom) |
From: D. M. M. <mic...@ro...> - 2011-12-03 13:17:35
|
On Friday, December 02, 2011, Tom Breton (Tehom) wrote: > Like, if two segments have the same MIDI > instrument at the same time, they each get one playing on its own MIDI > channel. You didn't say, but I think that's what you meant. No, it isn't quite what I meant. Putting it that way, and all the discussion that ensued finally helped me get a few things to click in my head though. I've been writing and deleting text for a couple of hours now. I kind of hate to give my answer without showing my work, but I just don't have time to continue this. What I concluded is that when you have controllers in little portable boxes that can move anywhere fluidly, you have decided to create the problem of being able to create situations where unintended conflicts exist. You can take steps to make everything within a sphere of influence aware of everything else within that sphere (tons and tons of deleted thinking out loud here), but since the boundaries of said sphere are extremely fluid and malleable (move a segment to a new track, change the instrument on an existing track, move a segment in time) and the interconnections between all the elements are complex, it is virtually impossible for software to resolve anywhere close to 90% of the potential conflicts automatically. The only real solution to this whole problem, as I see it, is to dump the segment model. Since we're not remotely going to consider that, I just don't see anything but to live with this side effect, and deal with it. It can be confusing, without a doubt, but it also works in its own way. It is what it is, and it's not wrong, it's just different from the approach most MIDI sequencers take. I have to go all the way back to saying that I don't think there is any fundamental architectural change our founders could have made 10 years ago that would have resolved any of this. It's just how the segment model has to work. Even with the mythical "extra-segmental" context I've been lamenting the lack of for years, you've still got gobs of problems resolving who owns what, and what goes where when what moves. Having said all that, feel free to start hacking on your 90% idea in a branch, and see if you can make it work. I'm convinced you can't, but I'll be first in line to extol your brilliance if you prove me wrong. For my part, I'm going to stop thinking about how to solve this problem henceforth. I've contributed what I could, and I'm spent. I'll be happy to support you in any way I can if you want to pursue this, but I'm done having any hand in where it goes from here. I'll be happy to test your work and try to pick holes in it though, once I get my grubby hands on it. There's even a remote possibility we might work through all the problems together, and make the damned crazy thing work. Good luck! -- D. Michael McIntyre |
From: Tom B. (Tehom) <te...@pa...> - 2011-12-03 19:08:04
|
> On Friday, December 02, 2011, Tom Breton (Tehom) wrote: > >> Like, if two segments have the same MIDI >> instrument at the same time, they each get one playing on its own MIDI >> channel. You didn't say, but I think that's what you meant. > > No, it isn't quite what I meant. Putting it that way, and all the > discussion > that ensued finally helped me get a few things to click in my head though. > > I've been writing and deleting text for a couple of hours now. I kind of > hate > to give my answer without showing my work, but I just don't have time to > continue this. Yes, it's taking a fair bit of time for me too. I like to hash designs out beforehand while it's still cheap to do so, and I'm glad we talked this over. > Having said all that, feel free to start hacking on your 90% idea in a > branch, > and see if you can make it work. I'm convinced you can't, but I'll be > first > in line to extol your brilliance if you prove me wrong. After I finish making triggered segments' controllers relative, I will probably do that. Just so I don't raise expectations about resolving conflicting controllers, the object of my 90% design is to present an instrument's controllers more obviously to the user, not to automatically fix conflicts. > For my part, I'm going to stop thinking about how to solve this problem > henceforth. I've contributed what I could, and I'm spent. I'll be happy > to > support you in any way I can if you want to pursue this, but I'm done > having > any hand in where it goes from here. I'll be happy to test your work and > try > to pick holes in it though, once I get my grubby hands on it. There's > even a > remote possibility we might work through all the problems together, and > make > the damned crazy thing work. Thank you. Tom Breton (Tehom) |
From: D. M. M. <mic...@ro...> - 2011-12-04 13:42:05
|
On Saturday, December 03, 2011, Tom Breton (Tehom) wrote: > Yes, it's taking a fair bit of time for me too. I like to hash designs > out beforehand while it's still cheap to do so, and I'm glad we talked > this over. Me too. It was fun kicking the ball around. -- D. Michael McIntyre |