v6.78+dev0318 - March 18 2023

[Daodan]

Another important question I had while I was testing this.
How one can remove multiple lanes at once?

[akademie]

Bug:

Project tabs: Move project tab to position 3 moves tab from position-1 to position-2 only, not position-3 etc.
BUT
moves correctly tab eg. from position-5 to position-3 etc.

Seems like that it works correctly if moving from higher position to lower position, but from lower to higher is calculated like tab#-1 or something like that.

[deeb]

Originally Posted by Daodan

Another important question I had while I was testing this.
How one can remove multiple lanes at once?

I guess is one by one. Like with envelope lanes. Not great.

[tonalstates]

If you delete a record armed track Reaper just poofs out of existence

Edit: This also happens in the Official 6.78

[bolgwrad]

I can't work out what this white slope is, and why it only occurs on the one (red, bottom) track.





Windows XP. I also drive an old car.

[schwa]

Originally Posted by bolgwrad

I can't work out what this white slope is, and why it only occurs on the one (red, bottom) track.

The bottom lane has the media split at the crossover point, so the media can't be overlapped, so the actual fades applied to the media are not the same as the comp area crossfade.

[schwa]

Originally Posted by tonalstates

If you delete a record armed track Reaper just poofs out of existence

Edit: This also happens in the Official 6.78

I don't think this happens in general. What OS? Any FX on the track? Does it happen if you select "dummy audio" as the audio device?

[schwa]

Originally Posted by Daodan

Thank you guys. It doesn't work from action list but works as keyboard shortcut or mouse modifiers action.
Yes, right-click menu option would be nice.

The action should be named "... for track under mouse." It's also in the right-click menu for the TCP lane buttons.

[Phazma]

Would it be possible to have the action "Insert new MIDI item..." respect the focused lane?

I have it set as default action for double click on tracks and it doesn't work properly on fixed lanes, always inserting on the first lane instead of the lane onto which I double-click:

[FeedTheCat]

Originally Posted by ferropop

I also don't see the need for editing Comp Lane while comping is on -- it's one shortcut to turn off/on.

Especially now, if you turn off comping, make some edits in comp lane, turn comping on -- the comp area remains so edges/crossfades stay nice - and you can immediately bump those edits to a new lane to preserve.

You have full editing tools while editing, full comping tools while comping, and switching between is a single keystroke, and no need for a trillion things competing for your attention.

I'm still of the opposite opinion, but probably not for the reason you'd think. The current implementation basically motivates you to go out of comping to do your edits, since only then you have the full feature set of editing tools available.

But is that what you want? You have no idea how your edits are going to affect your comp areas and impede the ongoing comping process.

Here's a simple example:

When comping vocals, you usually start by comping the best phrases. Then as you go on you might notice certain words in a phrase that need improvement.

Let me adjust the timing of a word by editing outside of comping:



When I go back to comping, I can see that my comp area just poofed. I have no clue where the rest of the phrase comes from. Should I have done the same edit with comping enabled? Create a new comp area for the word and move it together with its items? Which sorts of edits are comp-area-friendly and how do I retrain my brain from hundreds of hours editing the "normal" way?

This is why I've argued for a item-focused comp area implementation:



Imo we don't need comp areas in the comp lane at all. Comp areas don't need their own edges in the comp lane. Items already have edges. Comp areas don't need their own fades. Items already have fades. Let us edit item edges and fades as we always have, and recalculate matching comp areas for items/clusters of items. I still think such an approach would be simpler and more predictable, easier to implement and maintain, and more useful for comping actually.

Worst case, I waste more of schwa's time with my silly ideas

[schwa]

One way to do that edit with the current +dev build would be like this:

[FeedTheCat]

Here's another example with adjusting crossfades using the "normal" tools and then turning comping back on again for a nice surprise:



Why not have it work like this:



It feels extremely liberating to use "normal" tools to adjust comp areas... Hard to describe even... here's the script I used for the preview if someone want to try. Make sure the track is selected and copy items into the first lane via razor edits (or reaper comping mode and turn it off afterwards).

local is_windows = reaper.GetOS():match('Win')
local main_hwnd = reaper.GetMainHwnd()
local arrange_hwnd = reaper.JS_Window_FindChildByID(main_hwnd, 1000)

local GetTakeInfo = reaper.GetMediaItemTakeInfo_Value
local GetItemInfo = reaper.GetMediaItemInfo_Value

local prev_sel_item
local prev_sel_item_cnt
local prev_vpos
local prev_hsize
local prev_hpos
local prev_vsize
local prev_edit_time
local prev_hzoom
local prev_item_h
local prev_take
local prev_mouse_state

local areas

local function GetItemLane(item)
    local h = reaper.GetMediaItemInfo_Value(item, 'F_FREEMODE_H')
    local y = reaper.GetMediaItemInfo_Value(item, 'F_FREEMODE_Y')
    return y / h
end

function GetAreaCoords(item, start_offs, length)
    local track = reaper.GetMediaItem_Track(item)
    local track_y = reaper.GetMediaTrackInfo_Value(track, 'I_TCPY')

    local item_y = GetItemInfo(item, 'I_LASTY')
    local item_h = GetItemInfo(item, 'I_LASTH')

    local area_y = track_y + item_y
    local area_h = item_h

    local GetArrangeView = reaper.GetSet_ArrangeView2
    local av_start_pos, av_end_pos = GetArrangeView(0, false, 0, 0, 0, 0)
    local av_length = av_end_pos - av_start_pos

    local item_length = GetItemInfo(item, 'D_LENGTH')
    local item_start_pos = GetItemInfo(item, 'D_POSITION')
    local item_end_pos = item_start_pos + item_length

    local length = length or item_length
    local start_pos = item_start_pos

    if start_offs then
        local take = reaper.GetActiveTake(item)
        local take_start_offs = GetTakeInfo(take, 'D_STARTOFFS')
        start_pos = start_pos + start_offs - take_start_offs
    end

    local end_pos = start_pos + length

    if start_pos < item_start_pos then
        start_pos = item_start_pos
        end_pos = end_pos - (item_start_pos - start_pos)
    end

    end_pos = math.min(end_pos, item_end_pos)

    local _, av_pixel_w = reaper.JS_Window_GetClientSize(arrange_hwnd)
    -- Needed for scrollbar?
    av_pixel_w = av_pixel_w + 18

    local area_x = (start_pos - av_start_pos) / av_length * av_pixel_w
    local area_w = (end_pos - av_start_pos) / av_length * av_pixel_w - area_x
    
    return math.floor(area_x), area_y, math.floor(area_w), area_h
end

function AddAreas(main_item)

    local main_take = reaper.GetActiveTake(main_item)
    local main_source = reaper.GetMediaItemTake_Source(main_take)
    local main_file = reaper.GetMediaSourceFileName(main_source)

    local GetMIDIPool = reaper.BR_GetMidiTakePoolGUID
    local main_midi_pool = ''

    if reaper.TakeIsMIDI(main_take) and GetMIDIPool then
        main_midi_pool = select(2, GetMIDIPool(main_take))
    end

    local track = reaper.GetMediaItem_Track(main_item)

    -- Find items that share the same source as main item
    local shared_source_items = {}
    for i = 0, reaper.CountTrackMediaItems(track) - 1 do
        local item = reaper.GetTrackMediaItem(track, i)
        if GetItemLane(item) > 0 then
            local take = reaper.GetActiveTake(item)
            local source = reaper.GetMediaItemTake_Source(take)
            if reaper.TakeIsMIDI(take) then
                if main_midi_pool ~= '' then
                    local _, midi_pool = GetMIDIPool(take)
                    if midi_pool == main_midi_pool then
                        table.insert(shared_source_items, item)
                    end
                end
            else
                local file = reaper.GetMediaSourceFileName(source)
                if file == main_file and item ~= main_item then
                    table.insert(shared_source_items, item)
                end
            end
        end
    end

    local main_area = {}
    local main_x = GetAreaCoords(main_item)
    local main_length = GetItemInfo(main_item, 'D_LENGTH')
    local main_start_offs = GetTakeInfo(main_take, 'D_STARTOFFS')
    
    -- Check if area can be created on source item
    for _, item in ipairs(shared_source_items) do
        local x, y, w, h = GetAreaCoords(item, main_start_offs, main_length)
        if math.abs(x - main_x) <= 1 and w > 1 then
            local area = {}
            area.pos = {x, y, w, h}
            table.insert(areas, area)
        end
    end
end

function DestroyBitmaps(areas)
    if not areas then return end
    for _, area in ipairs(areas) do reaper.JS_LICE_DestroyBitmap(area.bitmap) end
end

function Main()
    
    local track = reaper.GetSelectedTrack(0, 0)
    if not track then
        reaper.defer(Main)
        return
    end
    
    -- Monitor a bunch of stuff that could potentially change areas
    local _, vpos, vsize = reaper.JS_Window_GetScrollInfo(arrange_hwnd, 'v')
    local _, hpos, hsize = reaper.JS_Window_GetScrollInfo(arrange_hwnd, 'h')
    local edit_time = reaper.GetItemEditingTime2()
    local hzoom = reaper.GetHZoomLevel()
    local sel_item = reaper.GetSelectedMediaItem(0, 0)
    local item_h = sel_item and GetItemInfo(sel_item, 'I_LASTH')
    local take = sel_item and reaper.GetActiveTake(sel_item)
    local mouse_state = reaper.JS_Mouse_GetState(-1)
    
    if mouse_state ~= prev_mouse_state or vpos ~=
        prev_vpos or vsize ~= prev_vsize or hpos ~= prev_hpos or hsize ~=
        prev_hsize or edit_time ~= prev_edit_time or hzoom ~= prev_hzoom or
        item_h ~= prev_item_h or take ~= prev_take then
        
        prev_vpos = vpos
        prev_hsize = hsize
        prev_hpos = hpos
        prev_vsize = vsize
        prev_edit_time = edit_time
        prev_hzoom = hzoom
        prev_item_h = item_h
        prev_take = take
        prev_mouse_state  = mouse_state

        DestroyBitmaps(areas)

        areas = {}
        
        -- Calculate new areas
        for i = 0, reaper.CountTrackMediaItems(track) - 1 do
            local item = reaper.GetTrackMediaItem(track, i)
            if GetItemLane(item) == 0 then
                AddAreas(item)
            end
        end
        
        -- Adjust overlapping areas (crossfades)
        for a = 1, #areas - 1 do
            local area = areas[a]
            local next_area = areas[a + 1]
            local r = area.pos[1] + area.pos[3]
            local x = next_area.pos[1]
            if r > x + 1  then
                local mid = (r - x) // 2
                next_area.pos[1] = x + mid
                next_area.pos[3] = next_area.pos[3] - mid
                area.pos[3] = area.pos[3] - mid
            end
        end

        -- Create new area bitmaps
        local alpha = is_windows and 0.5 or 1
        for _, area in ipairs(areas) do
            local w, h = area.pos[3], area.pos[4]
            area.bitmap = reaper.JS_LICE_CreateBitmap(true, w, h)
            reaper.JS_LICE_FillRect(area.bitmap, 0, 0, w, h, 0x15ffcb00, alpha, 0)
            reaper.JS_LICE_RoundRect(area.bitmap, 0, 0, w- 1, h - 1, 0, 0xF3ffeda4, alpha, '', false)
        end

        reaper.UpdateArrange()
    end

    if areas then
        -- Draw areas
        for a, area in ipairs(areas) do
            local bitmap = area.bitmap
            local x, y, w, h = table.unpack(area.pos)
            reaper.JS_Composite(arrange_hwnd, x, y, w, h, bitmap, 0, 0, w, h)
        end
    end
    reaper.defer(Main)
end

function Exit() DestroyBitmaps(areas) end
reaper.atexit(Exit)

Main()

[FeedTheCat]

Originally Posted by schwa

One way to do that edit with the current +dev build would be like this:

Yes, this would currently be the correct way. My point is that editing outside of comping is undesirable, since you can not predict what will happen to comp areas. But also editing with comping enabled is rather weird as you can't use your "normal" editing process. The different behavior on edges/crossfades and just the fact that you have to double click to edit inside a framed box, encourages you to turn comping off for editing.

[schwa]

Originally Posted by FeedTheCat

Why not have it work like this:

I don't want to get into a whole back and forth here, but what happens to that crossfade if you then change the source media lane? What if you change the source media lane so the same source media is used for the left and right side of the crossfade? What if you change the source media lane to one where the source media does not extend all the way into the crossfade area? The basic problem with storing no information about the comp lane anywhere other than in the media items themselves is that the comp-specific information becomes very fragile. That's not to say the suggestion is bad, just that there are a lot of tradeoffs.

The analogy with the "classic" REAPER comping system would be that information about fades is stored with the media items themselves, not the individual takes. The media item is a container that applies certain transformations, like fades, to the individual takes which can be swapped out.

[Vagelis]

Originally Posted by FeedTheCat

I'm still of the opposite opinion, but probably not for the reason you'd think. The current implementation basically motivates you to go out of comping to do your edits, since only then you have the full feature set of editing tools available.

FTC exactly my concerns as well, while we can edit anything without comping on, it still feels not so instant in case we want to repeat this many times.

That's why i suggested an option to show as editable the comp areas in comping lane, we don't lose comp areas, we can instantly edit the item as previously and NOT the comp area. BUT i really hope the lines to the left and right side of editable areas will become a lot thinner to edit easier the items inside.

[bolgwrad]

Originally Posted by schwa

The bottom lane has the media split at the crossover point, so the media can't be overlapped, so the actual fades applied to the media are not the same as the comp area crossfade.

Got it, thanks very much.

[FeedTheCat]

Originally Posted by schwa

I don't want to get into a whole back and forth here

I understand, and you won't, I promise. I'll think about your questions and write up an answer.

[Vagelis]

Also in comping lane the default is to create area why? It should have the default media modifier when we grab an item outside an editable area too! This small thing could make it feel a lot more natural for editing, in case one wants to create an area there's already a modifier for it, it doesn't need to be the default in comping lane imo.

EDIT: Or at least give US an option to have the behavior we want, an action could override to create comp areas in comping lane and in inactive areas for the above and this reason: https://forum.cockos.com/showpost.ph...3&postcount=12

Using the default media modifiers while comping, is going to be the best imo for these cases without needing to exit comping.

[uncleswede]

Originally Posted by tonalstates

If you delete a record armed track Reaper just poofs out of existence

Edit: This also happens in the Official 6.78

Hmmm... deleting a record-armed track doesn't happen here in 6.78. There must be some other factor in your situation...

[FeedTheCat]

Originally Posted by schwa

I don't want to get into a whole back and forth here, but what happens to that crossfade if you then change the source media lane? What if you change the source media lane so the same source media is used for the left and right side of the crossfade?

The crossfade stays, similar to the classic comping system, even if you switch to the same source on both sides. I personally don't think that's a big deal, but if it is, I'm sure there would be some sort of convoluted solution to get the current behavior.

The nice thing with the new system is that you can easily get rid of splits/crossfades in adjacent items with a single click.

Originally Posted by schwa

What if you change the source media lane to one where the source media does not extend all the way into the crossfade area?

This is where you'd need composite comp areas. Multiple items that agree to belong to the same comp area or to an area that is larger than themselves. (each item knows its position inside the composite comp area and can detach itself when edited)

GIF: When switching to the fourth lane you'd have to create a composite area in order to keep the same visible size. The item fade on the right side should probably be adjusted in that state.

Originally Posted by schwa

The basic problem with storing no information about the comp lane anywhere other than in the media items themselves is that the comp-specific information becomes very fragile.

Saving the info within media items would make sense to me, but it isn't necessary. You can also just give each item a reference to its comp area. (saving within the item does have some perks, e.g. when moving items to sub-project)

What I'm suggesting is that upon being edited, any item in the comp lane will try to calculate a new comp area for itself. If it already has a reference to an existing comp area it will recalculate the affect of the edit on that existing comp area (and if necessary detach itself to a new area).

Originally Posted by schwa

That's not to say the suggestion is bad, just that there are a lot of tradeoffs.

I get it, and there might be potential features that this approach could get in the way of. With many issues that have come up I'm thinking "that would be no issue with this approach" but I'm aware that we'd have other issues instead It's just that at this point, the tradeoffs look rather enticing to me.

Thank you for engaging schwa. It might not come across in my posts, but I completely trust your intuition and judgement on any of this

[muorsic]

Hello! I wanted to express my gratitude for the recent update that allows us to "play video from background projects". As a Film/TV composer, this feature is a game-changer, as it allows us to have a master video file in the background, while separately opening individual session files that will play the video with the project's time offset. This saves us time importing the same video file to every session and moving it around.

In addition, this feature works better than "slaving" another machine/daw with MTC (MIDI Timecode) because editing and moving items correspond with the video location, resulting in better overall playback without lag.

While this is a huge leap, I have three more requests that will make this option even more useful for us:

1. Having the option to route the audio from the video file inside the background project to an output and play it back with the video would be very useful. This would eliminate the need to import the video's audio into the active project tab. Without this option, it would be more practical to keep importing the video each time.
2. There is a small issue with Reaper projects always starting on a whole frame, which can cause the frame counter to display the wrong frame when the time offset requires the project to start mid-frame. This becomes more visible when a video with Timecode burned in is running in the background project, and the project time offset is correct, but the displayed timecode on the counter is not always accurate.
3. In the future, it would be great to find a way to make this feature work the same way with a separate machine running a background project video over a local network. Some composers prefer to keep the video machine with sensitive files offline, but the main sequencing machine connected to the internet.

[Justin]

Originally Posted by muorsic

1. Having the option to route the audio from the video file inside the background project to an output and play it back with the video would be very useful. This would eliminate the need to import the video's audio into the active project tab. Without this option, it would be more practical to keep importing the video each time.

You can do this already, just set the options to have the background project play with the current project

[muorsic]

Originally Posted by Justin

You can do this already, just set the options to have the background project play with the current project

Amazing! Just got it working, had a feeling there might be something I am missing.
Thank you so much.

[tonalstates]

Originally Posted by schwa

I don't think this happens in general. What OS? Any FX on the track? Does it happen if you select "dummy audio" as the audio device?

It's on Mojave 10.14, no effect or anything, just a clean session. I don't have the dummy audio option here, on <none> the same happens...



----

Edit: Ok, so yeah, it makes sense, it wasn't REAPER but edkashinky's global startup action from this pack

https://github.com/edkashinsky/reaper-reableton-scripts

after taking it out of the sws global startup actions this behavior went away, idkw because I have nothing on it that would mess with armed tracks, the one option he has about it (Different sample rate for recording) I don't have it on. So yeah.. I don't remember this happening before which is weird but ok.

[Daodan]

Originally Posted by schwa

The action should be named "... for track under mouse." It's also in the right-click menu for the TCP lane buttons.

Nice, thanks!