sends envelopes not recalled correctly with snapshots

[Jeff0S]

From nofishonfriday on December 09, 2012 18:31:33

What steps will reproduce the problem? see attached example project
it contains one snapshot with send automation, which was saved with the send automated (exactly as you see it when you open the project)
now recall this snapshot, send automation is gone (envelope is at 0db)

What version of SWS extension are you using? (Extensions -> About SWS...)

2.3.0 #4 What is your Reaper version number and CPU architecture (e.g. Reaper 3.75 x64)? 4.32 RC1 What operating system are you running? (e.g. Windows XP/7, OSX 10.5.8 etc, 64bit?) WinXP32 SP3

Attachment: snapshots send automation bug test.RPP

Original issue: http://code.google.com/p/sws-extension/issues/detail?id=537

[Jeff0S]

From nofishonfriday on December 09, 2012 09:36:52

forgot to mention, this is reproduceable every time here
ie create a new snapshot with the automated send, recall, automation is gone

Thanks for having a look.

[Jeff0S]

From considin...@gmail.com on December 11, 2012 11:41:01

I can confirm that (although my SWS build is a touch stale)

[Jeff0S]

From swstim on December 11, 2012 12:19:55

I hear ya. This is a non-trivial upgrade to snapshots, please bear with me as I figure it out in my miniscule free time.

Status: Accepted
Owner: swstim

[Jeff0S]

From nofishonfriday on December 11, 2012 12:47:30

Thank you.

[Jeff0S]

From considin...@gmail.com on March 05, 2013 02:49:39

Any news on this one? If nothing has been done, I could have a look at it (though I'm slow at figuring out other peoples code). Snapshots are important to me these days and this is a nasty flaw.

[Jeff0S]

From swstim on March 05, 2013 07:07:50

I've looked at it a little, and it's not an easy fix at all. I don't know that I'm going to be able to do it.

The snapshots feature is fragile in the sense that it's tied very closely to Reaper's internal workings, and when things change (or get added in this case) in Reaper it breaks things. I can't keep up with these changes.

[Jeff0S]

From nofishonfriday on March 05, 2013 13:25:41

Thanks for having a look Tim.
An idea (suggestion):

For me the situation is, I have automated send envelopes in nearly all off my projects but actually I wouldn't need them to be 'snapshotted'.
So how about (an option) for now to simply ignore them when doing full track mix snapshots ?

(This would be totally fine with me at least)

[Jeff0S]

From swstim on March 06, 2013 13:39:35

Sounds easy, but it's not. 2 issues: 1) The envelope in in the "XML" of the track, which means parsing the XML and keeping the envelope there to ignore it. If we got that much working, it'd be trivial to add the full functionality. 2) Sends are stored as receives, so the data isn't where you'd expect it to be - any time you modify the sending track, you need to find all its receives and update all the references to the sending track, etc. There's already mechanism in the code to do this, but it needs to be extended to work with envelopes, too.

[Jeff0S]

From considin...@gmail.com on March 13, 2013 06:01:51

Tim, perhaps a warning could be given so this doesn't bite the unwary?

[Jeff0S]

From considin...@gmail.com on March 30, 2013 12:41:48

Tim, I've been hacking at this and I've managed to get send envelopes stored and restored seemingly okay but there's probably a ton of bugs waiting to show up. I'm thinking that since you thought you might not be able to do it, it's probably way more complex than I imagine. Can you think of any issues that I might need to deal with beyond just storing and restoring envelopes?

Also, I don't want to commit what I've done as I could easily have broken something without realising. Can I send you a patch or something?

[Jeff0S]

From considin...@gmail.com on March 31, 2013 05:44:55

Never mind, I get it now. It's all about the chunk. Tricky.

[Jeff0S]

From swstim on March 31, 2013 17:41:40

Thanks for taking a look! If you ever want to "audition" code just make yourself a branch and check it in there.

[Jeff0S]

From considin...@gmail.com on April 01, 2013 13:04:42

Okay, will do. Looks to me like the snapshot code could use a bit of an overhaul. I see there's a bunch of chunk processing stuff (from Jeffos?) that could perhaps be brought used, so maybe I'll tinker with that in my own little branch. I'd like this to be working well and somewhat future-proof if possible.

[Jeff0S]

From jeffos...@gmail.com on April 02, 2013 04:56:49

Hey Phil, sorry I'm not really sure I understand what you said (English..) so my answer might be totally off!

Snapshots do not use my "chunk state tool" (SNM_ChunkParserPatcher).
Well, it is just used it in ..\ObjectState\TrackFX.cpp: I did that to fix snapshots that were not supporting frozen tracks - the SNM_ChunkParserPatcher does.
(BTW, there are useless WDL_TypedBuf <-> WDL_FastString conversions in there: it would be a 1st great optimiz given the massive amount data being dealt with)

Just like Tim, I also see what should be done to fix this issue but I don't have the time to help ATM, sorry.
However, what I can say is that the SNM_ChunkParserPatcher can indeed help to extract and push envelopes back in a fast and safe way. If this is what you meant in your previous post IX (?) and if you have any Qs about it do not hesitate to ping me!
Note: there is a v2 of this tool with more comprehensible interfaces but it is not part of the open source yet.

I think the "tricky" part Tim was thinking about is not this one though, it will be to persist snaps and related envs of other tracks in RPP files. And this stuff should resist frozen tracks, track deletion + undo, etc...
Well, that should be fun :)
Thanks a lot for having a look!

[Jeff0S]

From swstim on April 03, 2013 07:10:30

Jeff understands the complexity here.

It's possible my existing framework for sends/receives is good enough to be able to be extended to work with chunks for the envelope data, but maybe that's wishful thinking.

Maybe I should petition hard for Cockos to get this native because it's very useful, but every new little feature breaks us.