LBX Stripper - create custom channel strips

[dasombre]

thanks for all the updates Leon!
Massive stuff happening here

[Spacemen Tree]

Originally Posted by lb0

Hi Spacemen Tree, (is that an homage to Spacemen 3?? - big fan here)

Hi man. Sure is! Big fan as well.

Originally Posted by lb0

Will look into all the bugs. Now embarrassed - can you send me the version of the script you were using. My version numbering is non-existent (my bad) - and have added lots of code recently and published several updates - so the line numbers no longer correlate to the errors you've reported :/

So I'll PM you my email - and if you can just post the Lua script you've been using I'll take a look at the bugs.

So as I am here, hope you don't find it a problem, I attached the script version I have, from which I reported the bugs. Date is 14/12/2016.

Originally Posted by lb0

EDIT: The cycle window will only close if you have 'can mousewheel on knob' option in settings unticked. I'll see what I can do about that - will prob. have to disable mousewheeling the surface if cycle edit window open.

Sorry for adding to your todo list. No biggie for me, but since I came across it by accident I just thought I'd bring it to your attention.

Originally Posted by lb0

It is not possible to save a strip with track templates - but it is possible to save all current tracks (except master) as a Strip Set. This will save all the current tracks and strip layouts for those tracks - ready for recall into any project. You then use the Merge Set (or load set depending on whether you want it to overwrite the current setup) - to load the set in.

So basically - to use a bit like track templates - ensure you only have the tracks existing that you want to be part of the set (at the moment it will only save all tracks) - open ... menu and select Save Set. This will save all the data for the current strips/tracks etc. When loading - the tracks will load exactly as they were saved - fx and all.

Awesome!!!! Going to try it asap. This is great stuff man!

Originally Posted by lb0

Ok my short break over - back to family and kids - will reply more later...

Yeah, don't overdose on scripting I know it's addictive but there's life beyond the screen heh?

Originally Posted by lb0

Strips will be saved in your project template if you add them to the project before saving as template.

I'll make a template just for testing this out. I'm currently redefining my workflow so I'll test this out too. Thanks.

Originally Posted by lb0

I'm not sure what you mean by uncouple strips from tracks - but it doesn't sound like something that's currently possible. Unless you mean - can you add controls from other tracks in a particular strip - in which case yes you can add any control to any strip.

Oh, I just meant a sort of master strips not tied to track selection, but the Save Set feature is probably going to do it nicely.
Keep it coming!

[Arthur McArthur]

Is there a way to make the strips follow duplicated tracks? Right now it doubles the plugins and loses the settings.

Can the stripper retain it's settings on the newly duplicated track and not load the plugins twice?

[lb0]

Originally Posted by Arthur McArthur

Is there a way to make the strips follow duplicated tracks? Right now it doubles the plugins and loses the settings.

Can the stripper retain it's settings on the newly duplicated track and not load the plugins twice?

At the moment no. I'll have to think about best way of achieving that. Probably would need to add duplicate track option within the script.

[lb0]

Originally Posted by Spacemen Tree

Hi!


* got a C:\Program Files\REAPER (x64)\Scripts\LBX\LBX Stripper.lua:2270: attempt to index a nil value (field '?')
while adding to reaper a previously saved track template to see if LBX Stripper would recall parameters.

Hi Spacemen,

I'm trying to repeat this error - but so far have failed to reproduce. I've tried inserting various track templates whilst Stripper is open - but only get the expected behaviour.

However - I have tried to mitigate the problem and added extra table element checks for the lines that caused the issue - so hopefully this will fix it.

I have fixed the cycle option error - this only occurred when you clicked in the states list (when it's empty) and then tried to move the cycle knob value selector.

I have also made a few more fixes for crashes and problems found when trying to fix the other errors!!

[kawa_]

Great!!

[Arthur McArthur]

Originally Posted by lb0

At the moment no. I'll have to think about best way of achieving that. Probably would need to add duplicate track option within the script.

Not sure if it's possible but would be great to have it function with this script "duplicate tracks or items" (imo much better functionality than reaper's default duplicate):




function duplicate()
(
Undo_BeginBlock2(0);
GetCursorContext() === 0 ? (
Main_OnCommand(40062, 0); // duplicate tracks
Undo_EndBlock2(0, "Track : Duplicate Tracks", -1);
) : (
start = 0;
end = 0;
GetSet_LoopTimeRange2(0, 0, 0, start, end, 0);
start === end ? (
Main_OnCommand(41295, 0); // duplicate items
Undo_EndBlock2(0, "Item : Duplicate Items", -1);
) : (
Main_OnCommand(41296, 0); // duplicate selected area of items
Undo_EndBlock2(0, "Item: Duplicate Selected Area of Items", -1);
);
);
);

duplicate();

[lb0]

Originally Posted by Arthur McArthur

Not sure if it's possible but would be great to have it function with this script "duplicate tracks or items" (imo much better functionality than reaper's default duplicate):




function duplicate()
(
Undo_BeginBlock2(0);
GetCursorContext() === 0 ? (
Main_OnCommand(40062, 0); // duplicate tracks
Undo_EndBlock2(0, "Track : Duplicate Tracks", -1);
) : (
start = 0;
end = 0;
GetSet_LoopTimeRange2(0, 0, 0, start, end, 0);
start === end ? (
Main_OnCommand(41295, 0); // duplicate items
Undo_EndBlock2(0, "Item : Duplicate Items", -1);
) : (
Main_OnCommand(41296, 0); // duplicate selected area of items
Undo_EndBlock2(0, "Item: Duplicate Selected Area of Items", -1);
);
);
);

duplicate();

I'm not totally au fait with that language syntax - I get the duplicate track bit - and the items - but then it suggests selected area of items. What do the : mean?

Can you describe exactly what this does? Duplicate tracks OR items? How does it choose what it's duplicating? I don't quite get its functionality and how it differs to normal reaper track duplicate.

Generally - I'm duplicating tracks using the track chunk - as it gives me good control over identifying the new fx and replacing guids etc. - but if I can convert this script to Lua (by understanding the exact functionality) - it might be worth a go.

EDIT - I guess the start===end bit checks whether there is a loop region. So it will duplicate the tracks - but if there is a loop region - it will only copy those items within the loop region? otherwise - all items are duplicated? If so - I like the idea.

[Arthur McArthur]

Originally Posted by lb0

I'm not totally au fait with that language syntax - I get the duplicate track bit - and the items - but then it suggests selected area of items. What do the : mean?

Can you describe exactly what this does? Duplicate tracks OR items? How does it choose what it's duplicating? I don't quite get its functionality and how it differs to normal reaper track duplicate.

Generally - I'm duplicating tracks using the track chunk - as it gives me good control over identifying the new fx and replacing guids etc. - but if I can convert this script to Lua (by understanding the exact functionality) - it might be worth a go.

EDIT - I guess the start===end bit checks whether there is a loop region. So it will duplicate the tracks - but if there is a loop region - it will only copy those items within the loop region? otherwise - all items are duplicated? If so - I like the idea.

I didn't write the script (I forget who did I found it on the forum, but kodus to them!) but yeah you have it correct. If a track was the last thing selected it duplicates the track. If an item was the last thing selected it duplicates the item. If there is a time selection it duplicates the selected items (the parts within the time selection) and the time selection itself-. Really useful script

[lb0]

Added keyboard shortcuts:

l = live mode
f = fx param edit mode
t = track param edit mode
g = gfx edit mode
s = strip edit mode
,/< = previous track
./> = next track
-/_ = previous page
=/+ = next page

Ctrl + D = dock / undock
Ctrl + S = toggle snapshot window
Ctrl + Shift + S = Toggle sidebar
Ctrl + L = Lock surface

That's it at the moment. Plan to add more though...

[dasombre]

wooooow, a million thanks for the keyboard shortcuts
my personal christmas-week-highlight

[lb0]

Originally Posted by dasombre

wooooow, a million thanks for the keyboard shortcuts
my personal christmas-week-highlight

haha - well I very much hope something comes along to beat this highlight

Let me know if you think of any more... I'm already thinking of things like metalite shortcut, and a few others...

And when I've got round to adding simple copy/paste functionality (for copying controls between strips) - that will be included too.

[lb0]

Oops - it's Ctrl-Shift+S to toggle sidebar - meant it to be just Shift+S - but nevermind. This works ok too!! will edit previous list

Oh - and the dock one appears glitchy... was fine in my testing earlier. EDIT: FIXED!

EDIT: Also fixed using arrow keys to move controls as some keypresses were swallowed up with the new keyboard shortcuts - should be fine in latest version

[Arthur McArthur]

Originally Posted by lb0

Oops - it's Ctrl-Shift+S to toggle sidebar - meant it to be just Shift+S - but nevermind. This works ok too!! will edit previous list

Oh - and the dock one appears glitchy... was fine in my testing earlier. EDIT: FIXED!

EDIT: Also fixed using arrow keys to move controls as some keypresses were swallowed up with the new keyboard shortcuts - should be fine in latest version

The shortcuts are great for building strips but it would be great to have an option to pass through all shortcuts. For example my stripper usually stays docked and I want Control-S to always save the project and not open Snapshots (except when I'm building a strip), and spacebar to always transport play, etc.

I'm having problems getting the stripper to react to screensets. It doesn't seem to respond to "SWS: Hide Dockers." It would be great to have a "Hide Stripper" dedicated action.

Also I'm having a lot of problems running many strips at once:

My default strip starts taking longer and longer to add as I put it on more tracks. It goes from less than a second on the first strip, to about 10 seconds by the time I get to 60 strips. (Mind you my strips have about 30 fx currently, but they're all offline)

Opening the stripper in this 60 track session takes 20+ seconds. Closing the stripper leads to a crash

[lb0]

Originally Posted by Arthur McArthur

The shortcuts are great for building strips but it would be great to have an option to pass through all shortcuts. For example my stripper usually stays docked and I want Control-S to always save the project and not open Snapshots (except when I'm building a strip), and spacebar to always transport play, etc.

I'm having problems getting the stripper to react to screensets. It doesn't seem to respond to "SWS: Hide Dockers." It would be great to have a "Hide Stripper" dedicated action.

Also I'm having a lot of problems running many strips at once:

My default strip starts taking longer and longer to add as I put it on more tracks. It goes from less than a second on the first strip, to about 10 seconds by the time I get to 60 strips. (Mind you my strips have about 30 fx currently, but they're all offline)

Opening the stripper in this 60 track session takes 20+ seconds. Closing the stripper leads to a crash

What crash does it give you?

Not 100% sure why it's taking so long to load a default strip.

Opening stripper is likely to take some time in your case though - there is a lot of data to read in. Of course I'll see if this can be improved - but cannot guarantee it can be. Do you also have lots of snapshots in each strip?

The thing is - at the moment - each strip is treated differently - has entirely it's own data. The only thing that is shared is the images for backgrounds and controls. Everything else has the potential to be unique depending on the track it's on - so requires its own data.

Maybe something for the future is a way of determining sharing of data across tracks... not sure how this would or could work yet.

Certainly - I can change Ctrl + S to save project - makes sense.

Will look into the screensets issue too - not something I've tested.

Any chance you can post me you project file? (don't need any audio items - just the stripper setups/gfx/strips etc, + your track layout - .rpp file). Will see how slow it is and see if I can come up with anything to improve this.

[Arthur McArthur]

Originally Posted by lb0

What crash does it give you?

It freezes and I have to end process, no specific error code given.

Originally Posted by lb0

Opening stripper is likely to take some time in your case though - there is a lot of data to read in. Of course I'll see if this can be improved - but cannot guarantee it can be. Do you also have lots of snapshots in each strip?

Probably 30-40 snapshots per script.

Originally Posted by lb0

Certainly - I can change Ctrl + S to save project - makes sense.

Great- any way to make it pass through all keyboard commands as an option? If not, other useful ones would be space for play, ctrl-R for record...

Originally Posted by lb0

Any chance you can post me you project file? (don't need any audio items - just the stripper setups/gfx/strips etc, + your track layout - .rpp file). Will see how slow it is and see if I can come up with anything to improve this.

Sending to you now!

[NextLevel]

Awesome update, I love that you were able to add kbd shortcuts. yay!
Ultimately it would be best if there was maybe an .ini file or a user config area within the script where users could assign which keys to use as shortcuts.

Cheers

[lb0]

Originally Posted by NextLevel

Awesome update, I love that you were able to add kbd shortcuts. yay!
Ultimately it would be best if there was maybe an .ini file or a user config area within the script where users could assign which keys to use as shortcuts.

Cheers

I agree - people have different preferences - so will look into when I get some time

[dasombre]

the shortcuts really help a lot when creating strips. Thanks again for this!
one thing I noticed though: in the previous version (just before the version with the shortcuts), I could close LBX with ESC, and I could start/stop the playback with the spacebar.
Now this is not possible anymore. Could you bring this back maybe? It was very useful I think

[lb0]

Originally Posted by dasombre

the shortcuts really help a lot when creating strips. Thanks again for this!
one thing I noticed though: in the previous version (just before the version with the shortcuts), I could close LBX with ESC, and I could start/stop the playback with the spacebar.
Now this is not possible anymore. Could you bring this back maybe? It was very useful I think

yeah - sorry about that - they will be back in the next release.

I'm currently reworking how all the data is saved (and loaded) - as large projects with lots of strips got exponentially slower to load and save (especially save) I guess due to all the automatic sorting and searching through keys in the rpp file. One project I had been testing for Arthur took literally 10 minutes to save the data (only had 60 tracks - but large strip on each track). So I've had to come up with something else.

Well - I've mostly succeeded . I'm now saving each strip individually in a new folder (each project has its own folder within this data folder). This has reduced load times (which was about 20 seconds for that project) to around 8 seconds - but the saving has gone down from 10 minutes - to 2.5 seconds haha - clearly a large rpp file was not the place to be putting all this data due to all the sorting which I don't need as I load it all into memory anyway!

But - I say partially - only because in order to maintain the ability to load up old versions of projects - I need to create new files each time the script data is saved. This means that you would eventually end up with a lot of redundant files in the project data folder. So I'll need to come up with some sort of housekeeping methods. But it all works - just eats up storage a bit more.

obviously this means you would need to share these files too in order to give the project to someone else. i still need to add code to identify projects that need to load using the old method before i can release this.

hope this is ok with everybody. It shouldn't really affect anyone except for the data storage.

[dasombre]

thanks for the hint regarding the upcoming save procedure.
I personally have no problem with extra save files for LBX as long as I can maybe put them into my project folder and somehow can keep track of all those.

But I'm all for performance and reliability as I also want to use LBX regularly in bigger projects too.

Thank you for bringing back ESC and spacebar

[lb0]

Originally Posted by dasombre

thanks for the hint regarding the upcoming save procedure.
I personally have no problem with extra save files for LBX as long as I can maybe put them into my project folder and somehow can keep track of all those.

But I'm all for performance and reliability as I also want to use LBX regularly in bigger projects too.

Thank you for bringing back ESC and spacebar

I'll allow you to choose save path for the data files. I can make it default to the project folder rather than the resources folder if people wish - I think that may be better as the project folder is more likely to be on a regularly backed up drive - and have more space on it than the resources folder which will I guess for many people be on the system drive.

I have space and escape working again - simple fix - but as I said - won't be live until I finish the updates to the save/load system. Won't be long though - hoping for later tonight but does depend on my free time... Xmas is coming and other things are (sadly ?? - bah humbug me!!) taking priority

You can fix it yourself for the moment by commenting out one line -
line 15017:

local char = gfx.getchar()

change to

--local char = gfx.getchar()

or delete the line altogether (the char variable is read at the top of the run function now)

[timbralzoom]

is save path for "data files" covers controls & graphics?

[lb0]

Originally Posted by timbralzoom

is save path for "data files" covers controls & graphics?

not in this context. But if you would rather those were stored elsewhere too - I can make that adjustable also.

[timbralzoom]

Originally Posted by lb0

not in this context. But if you would rather those were stored elsewhere too - I can make that adjustable also.

ah! ok,
personally i have no problem with the current...
i thought it was kind a copy/collect used controls & graphics while saving script to project folder.

[lb0]

Originally Posted by timbralzoom

ah! ok,
personally i have no problem with the current...
i thought it was kind a copy/collect used controls & graphics while saving script to project folder.

Ah no - but that's something I've thought might be useful for sharing stuff in the future - so will add at some point...

[timbralzoom]

Originally Posted by lb0

Ah no - but that's something I've thought might be useful for sharing stuff in the future - so will add at some point...

+1 for might be useful, nothing urgent!

[dasombre]

thank you for the tip with ESC and the code, but as I know me I will just sit out the time for the update, no problem here so far thx a lot!
Also sounds good what you have planned for saving the data for me (a folder inside the project folder is a good way, helps organize things, better than ressource folder which is on my system-ssd, at lest I prefer the project-folder method).

Enjoy your family time MR.

[RJHollins]

?question?

Saving destination.

I've no idea how large a 'typical' STRIP file might be ... PLUS, the ability/option to share STRIPs opens possibilities ... but the question:

Having a 'central file' location [independent of any project] to pull in a strip, without having to track it down in a particular project would be preferred.

I think the idea of consolidating a STRIP to a single FOLDER is a great, organizational goal.

Maybe I'm not following the workflow concept being considered ?

[lb0]

Originally Posted by RJHollins

?question?

Saving destination.

I've no idea how large a 'typical' STRIP file might be ... PLUS, the ability/option to share STRIPs opens possibilities ... but the question:

Having a 'central file' location [independent of any project] to pull in a strip, without having to track it down in a particular project would be preferred.

I think the idea of consolidating a STRIP to a single FOLDER is a great, organizational goal.

Maybe I'm not following the workflow concept being considered ?

Well - I'm holding off releasing just for the moment as I really want to get the file management sorted first. It all works fine - but on that big project - each time it was saved (within the script - not the project - so you might have one project files - but if you save the strip 10 times - you get 10 copies of the script data) - 80Mb of data was produced.

This really concerns me - because if you have a single project file - you could easily get multiple script data files adding up to Gigabytes of storage - but actually - only the latest 80Mb worth is actually any use. This is a massive waste of resources.

But it's hard to know when I can delete the files - they should only be deleted if they are not 'attached' to a project file. The only way to find this out is to scan all the project files (.rpp) in a folder - to discover which ones link to which script files - or getting you to choose the rpp files you want to keep (or go back to) - this would allow me to delete all the redundant files safely.

I think scanning the rpp files would work - but again - how many rpp files might end up in a folder. If like me - every rpp file is in the reaper media folder - that could be thousands of rpp files to check through. Probably wouldn't take long to be fair - but something I think you would need to instigate yourselves once in a while.

The main issue here is that my script data needs always saving before the rpp file gets saved. This means I cannot know for sure what project my script data belongs to (without scanning them all). You could create a new rpp project - add some strips etc. - then save the script data several times before even the rpp file has been saved and the project been given a name. Therefore - there is no obvious name I can use to relate my script data to a project. For this reason - I have a project id - which identifies the project. This is stored in the rpp file - alongside all the script data filenames - and is how I can identify which folder the script data is stored in.

Anyway - bottom line is the same one I've harked on about before - because I cannot intercept Reaper's save routine to know when the rpp file is being saved - my script always has to perform it's save function separately.

Anyway - I'm going to try out a few things later and try to come up with a seamless way of data file management - that will allow you to remove unneeded data without any fuss.

[RJHollins]

hmmm .... this new idea is not sounding so good for my work flow.

Again ... not certain I'm following this correctly ... anyway.

For me ... I have so many REAPER projects. They are placed among 7 internal HardDrives. I couldn't even tell you how many RPP files there are.

2. What happens when we start creating a STRIP that we want to save, and edit later. There is no particular RPP project maybe at the time ... but want to prep a strip for 'some' project later. Plus ... the first version of the STRIP may very well be just the start. updates/ changes/ mods could follow.

I think a repository location for all STRIPS [in separate folders] would make sense. Maybe make it a user defined location for those that need to manage main drive, but as default, use the REAPER location like you have.

Just thoughts here. Maybe I'll understand your plan later? :|

[lb0]

Originally Posted by RJHollins

hmmm .... this new idea is not sounding so good for my work flow.

Again ... not certain I'm following this correctly ... anyway.

For me ... I have so many REAPER projects. They are placed among 7 internal HardDrives. I couldn't even tell you how many RPP files there are.

2. What happens when we start creating a STRIP that we want to save, and edit later. There is no particular RPP project maybe at the time ... but want to prep a strip for 'some' project later. Plus ... the first version of the STRIP may very well be just the start. updates/ changes/ mods could follow.

I think a repository location for all STRIPS [in separate folders] would make sense. Maybe make it a user defined location for those that need to manage main drive, but as default, use the REAPER location like you have.

Just thoughts here. Maybe I'll understand your plan later? :|

No - i think you've not quite grasped what i mean by script data.

This is the data that is normally stored in a rpp file. Not the .strip or .stripset files. So if you create a strip - save it as .strip file (SAVE STRIP) - this works as you expect - nothing changes. The .strip files have not been touched or changed in any way.

This is purely about the data stored in a rpp file.

So if you create a rpp file - add lbx strip data (drag in params/strips etc) - this so far has been stored in the rpp file (all the control position data/parmeter info, snapshots etc.)

Now all I'm proposing is moving this data into external files - stored wherever. The only problem doing so is managing these files.

If I was to constantly overwrite the same data files. Say you had ProjectA and you save all the data. This creates script files for ProjectA. Now if we save this same project as new project ProjectA1 - I cannot save the script files over the old ones as this would also change them for ProjectA. So each time my script saves data - It creates a new set - because my script doesn't know whether you've created a new version of the project or not - so for safety - every save will create new copy of script data. Now I just need a way of managing the redundant files which would probably involve checking all the rpp files in the save destination folder.

I guess if you store the same rpp files in multiple places - then you would also need to back up your script data to multiple places.

EDIT:

Maybe the neatest solution would be for my script to 'replace' the main project save function altogether. If I could ensure you use the save function within stripper to save the project (obviously only applicable if stripper has been opened) - then I could check if you are using SaveAs or Save type of save (Ctrl-S would emulate Save function) and overwrite/create files appropriately.

hmm....

[RJHollins]

Ahhh ... Thanks for explaining lB0. Now I see the distinction.

[lb0]

Originally Posted by RJHollins

Ahhh ... Thanks for explaining lB0. Now I see the distinction.

Sorry - I'm rubbish at explaining somethings - especially when I have kids jumping all around me

Anyway - I think I'm close to working out a way to find out when the project is saved - and therefore save the script data when this is done. This is possibly the neatest solution - and will mean the script does not need to save any data at all until you save the project

Only time this won't work - is when you EDIT: quit reaper - and use the save on close message to save stuff... As long as you use Ctrl-S or File>Save etc - then it will save the data and resave the project with the relevant data linked to.

This way should also avoid filling up the script project data folder with loads and loads of redundant files...

Still - it's all theory - but initial tests are very promising...

[lb0]

I think I've nearly nailed the saving

It even feels more robust than before... and no producing lots of redundant data

Need a little more time to test and ensure nothing weird goes on - but happy so far

[RJHollins]

We like it when You're happy

[lb0]

Originally Posted by RJHollins

We like it when You're happy

Yep - pretty happy. A little more testing tomorrow (time permitting) and it'll be ready.

The sad thing is - all this work - and you'll probably not really notice much difference... But sometimes that's for the best

The main things you'll need to know are:

1. Pressing the save button on the script gui will now save the data AND the reaper project file (so as if you were hitting Ctrl+S in reaper (but hitting Ctrl+S in reaper before these changes did not save the latest script data - you had to manually save the data or activate one of the save trigger points like closing the script window/hitting save/or switching out of edit mode - no need to worry about this anymore - save the project - the data gets saved too ).

2. Ctrl+S when the script has the focus will now save the script data and the project also. This is probably expected behaviour really.

2.1. Closing the script window will also save the script data and the rpp project file. This I would prefer not to have to happen - but it is necesary in order to not lose the script data (aa the data is no longer stored within the project file it would be lost unless it was saved here)

3. Depending on your preferences - the scripts data will now be stored in files within either the resources folder - or in a folder alongside the rpp file.

4. Quitting reaper and relying on the save prompt as reaper quits - WILL NOT save the script data - in this case any changes to the script will be lost - this is because reaper doesn't allow the script atexit code to run before it quits. I haven't found a way round this case. So get into the habit of hitting Ctrl+S or saveing the rpp project file manually before quitting reaper!

5. If you wish to share the rpp file - you'll also need to share the projects script data folder.

6. You should always have the maximum undo memory use preference >0 - otherwise my script cannot tell when you are saving the project when my script doesn't have the focus - and the only way you'll be able to save the script data is from within the script itself (hitting save button).

that's all I can think of at the moment. But it's working nicely for me and the benefits from these minor workflow things you need to be aware of will be of huge benefit if you work on big projects with 100+ tracks and loads of plugins on each track (where the save time got incomprehensibly silly!). It still might take 10+ seconds to start the script (there's a lot of data being loaded) - but save times should be around the <5 second mark. Smaller projects you won't even notice any startup/shutdown times .

My tests had a 75 track project where each track had 30 odd plugins (mostly loaded offline) - and 230+ controls on each strip + 50 odd snapshots per track too. Load time was around the 8 second mark. Save time about 2-3 seconds. This I'm very happy with - compared to the 10+ minutes it took to save using the old method.

[timbralzoom]

^^ That's what i call fantastic news!!

[NextLevel]

lb0,

Regarding this, ↓↓↓

2.1. Closing the script window will also save the script data and the rpp project file. This I would prefer not to have to happen - but it is necesary in order to not lose the script data (aa the data is no longer stored within the project file it would be lost unless it was saved here)

I have concerns over this, is there anyway this can be made optional?
I would rather lose script data then accidently overwriting a project.

Cheers & Happy Holidays

[RJHollins]

I guess ... once we get to test and actually see how this all works ... I'll hold back on concerns ... which are a couple.

As to load times ... I use NEBULA ... there are libraries that already have some loading times [but well worth the wait].

Well, can't totally hold back.

As long as we can create a STRIP, and pull it into any project when needed. Great.

Also brings up another hopeful feature we talked about. The ability to have a STRIP within an ITEM [not just a TRACK]. Something down the road you said possible [?] ... just wanted to fling that out there with all this new data saving re-work.

and the request just keep-a-commin'