Creating a fork on github sounds like a good idea. I'll do that. Having notes be active while moving seems like a nice feature. It would be great to be able to position notes and listen to the changes in realtime, when adjusting timing and what not. Its probably my lack of understanding at this point, however, how would having this feature affect the drawing of notes while they are being moved? Even if the notes were active while being shifted, couldn't they be drawn as a rectangular overlay (possibly with transparency or something)? I'm not sure what sort of real world performance issues would crop up with that method though (having the drawn rectangle snap to beats would improve things). Above and beyond the issues of drawing, I can see other potential issues with stuck notes, if for example a note gets triggered and then the note-off is moved away from the playhead. Might need some smart logic to deal with that sort of case.
For that matter, do you have any thoughts on how to handle overlapping notes? When I was first playing around with non-sequencer I had it in merge mode, which quickly got very messy as notes overwrote other notes. Seems to me like notes should never overlap (multiple note-ons without a corresponding note-off in MIDI doesn't really make sense). If the user were to drag and drop multiple notes, I would think it would overwrite any notes it happens to fall on. In regards to the optimizations I made. They are for the case of dragging a single note, which is the duration or velocity color. This seems like a separate operation from moving multiple notes. Optimizing the various widgets for damage areas seems independent of the decision you mentioned at any rate, since just about any method of redrawing which doesn't require the entire screen redraw, could benefit, provided there really is an issue with this. Could you provide any insight as to the completeness of NTK and Non Sequencer in regards to partial redraw optimization? Cheers. Element On Sun, Dec 1, 2013 at 2:25 PM, J. Liles <[email protected]> wrote: > Forking on github and submitting pull requests is probably the easiest > method. > > Ok, on to the issue: so an important question here and one that I have not > answered myself is this: > > Should notes in the process of being moved/dragged affect the playback? > That is, should the current position of the notes be 'visible' to the > playhead? Currently, they are. Whether that's good or bad is up for debate. > However, if the notes *weren't* active when being moved, then that opens up > lots of opportunities for optimization. For one thing, the notes could be > drawn into an image surface which is then overlaid onto the canvas, making > drawing very fast (but perhaps being a bit confusing depending on the > pattern's compaction mode, key, etc.) > > There's not much point in optimizing the particulars until decisions like > this have been made. > >
