Old 11-19-2012, 04:38 AM   #41
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

Some more bugs re. MIDI:

http://forum.cockos.com/project.php?issueid=4473
http://forum.cockos.com/showthread.php?t=113533
http://forum.cockos.com/showthread.php?t=113442
http://forum.cockos.com/showthread.php?t=112761
http://forum.cockos.com/showthread.php?t=108247


This last one actually has two bugs reported in. The second one is more annoying - right-clicking on a CC deletes the CC, when it shouldn't!!! We don't even have a mouse modifier context to deal with this. Please fix.
EvilDragon is offline   Reply With Quote
Old 11-19-2012, 07:58 AM   #42
semiquaver
Human being with feelings
 
Join Date: Jun 2008
Posts: 4,923
Default

Quote:
Originally Posted by Banned View Post
I think not, because that would defeat the function of pausing recording. For WYSIWYG, the mod wheel should rather move back down when you start recording again, .
That would work too. So long as you don't have the experience of playback sounding different than when recording. A preference is probably in order.
semiquaver is offline   Reply With Quote
Old 11-19-2012, 08:47 AM   #43
drew
Mobile
 
drew's Avatar
 
Join Date: Jan 2006
Location: London & São Paulo. Hardcore commercial REAPERite
Posts: 1,669
Default

Wonderful to have that rounding bug fixed, Cockos - thank you so much for preserving my sanity while I paste preserving measures!
__________________
Proudly using REAPER exclusively for...
* Media and event music composition & production, sound design + auto-processing at Qsonics.com
* Broadcast branding, promos, education & training and narration voice-overs at DrewWhite.com

Last edited by drew; 11-19-2012 at 10:41 AM.
drew is offline   Reply With Quote
Old 11-19-2012, 08:49 AM   #44
bitrate
Human being with feelings
 
Join Date: Aug 2010
Posts: 477
Default

Quote:
Originally Posted by EvilDragon View Post
I know I often copy-drag things. I want this to extend the item if I wish so. No matter the timebase. Simple as that.
Another copy-dragger here. +1.
bitrate is offline   Reply With Quote
Old 11-19-2012, 08:56 AM   #45
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default


Testing the screenset fixes.

I get a very small variation here. I have a screenset that positions a toolbar and a mixer in the lower docker. The width of the toolbar will sometimes be a pixel or two too wide, and a reload of the screenset will correct that.


My screensets: https://stash.reaper.fm/14585/R431pre...screensets.zip
(two monitors, 1920x1200 and 1280x1024)

Sequence of events is:
  • call up screenset
  • change width manually
  • call up other screensets
  • then recall the original screenset -> width of toolbar a little too wide
  • call again -> correct width

Width is referring to the width of the toolbar placed on the left in the lower docker next to the mixer.

Recalled once, then a second time

__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom

Last edited by airon; 11-19-2012 at 11:53 AM.
airon is offline   Reply With Quote
Old 11-19-2012, 11:34 AM   #46
Evan
Human being with feelings
 
Join Date: Oct 2006
Location: Greece
Posts: 3,553
Default

Quote:
Originally Posted by EvilDragon View Post
Small FR - we should be able to do this:

...

To make it clearer - drawing a new note WILL extend the item boundaries. But copying a note then moving it to extend the item will not do so. It is highly annoying.
Optional please! With lock/unlock item size. (otherwise you may change the item size by accident when moving events around).
Evan is offline   Reply With Quote
Old 11-19-2012, 11:55 AM   #47
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

I don't think it really needs an option... The only instance where drag-copy should NOT extend the item boundaries is when using loop source. That's about it. It should NOT depend on timebases! For any other situation, you can afford to extend the item even accidentally (and then you have undo if you really screwed it up). No need to optionalize when the fix for any accidents is one Ctrl+Z away.
EvilDragon is offline   Reply With Quote
Old 11-19-2012, 12:04 PM   #48
j79
Human being with feelings
 
j79's Avatar
 
Join Date: Mar 2009
Location: Göteborg
Posts: 1,322
Default

I am kind of in the middle...this is somewhat like how dragging an item below existing tracks would create multiple unneeded new tracks back in the day. Not really a problem, but still kind of really annoying...

Wouldnt it solve the problem if the item only extended if needed when the mouse-button is released?
j79 is offline   Reply With Quote
Old 11-19-2012, 12:08 PM   #49
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

Quote:
Originally Posted by j79 View Post
Wouldnt it solve the problem if the item only extended if needed when the mouse-button is released?
Yes, it would. In fact that is the same behavior for the auto-track creation when you drag-copy an item to an empty arrange area. There we have our ultimate solution. Without additional options.
EvilDragon is offline   Reply With Quote
Old 11-19-2012, 01:44 PM   #50
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

Quote:
Originally Posted by EvilDragon View Post
Yes, it would. In fact that is the same behavior for the auto-track creation when you drag-copy an item to an empty arrange area. There we have our ultimate solution. Without additional options.
But how do you distinguish between dragging events to extend item boundaries,
and dragging events to other items? Do we just preempt the future possibility
of dragging events to other items?

The toggle/modifier suggestion trades one tedious but simple operation (manually
extending the item before [copy-]dragging), for another tedious but simple
operation (switching the proposed drag-mode), and adds a layer of complexity in
the process. Hardly an improvement.

Or do we add a complicated heuristic where the software tries to determine our
intentions based on item overlaps, or where we intend to drop the events, or how
long we hover over an area or somesuch? In my experience, these heuristics are
a pain in the ass. I'd rather my editor do what I tell it, and not try to think
for me.

The glib "Just add it, duh!" doesn't cut it.
medicine tactic is offline   Reply With Quote
Old 11-19-2012, 01:48 PM   #51
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

I'll just say go see Sonar, it seems to be working without a hitch there.
EvilDragon is offline   Reply With Quote
Old 11-19-2012, 01:54 PM   #52
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

Quote:
Originally Posted by EvilDragon View Post
I'll just say go see Sonar, it seems to be working without a hitch there.
I actually installed the trial on a virtual machine last night to see what all the fuss was about.

Ye gods...

I've never been happier to be a REAPER-ite. AFAICT it basically takes over the entire decision process for how items are created, and how events are added to them. Totally not in keeping with REAPER's philosophy.

Edit: Have you ever used it?

Last edited by medicine tactic; 11-19-2012 at 02:01 PM.
medicine tactic is offline   Reply With Quote
Old 11-19-2012, 02:11 PM   #53
ivansc
Human being with feelings
 
Join Date: Aug 2007
Location: Near Cambridge UK and Near Questembert, France
Posts: 22,754
Default

Quote:
Originally Posted by medicine tactic View Post
I actually installed the trial on a virtual machine last night to see what all the fuss was about.

Ye gods...

I've never been happier to be a REAPER-ite. AFAICT it basically takes over the entire decision process for how items are created, and how events are added to them. Totally not in keeping with REAPER's philosophy.

Edit: Have you ever used it?
I am a Sonar escapee from V3 to V8.5.3 and whilst there are a TON of thin
gs I had / have issues with in Sonar, the MIDI implementation, especially how it deals with timeline and items, works.


P.S. Very very happy indeed to see some MIDI bug fixes. Thanks, Devs.

And now the Oliver Twist moment "Can I have some more please, sir?"
ivansc is offline   Reply With Quote
Old 11-19-2012, 02:13 PM   #54
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,551
Default

Quote:
Originally Posted by EvilDragon View Post
I'll just say go see Sonar, it seems to be working without a hitch there.
Good luck keeping that comment in it's proper limited context.

At any rate, you may have to change your nick to "Happy Dragon" pretty soon huh?
Lawrence is offline   Reply With Quote
Old 11-19-2012, 02:24 PM   #55
gofer
-blänk-
 
gofer's Avatar
 
Join Date: Jun 2008
Posts: 11,359
Default

Just by looking at Sonar we won't gain much, if it works without a hitch we'd still need to find out what it is that it does.

I can only talk about Sonar7. At least for the uninitiated user that version decided for you, and often enough was wrong with it's guess to be annoying.
As long as I worked forward and no following clip existed yet it hadn't much choice to not do what I expected (that's the situation you see in Theodor Krugers vids - it works superb for that). But I lost a good deal of hair with notes being created in clips I didn't want them in, or even clips created which I didn't want. The situation just wasn't always that unambiguous.

Then again, I didn't really give it much of a chance. After half a year I gave up on it, but because of other stuff. Maybe there are options to tweak this behavior.




Quote:
Originally Posted by medicine tactic View Post

The toggle/modifier suggestion trades one tedious but simple operation (manually
extending the item before [copy-]dragging), for another tedious but simple
operation (switching the proposed drag-mode), and adds a layer of complexity in
the process. Hardly an improvement.
You don't take into account that it's not something you'd switch back and forth all the time. Also I'd consider hitting a key command or toolbar button or holding a modifier during a drag less tedious than first dragging the item edge and then dragging the events. The trade is between doing something tedious but easy all the time and doing something less tedious but easy sometimes.
gofer is offline   Reply With Quote
Old 11-19-2012, 03:40 PM   #56
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

Quote:
Originally Posted by gofer View Post
You don't take into account that it's not something you'd switch back and forth all the time. Also I'd consider hitting a key command or toolbar button or holding a modifier during a drag less tedious than first dragging the item edge and then dragging the events. The trade is between doing something tedious but easy all the time and doing something less tedious but easy sometimes.
Fair enough. And I should be clear and say that, believe it or not, I *do* find
it annoying that item boundaries are straight up solid with respect to
[copy-]dragging. I just know that care needs to be taken with the solution,
because it will have, ahem, REAPERcussions (medicine tactic ducks) on what design
paths are available in the future.

And there are other ways. In Cubase, item "boundaries" aren't absolute --
they just define the portion of the item that's visible to the scheduler.
Events can exist outside of the scheduler-visible area, but still be members of
the item.

Last edited by medicine tactic; 11-19-2012 at 03:46 PM.
medicine tactic is offline   Reply With Quote
Old 11-19-2012, 04:25 PM   #57
gofer
-blänk-
 
gofer's Avatar
 
Join Date: Jun 2008
Posts: 11,359
Default

Of course. We're in complete agreement on that. All steps have to be taken with care and when someone sees a problem, it's good to think and talk about it. Sometimes it's very easy to forget about some consequence of what seems to be a simple idea at first. There has been a time where item edges couldn't be changed from within the MIDI editor at all and at the time this was tackled, it took quite a few iterations of pre-releases to get it right (or let's say, not entirely wrong) finally . (EDIT: Although, thinking about it, probably it was rather the item loop boundaries I have in mind here - I can't remember right now)

That being done, we aren't talking about something revolutionary new for Reaper here, item edges get extended all the time now, also automatically (eg when you drag a note end). All that we are talking about is an option to extend the edge also when events are dragged or copied. As long as the problem is "we'd have to click on a button to turn it on and off", we're still on pretty solid ground, I think. But if there is an idea how to avoid it (without laying our fate into a computed decision), then it would be very good to find it.

Btw, Reaper's items can contain data outside the item borders too. Extending the item edge might reveal existing data. But that doesn't seem to change much. Or are you onto some idea?

Ride on

Last edited by gofer; 11-19-2012 at 04:34 PM.
gofer is offline   Reply With Quote
Old 11-19-2012, 07:52 PM   #58
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

There's a subtle uniformity to the current stretching behavior. Dragging the
note-off event (stretching a note from the end) can extend item boundaries
because the note-off can not change what item the note lives in. That is, we
probably wouldn't want to change the note's home by dragging its note-off to
another item. Dragging the note-on (stretching a note from the beginning), or
dragging the whole note can't extend item boundaries because it has the future
potential of moving the note to a different item (or some other other behavior).

Quote:
Originally Posted by gofer
Btw, Reaper's items can contain data outside the item borders too. Extending the item edge might reveal existing data. But that doesn't seem to change much. Or are you onto some idea?
Oh yeah! I'd forgotten that because they become completely invisible. So
REAPER's MIDI editor design seems to me to be closest to Cubase right now, but
hasn't committed to a course. Honestly, I'm totally impressed with the devs'
forethought. REAPER's MIDI editor design is perched at a node, a number of possible
futures branching off, well-designed but uncommitted.

Edit: Actually probably most DAWs allow events outside item boundaries. Cubase is
somewhat unique in that it let's you edit those events just like normal.

Last edited by medicine tactic; 11-19-2012 at 11:33 PM.
medicine tactic is offline   Reply With Quote
Old 11-20-2012, 02:15 AM   #59
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

Quote:
Originally Posted by medicine tactic View Post
Dragging the note-on (stretching a note from the beginning), or dragging the whole note can't extend item boundaries because it has the future potential of moving the note to a different item (or some other other behavior).
It CAN extend item boundaries already! But only in Source beats timebase mode. What I'm asking is for this to be possible in all timebase modes.
EvilDragon is offline   Reply With Quote
Old 11-20-2012, 03:10 AM   #60
gofer
-blänk-
 
gofer's Avatar
 
Join Date: Jun 2008
Posts: 11,359
Default

The difference is, in source mode it's clear that you only want to deal with this one item source. There is no doubt that you want your moved/copied data in this one.

That doesn't mean I disagree. There should be a way to tell Reaper that you want to stay in the same source when you work in other timebases and shift events outside the current item boundaries. I totally want that and don't see a problem with it as an option.


What Medicine Tactics is thinking about here (probably prematurely, but of course a valid discussion) would be option c). "I don't want to extend this source, but still be able to shift events outside" -which we don't have yet. This is basically thinking about what people here like to call track based editing.
If there's no item existing at that position, easy enough - create one. But what if an item exists at the target position? What if you've got multiple items there, or items with multiple MIDI takes, or both? How to determine the target in a manageable way?


My position is:
This is no problem regarding your request. The option "stay in current source, extending it as needed" would need to exist anyway and it's unambiguous (if I don't miss something). But it in fact doesn't hurt start brainstorming about what is actually expected from "track based" and how it could be made workable, once option c) gets tackled.

This is very much the wrong place for it, though . I asked that question before in some of the "want time based MIDI" threads but no-one came up with a good idea about it yet.
gofer is offline   Reply With Quote
Old 11-20-2012, 03:11 AM   #61
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

That's because by definition you can only open one item at a time in source
beats mode, so the complications vanish.

Edit: Ahh, gofer beat me
medicine tactic is offline   Reply With Quote
Old 11-27-2012, 10:49 AM   #62
G-Sun
Human being with feelings
 
G-Sun's Avatar
 
Join Date: May 2010
Location: Norway
Posts: 7,318
Default

Quote:
+ Screensets: fixed loading of docker size/positioning states [t=113478]
Still buggy behavior here.
Reaper doesn't remember last screen-set.

Reaper 4.31 32bit win7 64bit
__________________
Reaper x64, win 11
Composer, text-writer, producer
Bandcamp
G-Sun is offline   Reply With Quote
Old 11-27-2012, 11:54 AM   #63
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

Quote:
Originally Posted by G-Sun View Post
Still buggy behavior here.
Reaper doesn't remember last screen-set.

Reaper 4.31 32bit win7 64bit
It is a bit weird, yes. Refer to [url=http://forum.cockos.com/showpost.php?p=1076148&postcount=2]this post.[/quote]
EvilDragon is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 07:15 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.