MPL Dump Retrospective Record log (no JSFX required)

[_Stevie_]

Originally Posted by mpl

And please use links to GIFs or smaller GIFs. I hate Reaper5 forum theme and my Reaper3 forum view is awfully wide with such GIFs.

Sorry, saw this only by now! Will keep it in mind.

Could you nail the issue with my attached project?

[mpl]

Originally Posted by _Stevie_

Could you nail the issue with my attached project?

After couple of tests 1.05 seems working with your project. Although can be still an issue with negative offsets.

[matthias.matthias]

Originally Posted by mpl

After couple of tests 1.05 seems working with your project. Although can be still an issue with negative offsets.

Thanks a lot! It's working great for me now.

BTW: the offsets used in film post production (positive full hours) were introduced to avoid a negative time code just before the project start, because negative offsets were causing problems... ;-)

[_Stevie_]

Yes, indeed mpl, no worries for negative offsets. Matthias already summed it up perfectly

I small little issue remains. AFAIK, this happens, when the MIDI Take doesn't have the same length as the Item:

[mpl]

Technically it is CC123 (all notes off message, typical for any MIDI item) after last message so it should not be a problem. If you open it in MIDI editor and add somewhere note, it should fix item view visually.

[_Stevie_]

MPL, I'm sorry to say but this is somehow not satisfying. I tried to work around it, but it's really overcomplicating things.

The "all notes off" generates all kinds of problems. Isn't there a way to fis this in the script? Would be very much appreciated!

[TonE]

Originally Posted by _Stevie_

MPL, I'm sorry to say but this is somehow not satisfying. I tried to work around it, but it's really overcomplicating things.

The "all notes off" generates all kinds of problems. Isn't there a way to fis this in the script? Would be very much appreciated!

Stevie you could find the correct line and comment it out, adding -- before it. Just for testing if it helps. Look for the number 123 as written above.

[mpl]

CC 123 in Reaper is a way to mark midi item source length. It closes any MIDI item, therefore it always should be here

[_Stevie_]

Absolutely, it NEEDS to be there. It shouldn't be ommited.
But the CC123 should be set at the item end, so that take and item
have the same length.

[TonE]

What is the case now, something what should be at the end is in the middle or what, then that would be a bug. There is CC123, but in wrong position? If yes, it should be moved to correct position.

[_Stevie_]

Check my GIF and you see what I mean.

[Klangfarben]

I just want to add that the CC123 message is very dangerous and can have a lot of unintended consequences. That is why no user ever writes CC123 into a midi item in day-to-day midi editing.

I don't think this is a question of "can we move the CC123 event". I think the question should be can this be done without any CC123 message at all? Because anything else like I said is really, really dangerous - and will also break a lot of other scripts we use.

MPL, can this script work without inserting the CC123 message and still have Reaper get the midi item source length?

[mpl]

Originally Posted by Klangfarben

I think the question should be can this be done without any CC123 message at all?

No, it can`t be done without this. I replaced manual adding CC123 by native API function for setting item edges properly, see 1.06.

[Klangfarben]

Originally Posted by mpl

NI replaced manual adding CC123 by native API function for setting item edges properly, see 1.06.

Thank you so much!

[_Stevie_]

This looks really good so gar mpl, thank you so much! Now everything works

[_Stevie_]

I just found an issue that I hadn't thought about, until now.
When having tempo changes in the project, retrospective record does not
follow them. Maybe that's a corner case that hasn't been taken into account?

[Breeder]

Would it be possible to keep a separate buffer for each track?

I'm thinking how that would be handled (to keep buffer synchronized across all tracks) and this first came to mind ->

If there are multiple buffers for multiple tracks and not all of them are selected for processing by the script just ask the user if all MIDI data may get dumped to respective tracks (or all data to one track or just the selected tracks while other data gets removed so the buffer is always synchronized across tracks)

Or maybe two actions - one to dump all data to one track (the script we currently use) and another one to dump to respective tracks (the second one wouldn't care about the current track selection, it would dump to all the tracks that have buffer data)

[mpl]

Originally Posted by Breeder

Would it be possible to keep a separate buffer for each track?

This requier some king of identification of JSFX. I imagine a special variable in JSFX, return track GUID or track index JSFX sitting at, so I can do something like

desc:RetrospectiveRecord_tracker
options:gmem=str_insert(get_parent_track_GUID,"mpl_RetrospectiveRecord",0)

and ask buffer related to selected tracks by GUID further from reascript

[Klangfarben]

Hi MPL, were you able to fix the bug with tempo changes? I can't really use it until it works correctly with tempo changes as most everything I write has them.

Thanks!

[Breeder]

Originally Posted by mpl

This requier some king of identification of JSFX. I imagine a special variable in JSFX, return track GUID or track index JSFX sitting at, so I can do something like

desc:RetrospectiveRecord_tracker
options:gmem=str_insert(get_parent_track_GUID,"mpl_RetrospectiveRecord",0)

and ask buffer related to selected tracks by GUID further from reascript

Ah, for some reason I always think that JS can call basic API which seems not to be the case.

Oh well, it's not a real problem, hopefully it will be solvable in the future

[_Stevie_]

Originally Posted by Klangfarben

Hi MPL, were you able to fix the bug with tempo changes? I can't really use it until it works correctly with tempo changes as most everything I write has them.

Thanks!

Bump for this one ^^^^^^^

[_Stevie_]

I added some features:

- after dumping the item, the item is selected (great if you want to edit the item in the MIDI editor afterwards)

- the item is trimmed to its content (Breeders SWS action) and then extended to the next 1/4 grid (thanks mpl for the algo!). That way it's easier to move the item on the grid, after having recorded it.

Feel free to incorporate these features, if you like.

[TonE]

Thanks Stevie for sharing, why you decided for next 1/4 grid, and not 1/1 grid for example? It would be cool having a few youtube examples, how these scripts can be used in practice? For example can this script also be used for building an Alk2 workflow inside Reaper? Somehow this seems to be relevant as well.

[_Stevie_]

A 1/1 grid leaves a lot of "white space" in front of the item, whereas 1/16 would have been too unprecise, if zoomed out (I work with zoom dependent grid in my projects). I'm not familiar with ALK2. This is really just a tiny improvement for mpl's retrospective record. It doesn't introduce a new workflow.

[TonE]

Originally Posted by _Stevie_

I'm not familiar with ALK2.

Me, too, just saw few youtube videos, thought how this could be possible with Reaper. Currently most promising is using MIDIToReaControlPath for generating action items.

[mpl]

Originally Posted by Klangfarben

Hi MPL, were you able to fix the bug with tempo changes? I can't really use it until it works correctly with tempo changes as most everything I write has them.

Thanks!

I don`t think I can help here, any help from some clever code guru would be much appreciated.

[lb0]

Originally Posted by mpl

I don`t think I can help here, any help from some clever code guru would be much appreciated.

I would store each recorded message against actual play position when capturing when playback is active.

You're already checking in the JSFX whether playback is active or not (in order to empty the buffer?).

Just have 2 modes in the JSFX - one captures (when stopped) against timeprecise (as you're already doing) - the other (when playing back) captures against play position.

Have a flag to indicate which mode corresponds to the data - so when reading the data into a midi item - it knows whether the midi message location should be translated as a specific time from beginning - or an actual playback position.

Of course - I'm assuming the created midi item will always be placed where playback was started.

I've not tried out your script - but I think this would be the easiest way to do it so it corresponds to tempo changes.

EDIT:

TBH - I'm not sure why your method isn't following tempo changes. I'm assuming the tempo changes already exist along the timeline - then I'm unsure as to why recording simply against a start time position and then time of event after that position doesn't follow... So maybe I'm missing something.

Do you know if Eugen's original jsfx works ok in this area?

[Klangfarben]

I think the issue here is that there is only one buffer - both for capturing while stopped and capturing while playing. There really needs to be two in the script so that the script is aware when the transport is stopped and when it is playing. Either that or the buffer needs to clear on play.

If you don't differentiate between capture while stopped and capture while playing, then the script will not be able to deal with tempo changes. Because how could it capture and know what the tempo changes are while stopped?

If the script knows when the transport is playing vs transport stopped then it shouldn't be a problem to capture events correctly with tempo changes.

EDIT: Yes, Eugen's original eel script for this works perfectly fine with tempo changes. However, his script obviously can't capture while stopped so the above isn't an issue.

[lb0]

Originally Posted by Klangfarben

I think the issue here is that there is only one buffer - both for capturing while stopped and capturing while playing. There really needs to be two in the script so that the script is aware when the transport is stopped and when it is playing. Either that or the buffer needs to clear on play.

If you don't differentiate between capture while stopped and capture while playing, then the script will not be able to deal with tempo changes. Because how could it capture and know what the tempo changes are while stopped?

If the script knows when the transport is playing vs transport stopped then it shouldn't be a problem to capture events correctly with tempo changes.

EDIT: Yes, Eugen's original eel script for this works perfectly fine with tempo changes. However, his script obviously can't capture while stopped so the above isn't an issue.

Ah - I thought this script emptied the buffer when playback starts.

In which case - I would empty the buffer when playback starts - and note the start position. Nothing else need change.

Of course - this stops the ability to record when stopped and then continue capturing when playing - but is that a real requirement? If this were a requirement - then yeah - 2 separate buffers would allow this - as long as the playback captured buffer was aligned with where playback was started.

Personally - easiest way is to simply wipe the buffer if playback starts.

EDIT:

You may get some weirdness if you continue playing notes having stopped playback - as these would be added onto the end - but is that so likely?

[Klangfarben]

Originally Posted by lb0

Of course - this stops the ability to record when stopped and then continue capturing when playing - but is that a real requirement? If this were a requirement - then yeah - 2 separate buffers would allow this - as long as the playback captured buffer was aligned with where playback was started.

Right. As Stevie and I said earlier there really is never a situation where you would want to play while stopped, then hit play and capture everything together. So having the buffer clear on play would be a perfectly fine solution without the need for coding two buffers.

The problem currently that the script MPL wrote to clear the buffer is not part of the main script, so the main script still has no idea of what the current start position should be. I'm assuming if that were incorporated into the main script it would work correctly?

Originally Posted by lb0

You may get some weirdness if you continue playing notes having stopped playback - as these would be added onto the end - but is that so likely?

I don't see this being an issue. This really isn't likely.

[_Stevie_]

Everything what Klangfarben said! I completely agree

[lb0]

Originally Posted by Klangfarben

The problem currently that the script MPL wrote to clear the buffer is not part of the main script, so the main script still has no idea of what the current start position should be. I'm assuming if that were incorporated into the main script it would work correctly?



I don't see this being an issue. This really isn't likely.

I would clear the buffer in the JSFX when it 'notices' that playback has started. It's already monitoring the playstate in order to store playback position.

A simple reset of stored message position and count at this stage would probably be enough.

[_Stevie_]

That would be perfect!

[lb0]

Edit: didn't work!

[mschnell]

Will there not be a problem due to the fact that between gmem send and receive in different tracks a "virtual timing" delay of +/- the complete latency set by the project (set by the samplerate, block size and block count) is possible ?

-Michael

[lb0]

Originally Posted by mschnell

Will there not be a problem due to the fact that between gmem send and receive in different tracks a "virtual timing" delay of +/- the complete latency set by the project (set by the samplerate, block size and block count) is possible ?

-Michael

Actually - yes - this would likely be a problem. You cannot rely on timeprecise to store the timing difference between incoming MIDI messages within @block (as they are processed in a block and not 'live').

Eugen's original JSFX did it differently - and calculated the actual playback position according to the block start and offset - which would IMO be far more accurate.

[_Stevie_]

Nope, doesn't work here. When I first noodle around while playback is stopped and then start the playback, I get both recordings.

[lb0]

Originally Posted by _Stevie_

Nope, doesn't work here. When I first noodle around while playback is stopped and then start the playback, I get both recordings.

When I tested last night - my edit was working ok for me. Are you sure you're running the edited version (and you haven't got 2 copies of the JSFX running at once - one of them the old version)?

But anyway - I think there are bigger issues currently with the way the message position data is calculated - meaning that timing issues will occur for the stored midi messages. If you have a very small block size - they will be less noticeable - but still inaccurate.

As mschnell pointed out - the position data needs to be calculated using the block start time, block count, block length, and MIDI message offset in order to be accurate.

[_Stevie_]

Yep, I attached a licecap:

https://i.imgur.com/GeM5sC0.gif

[lb0]

Originally Posted by _Stevie_

Yep, I attached a licecap:

https://i.imgur.com/GeM5sC0.gif

You're right! Doesn't seem to work on my laptop either - but was ok on my studio pc last night. Although I think there were possibly other alignment issues I hadn't noticed...

Needs more work

EDIT:

Ah - of course - if no midi is being received when playback changes then it won't work with my hack above.

I have worked out a way to get it working - but it's not fit for purpose anyway as the alignment of the MIDI item is with the first midi message received and not when you press play.

I have a lot of background midi stuff going on on my studio machine - so that's probably why I didn't notice these issues.