View Single Post
Old 09-04-2019, 11:04 PM   #17
ivansc
Human being with feelings
 
Join Date: Aug 2007
Location: Near Cambridge UK and Near Questembert, France
Posts: 19,151
Default

Quote:
Originally Posted by mccrabney View Post
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.
Well spotted! I recall this b3ing a perennial issue on several of the old sequencers I used back at the dawn of MIDI history.
__________________
"What a dick comment. I'm gonna make sure to avoid your name." Dicks other than Trump can speak????
ivansc is offline   Reply With Quote