View Single Post
Old 09-04-2019, 12:16 PM   #15
mccrabney
Human being with feelings
 
mccrabney's Avatar
 
Join Date: Aug 2015
Posts: 3,668
Default

the issue in this post uses as illustration a common use case for, say, a bassline: an item ends with a pitchbend slide down, and returns to 0 for the next note.

as often is the case in pattern based music, this occurs over the span of 2 items for ease of duplication.



if a user drags the note/associated pitchbend curve at the end of item 1 "into" * item 2, it extends item 1 and drops a pitchbend point. this is merely visual - it doesn't actually override the pitchbend return event that occurs in item 2 (and you can test this by gluing the items together).

however, it's highly misleading, and indicative of a problem with overlapping midi items in the context of what is an essentially monophonic parameter -- it'll only ever respond to the last pitchbend message received, so why bother drawing it?

but digging deeper past the graphics of it, it seems backwards to accommodate playing back multiple, overlapping cc curves in this fashion, especially when it gets in the way of more primary application - dragging a cc from time A to time B irrespective of item.

which brings me to my *: i would expect that clicking/dragging a midi note/associated data from item 1 "into" item 2 would actually move the data into item 2, rather than simply extending the bounds of item 1.
__________________
mccrabney scripts: MIDI edits from the Arrange screen ala jjos/MPC sequencer
|sis - - - anacru| isn't what we performed: pls no extra noteons in loop recording
| - - - - - anacru|sis <==this is what we actually performed.
mccrabney is offline   Reply With Quote