v4.32-dev-pre4 - November 27 2012

[musicbynumbers]

Lol, whoops! meant the midi filter view. Shouldn't have wrote that first thing when I woke up!

Originally Posted by Anton9

Not sure what you mean by buttons on the track manager, as the only buttons are(Project,List,Freeze,Options).

But if I understand you correctly.., you mean being able to drag in the columns and do things such as make tracks visible, mute, solo.., etc.?
If so this is already possible, just left-click-drag.., you can also lasso multiple items by left-click-dragging in the empty column all the way to the right, then just click on any one of the cells to toggle that option for all selected tracks.., for example clicking on a cell in the TCP column will toggle all selected tracks visibility.

[EvilDragon]

Originally Posted by Anton9

If you open them seperatly they retain their settings, however if you open Item-1 then Item-2 via the 'Contents' menu so that they're both in the same editor, Item-2 takes on the grid setting of Item-1 and it retains that setting even if opened by it's self later.

So my question is.., how do you plan on addressing this?

The sanest way of addressing it is only keeping the grid of the focused item, and changing all other items (on the current track only, perhaps?) to the grid of the focused item.

[Evan]

Some nitpicks...

(a)
The docking MIDI editor option is simply titled 'Dock Window'.
Other panels use more descriptive titles such as 'Dock Mixer in Docker', 'Dock media explorer in Docker'.

(b)
Docking the MIDI editor does not put a checkmark in the 'Dock Window' option. It seems as if you need to select 'Dock Window' again to do the opposite.

[xpander]

I'm sorry if I did miss this from some earlier report. If MIDI item has Loop source selected, drawing or dragging the end of the note over the item border will leave just a really short note.
I think the current behavior like in 4.31 is more reasonable, where the note end can be drawn/dragged to the end of the item and it just stays there if mouse is moved further. (When loop source is selected.)

Also, while this is happening, I can still move a note with mouse over the border and the item edge will expand as I go. That is actually something I would expect to happen when loop source is not on.



WinXP Pro 32-bit

--

Originally Posted by Evan

(b)
Docking the MIDI editor does not put a checkmark in the 'Dock Window' option. It seems as if you need to select 'Dock Window' again to do the opposite.

Yep.
http://forum.cockos.com/project.php?issueid=4152

[musicbynumbers]

I would love to see an arrange option that makes any changes you do to a MIDI item copy make the item's colour a little lighter so we can see the one we have only changed a little against the others. Reason does this I think and it could be quite nice. This could also work for audio. Anything that creates a new item in the project bay could change brightness a little.

also, can we be a little silly with the "nickname" when this is released devs?

how about "one window to rule them all!"

[jnif]

Originally Posted by xpander

Yep.
http://forum.cockos.com/project.php?issueid=4152

Yep, yep.
http://forum.cockos.com/project.php?s=&issueid=3659

jnif

[run, megalodon]

Originally Posted by musicbynumbers

I would love to see an arrange option that makes any changes you do to a MIDI item copy make the item's colour a little lighter so we can see the one we have only changed a little against the others. Reason does this I think and it could be quite nice. This could also work for audio. Anything that creates a new item in the project bay could change brightness a little.

also, can we be a little silly with the "nickname" when this is released devs?

how about "one window to rule them all!"

There are already a confusing amount of color options and color quirks in Reaper. I'd hope that anything like this doesn't happen until there is overhaul to make a cohesive system.

[medicine tactic]

Originally Posted by run, megalodon

There are already a confusing amount of color options and color quirks in Reaper. I'd hope that anything like this doesn't happen until there is overhaul to make a cohesive system.

re: overhauls in general, I'm unclear on the exact nature of the constraints imposed by REAPER's development philosophy -- what's described at various times by the terms and phrases "incremental", "feature latch", "continue to support all current workflows", "evolutionary not revolutionary", maybe more.

To use your example, would it be difficult to make the color system more cohesive because doing so would necessarily rearrange aspects of REAPER that are already set in stone? Can REAPER really only be added to, not consolidated/rearranged?

Or is it more a statement about the *rate* of change: that there won't be an abrupt point of discontinuity, but a series of small changes can still radically transform REAPER over time.

Or is it more abstract: REAPER can be consolidated and rearranged as long as the spirit of all current functionality still exists in one form or another, and the same workflows are more or less possible.

Or is it really just a set of guidelines, not rules, and I'm over-thinking this. Maybe it's a fuzzy combination of the above, mixed with enough that's new and exciting to keep the devs loving what they do.

Apologies if this is an annoying question, but I really am curious.

[Lawrence]

Can anyone explain this below?

Preview the correct bass sound from the note but the wrong sound from the piano roll. Flash video below. Reaper pre x64.

http://theaudiocave.com/vids/preview_controller.swf

Under what circumstances, with a single clip open, should I be hearing two different sounds?

[run, megalodon]

Originally Posted by medicine tactic

re: overhauls in general, I'm unclear on the exact nature of the constraints imposed by REAPER's development philosophy -- what's described at various times by the terms and phrases "incremental", "feature latch", "continue to support all current workflows", "evolutionary not revolutionary", maybe more.

To use your example, would it be difficult to make the color system more cohesive because doing so would necessarily rearrange aspects of REAPER that are already set in stone? Can REAPER really only be added to, not consolidated/rearranged?

Or is it more a statement about the *rate* of change: that there won't be an abrupt point of discontinuity, but a series of small changes can still radically transform REAPER over time.

Or is it more abstract: REAPER can be consolidated and rearranged as long as the spirit of all current functionality still exists in one form or another, and the same workflows are more or less possible.

Or is it really just a set of guidelines, not rules, and I'm over-thinking this. Maybe it's a fuzzy combination of the above, mixed with enough that's new and exciting to keep the devs loving what they do.

Apologies if this is an annoying question, but I really am curious.

No problem, that's a lot of questions but here's what I can think of that is relevant.

There are some things about Reapers coloring system that just don't work well. For example, you never really get the color you pick, it is rendered differently for every application. The item, the tcp track panel, mcp track panel, tcp name panel and mcp name panel can all be different tints. Then you get another different tint when a track or item is selected, which can completely obscure the colors that can make it hard to tell what item or track is selected or what exactly the color was before it was selected if you use similar colors. There is also a lot of overlap with the purpose of colors. Pooled midi is automatically colored, which can confuse when item or track are colored. This can be turned off, but it will get newbs. Others will probably be able to mention more things. Now there is talk about coloring items in the midi editor by clip to differentiated them so that using colors for notes becomes more involved and confusing. Then this idea about makes things slightly lighter, which is sure to conflict with selection tinting.

So I think that the only way to eliminate this stuff is to address the whole system.

Cockos developement philosophy, though, is their business. Everyone is unclear on "the exact nature of the constraints imposed by REAPER's development philosophy" because the devs have never clearly stated it and never will, and they probably bend here and there and do what is necessary or find creative solutions, so it is impossible to anticipate what they will be receptive to and present them with what fits into that. You mention "feature latch" which we discussed in another thread. That was taken from askjf.com, where Justin said:

There's always potential in changing things, but of course there's feature latch when tends to override everything.

That is just about as specific as anything we have ever heard Cockos say about their development plans, in fact that is one of the more illuminating statements I've seen, so the everything forum guys know has been gleaned from stuff like that. The only other source is just watching development.

So far from that it would seem that it is true that Reaper can only be added to and not consolidated/rearranged. I can't think of anything that's been taken out or revamped. Usually we've just gotten more and more options until there is sort of a complete set which might be reorganized, and that has worked in a lot of cases.

In some cases, it's weird though, as with area selection. When V4 came around we got the area selection features we have now, but rather than a sort of cohesive area selection that you find in other daws, we got a solution stitched together from item and time selection; modifier actions to make an item and time selection at the same time, and actions that affect selected items within the selected time area. This is a problem for me because (1) there isn't a clear and simple visual indicator of what's selected, (2) selection can be tricky because although time selection snaps to the grid, item selection does not so you have to be very careful about small items near the edges of your selection, and (3) because instead of using the same actions that we do for other stuff, like ctrl+d to duplicate and ctrl+c to copy, we get the set of extra actions that take effect on the "area" selection, so that you have to remember two commands in alot of cases, like ctrl+d and ctrl+shift+d, and in some cases you get behavior you don't want, like if you are trying to copy an item that happens to be partly in the time selection, and you only that part gets copied. It appears things went this way because adding a whole new selection tool would conceptually overlap with time and item selection, and because changing the nature of selection so that only a certain type of selection was allowed at once (so that you could use the same actions on everything with no confusion) would be a big change to the nature of selection in Reaper. Those are my guesses since I don't know what the devs think, but it seems clear that in some way the style of area selection present in basically every other daw was avoided in favor of something that meant less serious changes. I really hope that eventually Cockos will do something to fix this, whether they add something that makes it work, or they relent and do a revamp.

So Cockos might not change any system, but hell, they still might, and I think the best thing to do is just point out what I don't like as a user and let them figure out how to address that. It's true that I do think of what they will and won't do sometimes, because you don't want to be asking for something that is definitely never going to happen, and somethimes you have to get into implementation as we are doing for midi in this thread right now, but I'll go by a case by case basis and in this case all I have to say is that the color system in Reaper is just too convoluted, and I would like something that makes more sense.

[run, megalodon]

And

Originally Posted by medicine tactic

Or is it more abstract: REAPER can be consolidated and rearranged as long as the spirit of all current functionality still exists in one form or another, and the same workflows are more or less possible.

This is a good question and to answer it directly I do not know. I wonder what Cockos will do when things are a few years down the road and there is something in the daw that just can't be adapted to fit a certain problem; when just about everything is perfected and Reaper has a huge user base with alot of pros, and there is a sizeable amount of forum chatter about how everyone hates that one particular thing, like maybe area selection. Will they change it? And how big of a change are they willing to make? How important is it that you can open a project made in Reaper 1.0 in 8.0, especially when you can download the old versions at will, or invent some sort of transfer tool, or even keep the original code but hide it so it's just there for legacy purposes?

[mikeroephonics]

Originally Posted by run, megalodon

How important is it that you can open a project made in Reaper 1.0 in 8.0, especially when you can download the old versions at will, or invent some sort of transfer tool, or even keep the original code but hide it so it's just there for legacy purposes?

From what I can remember, most everything added or changed in REAPER has allowed backwards compatibility with projects created with older versions of REAPER. There have been exceptions, but so few that I can't recall exactly what they were.

Perhaps some system can be put in place to support older projects with newer versions of REAPER (like keeping original/older code hidden, but functional when needed for backwards compatibility with older .rpps.)

[run, megalodon]

Originally Posted by mikeroephonics

Perhaps some system can be put in place to support older projects with newer versions of REAPER (like keeping original/older code hidden, but functional when needed for backwards compatibility with older .rpps.)

Maybe, that will all be up to the devs and if they decide that something really needs a complete overhaul. If they do, I'm sure they won't need our help to figure out how to make it work.

[mabian]

Sorry if it has mentioned before, but I have reverted to 4.31 due to an annoying problem in 4.32pre4: using Linplug RMV, left clicking on a piano roll keyboard note or even the plugin pads the sound is produced only when the mouse button is released.

Reinstalling 4.31, even without reboot, everything is back normal: the preview sound is heard on mouse left button down.

Thanks,
Mario

[xpander]

Originally Posted by jnif

Yep, yep.
http://forum.cockos.com/project.php?s=&issueid=3659
jnif

Whoops, lol. Well, yours is better too, it's still open. Hmmm, I did try searching similar before posting mine, but obviously missed that one. Thanks.

[jnif]

Originally Posted by Lawrence

Can anyone explain this below?

Preview the correct bass sound from the note but the wrong sound from the piano roll. Flash video below. Reaper pre x64.

http://theaudiocave.com/vids/preview_controller.swf

Under what circumstances, with a single clip open, should I be hearing two different sounds?

Looks like you are using multiple MIDI channels in one item.
Something like this:
Rhodes = MIDI channel 1
Bass = MIDI channel 2

Piano keys on the left side of piano roll view will play the channel selected in "Draw events on channel" drop down menu inside Filter events window. So, I think it's not a bug.

Would you like to have a new option like "Selecting a note sets the MIDI channel for new notes"? That would change the "Draw events on channel" automatically when you select notes.

Related to this discussion, there is a bug in previewing of notes when editing multiple tracks at the same time. When selecting notes of the editable inactive item, the preview midi is sent through the active item's track. Thus, a wrong sound is previewed.


jnif

[medicine tactic]

Next pre must be a doozy. My totally uninformed and probably way off-base guess is that now that they've poked at the problem a bit and gained some insight into what it's going to entail, they're going back to de-kludge and generalize the ME infrastructure to more naturally support editing multiple items at once.

[mikeroephonics]

Originally Posted by medicine tactic

Next pre must be a doozy. My totally uninformed and probably way off-base guess is that now that they've poked at the problem a bit and gained some insight into what it's going to entail, they're going back to de-kludge and generalize the ME infrastructure to more naturally support editing multiple items at once.

Here are my ideas on how to determine what MIDI items can be edited simultaneously:
http://forum.cockos.com/showpost.php...&postcount=150

Here's Schwa's response:
http://forum.cockos.com/showpost.php...&postcount=153


I have good feelings about what REAPER v4.32 will have in store for MIDI users.

[medicine tactic]

run, megalodon: Thanks for your responses. I hadn't responded mostly because I agree with you, and didn't have anything to add.

Part of me thinks it'd be nice to have official clarification so we can at least steer our thoughts and requests in the right direction. But another part thinks too much clarification probably isn't good for us or them. Users can get demanding and entitled, and heavy obligation and loss of freedom on the dev side just plain sap energy. Probably best to leave it vague, odd as that may seem, and keep everything more or less possible.

[Seventh]

I feel like I need to keep plugging the MIDI Navigator, because the idea is just too awesome to pass. Hopefully the devs at least consider this.

[swiiscompos]

Originally Posted by Seventh

I feel like I need to keep plugging the MIDI Navigator, because the idea is just too awesome to pass. Hopefully the devs at least consider this.

+1, It would be very very useful!!

[jaydrake]

What am I doing wrong? I can't seem to extend the media item by dragging notes beyond it's original length.

[EvilDragon]

Check if your MIDI editor timebase is set to "Source beats". If yes, change it to "Project beats" or any other. You also have to have that way of editing enabled in Options->Allow MIDI note edit to extend the media item.

[musicbynumbers]

Originally Posted by Seventh

I feel like I need to keep plugging the MIDI Navigator, because the idea is just too awesome to pass. Hopefully the devs at least consider this.

It would be useful yes. It's quite easy to get lost in a sea of notes! plus it allows you to stay focused on the midi editor and not go to the arrange page!

[miche]

Originally Posted by Seventh

I feel like I need to keep plugging the MIDI Navigator, because the idea is just too awesome to pass. Hopefully the devs at least consider this.

Like most here, I would totally love it. If this function is implemented, it could be great if:

1) its size was adjustable
2) there were actions we could assign to shortcuts to show/hide it

That way, we would be able to save on note display for needed parts.

[Argle]

+1, would love something like that.

[medicine tactic]

Originally Posted by Seventh

I feel like I need to keep plugging the MIDI Navigator, because the idea is just too awesome to pass. Hopefully the devs at least consider this.

It is pretty cool. It'd be nice if it could share the horizontal scroll bar area, similar to Ableton. In practice I've found that FL Studio's zoom navigation accomplishes the same thing faster (visual orientation within an entire project combined with easy navigation) using the piano roll itself as the visualization. And we can stitch together something similar to that already with REAPER's zoom actions.

[hamish]

Originally Posted by Seventh

I feel like I need to keep plugging the MIDI Navigator, because the idea is just too awesome to pass. Hopefully the devs at least consider this.

Yes please. I didn't see this earlier, we badly need it. Voted.

[jnif]

Bug in automatic MIDI item extending:

In this video the item extends at time 0:03 but the dragged note is still not moved outside the original item edge. The note jumps erratically back and forth. Note moves correctly later after continuing the left drag much further.

jnif

[hamish]

Originally Posted by jnif

The note jumps erratically back and forth. Note moves correctly later after continuing the left drag much further.

Snapping behaviour? (I can't be bothered testing it myself :P)

Of course even pre-multi-midi I have snap on when extending Items, as I usually want them to be whole bar or beat lengths. Can't imagine extending an item with snap off really

[Anton9]

Originally Posted by Seventh

I feel like I need to keep plugging the MIDI Navigator, because the idea is just too awesome to pass. Hopefully the devs at least consider this.

Great idea.., voted.., also added some more ideas here...,
http://forum.cockos.com/showpost.php...6&postcount=10

[beingmf]

Reading all this, I think it would be useful to use the already existing snap offset when dragging a Midi note beyond the left edge. Original item start would be "anchored", just the left edge would be expanded.
Whaddya think?

[bharath]

The way the default installer installs the program covers up the toolbar above the TCP. This is on fresh install. Small things like this would reek of "non-professional", to fresh Reaper-ites.

Attached is an image of what is happening.

Win7 x64. I think I saw this same unresized toolbar in some video online. Users shouldn't have to resize those couple of pixels to get a neat layout.

[Subz]

Originally Posted by beingmf

Reading all this, I think it would be useful to use the already existing snap offset when dragging a Midi note beyond the left edge. Original item start would be "anchored", just the left edge would be expanded.
Whaddya think?

i always have thought the midi editor deserves a Relative snap & absolute snap option (Like we have in the arrange window)

i also understand that many uses would want to keep the current "both in one" method we currently have

it would be nice to have all 3 options,

1) Smart Snap (Current Method)
2) Relative Snap (Notes move By Grid amounts)
3) Absolute Snap (notes move To the Grid)

just my 2p

Subz

[clerks]

Originally Posted by Seventh

I feel like I need to keep plugging the MIDI Navigator, because the idea is just too awesome to pass. Hopefully the devs at least consider this.

+1
voted too, it would be great

[Dstruct]

Originally Posted by gofer

There is definitely something wrong with MIDI Preview with respect to anticipative processing.

Can someone check this please:

- In Preferences/Audio/Buffering have Anticipative FX processing enabled. Render-ahead is set to 200ms, "Allow on tracks w/o FX" is disabled as well as "Allow on tracks with MIDI editor".

- Create three tracks A, B and C and make A a folder parent of B and B a parent of C.
A
..B
....C

- Put a synth (ReaSynth) onto track C
- Put any FX (ReaEQ) onto both, A and B (If you want the issue even more noticeable, put another FX onto the master.)
- create a MIDI item on C and open the editor to test MIDI preview (click a piano key, scrub, do whatever it takes).

=> MIDI Preview will have noticeable latency. You can switch that additional latency off by bypassing the FX plugin chains (bypassing the individual plugins doesn't help). For giggles, enable "Allow anticipative on tracks with MIDI editor" and compare again with all FX chains bypassed vs all chains active.

The same happens when I use sends instead of folder routing. That can be audio or MIDI sends, doesn't matter. As long as the send is active and the FX chain unbypassed the latency will occur and cumulate with every track you send in series (as in send from C to B to A (to Master)).


I get this issue since exactly v4.32-dev-pre3 with any plugins I tried.

Sounds like it comes from this change:

"Anticipative FX multiprocessing: improved performance in certain routing/PDC combinations"