Menu
▾
▴
Re: [Lmuse-developer] what are you doing in your branch?
|
From: Florian J. <flo...@we...> - 2011-10-25 23:15:33
|
Am 25.10.2011 20:38, schrieb Tim E. Real: > Was late, no time to write up on it last night. > > Bear with me here, it is far from perfect and there are > conflicting conceptual ideas here which I outline below... > It may not even be the right direction although some of the > stuff may actually be useful for trunk. > > This branch attempts to start to unify some things in the > infrastructure to prepare for the future. > > I started with this credo: > Everything that can be drawn on a canvas should be a CItem > or derivative of CItem. > Currently in trunk the audio automation graphs and piano roll midi controller > graphs do not use CItem. My immediate aim is to make them use CItem. > > So I reworked CItem, and made specific subclasses of them for each > type of item needed. > CItem itself no longer contains 'part' and 'event', these are included > in the subclasses which need them, and it is now entirely up to the > subclasses what members are needed and included. > (The idea there was that not all CItem types may need a part or event.) > > This opens the possibility of mixed item types on canvasses. Such as > notes, controller points, and movable text items, even pictures, > all at the same time. > > Next, I needed a way to generally provide better support for drawing layers - > that is item list layers which are drawn in order. > This is important to get the order of drawing correct so some items > appear on top of others. The drawing sequence is crucial here. > (Currently in trunk drawing order is kind of hard-wired into Canvas::draw.) > > So I created a new class 'ItemListLayers' which is just a vector of > CItemList instances. > Next, I replaced class Canvas's single 'CItemList items' member > with 'ItemListLayers items'. > (I carefully considered dumping ALL the items into the existing single > 'items' list. There are advantages having them all in one list. > But in the end I went with these separate lists instead.) > > It is up to the specific Canvas subclasses how many layers are > used and for what purpose. In their constructors, they > specifically add the required number of CItemList instances > to the ItemListLayers 'items' vector. > Then throughout their code, they manipulate and draw the various layers. > > For example in the PartCanvas I currently have two layers: > part items and automation items. > The EventCanvas (base for PianorollCanvas and DrumCanvas), > I currently have just one layer - note items. > But later we can add automation items, text items etc. all drawn > right on the canvas itself. > > Well, that's all I've got so far. > Run it, and you will not notice any differences at all, ATM. > > --- > The aim was to try to show that automation could be displayed > in the arranger without requiring parts. > As we discussed before, this would mean for example midi parts > would no longer own the automation data, this data would now be > part of the track itself, the way audio automation is currently done - > it is part of the audio track. > > However, as of yesterday I was ready to announce that I am abandoning > that concept. Yet as of today I'm not so sure, leaning back the > other way again. It's tough, there are very valid points to each method. > You see, I now believe it is best that all these items require a part to > contain them. > Drawing automation directly on the arranger without parts looks neat, > and is a cool thing, but unfortunately defeats the purpose of parts. > true. i think there should be definitely be a way to put automation into parts. (but maybe also a way to NOT put them into parts ;) ) with MIDI tracks, i'd propose the following simple solution: no changes (that is, automation, controller changes are kept in parts), just that there are "note-parts" and "automation-parts", which can be dealt with independently. > By containing them within parts, it allows them to be easily copied, > moved, and most importantly - cloned! > Anyone attempting some heavy automation editing on the arranger > would quickly realize that being able to 'part-ize' and clone the data > would help. > cloning is important, yeah. > And yet, having parts is fraught with difficulties as well. > It means - guess what - that ALL track types would allow parts, even > Audio input, Groups etc. No more empty 'dark' filled track for them. > So here, moving audio automation from track ownership to part > ownership would be major work. > > And with parts, the issue of arbitration of overlapping data from > overlapping parts would be a concern, as it is now with midi > automation and that ugly hack of those 'do clones' + > 'do part controllers' flags business. > Right now I am trying very hard to see if I can eliminate that in trunk. > As I mentioned, this must happen before unification of audio and midi > controllers can happen. > (Making tracks own the automation data would solve all of this right away, > ie there is only ONE automation stream, not several from overlapping parts.) > overlapping is indeed a problem :/ when we use "automation parts" and "event parts", we could simply make muse not let you overlap "automation parts". problem solved. > And yet on the other hand, that kind of hack may just be required > even for audio parts, if we go with the 'all parts' concept. > > There is another possibility of using both techniques at once. > That is, draw automation without parts, then later user draws parts /around/ > the data, then moves, copies, clones etc. > I mentioned this possibility before - parts would be sort of just > permanent selection rectangles that can be draw /around/ existing > data to provide a 'container' for them for easy manipulation later. > > You see, MusE is an enigma wrapped in a riddle wrapped in a question. > It somehow manages to use both conflicting techniques at once. > Like wave-particle duality. Audio and midi. Yin and Yang. > > I wish you could see all the conflicting concepts all clamoring > for peace in my head. It's very intense. Hard to explain all the angles. > I we could speak together, I would be yapping 1000 words per minute > outlining why 'this is possible but conflicts with this' kind of thing... > Hopefully out of all this some kind of coherent mash will arise. > > To summarize: > The overriding salient issue seems to be whether we want to allow > drawing and editing of items in the arranger without requiring parts. > Do we 'move to the left' or 'move to the right' or 'try to come down > in the middle with a compromise'... > Trying to work it all out... > > Comments, ideas welcome. I bet I can probably say > "yep I thought of that, it's doable but requires this and > conflicts with that..." He he. > maybe we should go away from muse's current concept, and "reinvent the wheel"? that is, try to create a new concept, fully un-biased, not trying to orient ourselves on current muse? i know that this may cause major incompatibilities. but sometimes you cannot keep a clean design compatible with a dirty design. hrm, difficult questions... i definitely think such changes (plus other changes) would rectify muse 3.0 ;) then we could break with backwards-compatibilty (or at least, offer a "import feature", which really imports (that is, changes) files). greetings flo > Onwards and upwards... > Tim. > > >> Hi Tim >> >> great you are branching as well now :) >> >> it'd like to know what you'll do in your branch. >> >> are you moving code around? or doing deep changes like orcans namespace >> changes? >> >> in this case, we'll likely run into problems, though there is no way >> (except git xD) to avoid them (and even git can avoid them all). >> >> when moving code around (that is, renaming files or moving code from one >> file to another), this will likely cause merge conflicts. there's >> hand-work neccessary. as svn (and even git) are not almighty, they >> cannot resolve them on their own. it's unavoidable (except we all except >> you stop coding), but i'd like you to know that such changes require >> hand-work. >> >> don't understand me wrong, i neither want you to NOT work on your >> branch, nor do i want all the others to stop working while you are >> coding. i just want to make you all aware that svn isn't almighty ;) >> >> greetings >> flo >> >> >>> > ------------------------------------------------------------------------------ > The demand for IT networking professionals continues to grow, and the > demand for specialized networking skills is growing even more rapidly. > Take a complimentary Learning@Cisco Self-Assessment and learn > about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/cisco-dev2dev > _______________________________________________ > Lmuse-developer mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-developer > > |