Project setting ReCall ... dazed & confused

[RJHollins]

These past few weeks have really been tough, concerning my real first project. Each step of the way most always have hit some kind of snag When testing began, the Master Trk of Reaper, with its available FX bin started the craziness. Not one to point the finger, but it seems we have hit a definite BUG ... and I suspect its Reaper.

When testing moved to one of the normal multi-trks, we were then able to get out of the starting gate. Now able to Save and Load config files, my plug-in finally was getting the data required to even operate.

My plug-in is a VST MIDI controller designed to speak and control a series of 'other' VST plugs. This connection is working, as we send [CC] controller data, and PRGCHG commands. This has worked nice.

Because of the rather involved routing, the use of a Reaper FXChain is very convenient, and preferred.

My plug-in, serving as the central core of control is working tightly with the [5] VST's it talks too. There is no issue happening there.

BUT ... we have a snag ... and the more I think about it ... the more perplexing it becomes.

It is 'The ReCall' ... after all the tweaking, each of the 5 sections have the PRGCHG in place, all the user control settings [Freq,Gain, BW, etc] done ... we SAVE the song.

When Re-Loading the song, everything loads in ... my VST controller shows all the parameters just as we saved it.
HOWEVER ... the 5 'slaved' VST are not at the proper PRg PATCH.

There was 'issue' mentioned by NuBeat regarding output triggers missing from the FS Pull-Down Menu Selectors that I use in my plug-in. These Pull-downs hold the Patch name and MIDI Patch Number that gets transmitted.

This is highly suspect ...

I've tried an idea or two ... but did not help, and actually cause unwanted results ... so I wait to hopefully hear from NuBeat to help me understand this issue that he spotted.

In the meantime ... I'm pondering the issue of the Re-call. This has landed me into a state of perplexed.

I have a PreSet Manager being used for my first time. We have Reaper, with its FXChain ... when a song is saved ... every detail in that FXChain is also stored.

When the project is reloaded ... I'm wondering .., who's calling the Re-Store shots ! And when and where is this happening ?!?

The 'slaved' VSTs that are 'under the hood' are very heavy on resources ... load times can vary ... so there has always been a question in my mind ... WHEN to the specific Patch data get sent to all these supporting plug-ins ?

If the 'commands' are sent BEFORE the plugin has finished loading ... what happens. Is there some MIDI buffer that holds this till ready ... that'd be nice Or do I need to guess a wait time and trigger a data send ...

What about the PreSet Manager's roll in this. This bad boy seems like a continuous recorder ... it remembers things that I forgot it remember ... had to actually disconnect some internal things that the PM doesn't need to aware of.
But what happens when a project gets reloaded ?

I have an AFTERLoad prim on the LOAD section of the Ruby Marshal that loads my special Config file ... which then stuffs are the arrays which go to all the pull-down menus. This works [except for this important point NuBeat noticed]. Maybe this is the sole culprit .. don't know yet ...

I just know I've confused the heck out of all this recall settings.

Reaper stores every plug-in setting ... it mostly likely has all the status the 'slave' VST were at when saved. same for my controller ... The systems seems to be in conflict.

... I just needed to get these haphazard thoughts/ observation into a thread here ...

dazed and confused ... maybe time to pull some Moody Blues ...

[trogluddite]

First thing I would do is to get hold of a MIDI Monitor plugin - a quick google will find a few decent free ones.
Plonk it after your effect in the plugin chain - save, load, and see what it reads.

If you don't see the data you expect, there are really only two possibilities...
1) Your plugin doesn't send the data - so some kind of bug with the preset loading (either of your making, or an inherent FS problem)
2) The data is sent out, but before other plugins are ready to receive it.

With Reaper, you can sometimes see the message box that tells you about plugin loading - especially for big ones - making it look likely that they are loaded sequentially, and so (2) is a definite possibility.

Here's a few quick ideas to test...

Preset manager has a wireless trigger output called "After Preset Change" - this waits until all preset data is loaded and handled by the preset parameter prim's before firing. Before going the whole hog re-wiring your schematic, I'd do a few tests in a simple schematic that just uses that trigger to send a simple MIDI message - again with a MIDI Monitor to check the output.

Next step - use a simple schematic again, but delay the trigger so there's a short time delay after loading, to see if that makes a difference. Here's a little module that uses a Ruby delay - that will be more accurate than the regular timer primitives - it just sends a single Mod.Wheel controller message after the delay. By experimenting with the delay, you might be able to tell if it is the loading time of the other plugins that causes the problem.

Delayed MIDI Send.fsm

(501 Bytes) Downloaded 911 times

Another idea. Check out your plugin folder for the slowest loading plugins you can find - ones you actually get to see on the Reaper "loading plugin" box. Then try placing them in a project in various different orders. It may be that you can influence the loading order by, say, putting your plugin in a lower or higher track than the 'slave' plugins, and using a MIDI send to pass the data where it's needed.

The information you get from those tests should to point you in the right direction for de-bugging the bigger project.

[RJHollins]

Thanks TROG for helping me to think clear about this.

After a nights rest, and reading your post ... you have given me a direct strategy and some new ideas to explore.

after my jazz gig tonite I'll be back on this !

Thanks my friend !

[RJHollins]

We have made a little headway ...

We seem to be able to load and properly set 3 out of the 5 slave plugins [basically sample libraries].

To be sure that it wasn't a Reaper routing issue ... the working 3 were removed from the chain. Then tested the remaining 2 slaves and they did load and set properly.

We seem to be dealing with 'time to load slave' issue.

This 1st test had a 4 sec delay. I've now doubled it to 8 sec to test if that makes a difference.

The problem ... once again ... I have flawless recall on my rig --- all 5 slaves load and configure properly with their correct patch. The issue is on B-Testers machine Therefore I can't really test if I'm even delaying the right spot NOR do I know how DAW's handle this ... Is the DAW waiting till the plugin is ready [after the delay] before loading the next ... maybe ... i hope to learn more after the 8 sec delay test.

I did look at the PreSet Manager, of which I'm using one of the custom ones called "Ernst's Hot Preset Manager" [it offered a Copy/ Paste function that seemed very useful] .... Searching around inside of the PM, I did locate a WIRELESS - 'After Preset Change' coming off the 'MANAGER' prim. Is this the Wireless that should be considered to delay ???

No where did I see an AFTERLOAD prim in this PM

Thanks for any additional guidance !

[trogluddite]

'After Preset Change' coming off the 'MANAGER' prim

That's the one I was on about before. But having thought about it some more, I'm not sure if it will help - will need some small experiments to see if loading a DAW project counts as a "preset change"; could be that the host just updates each parameter individually from the settings stored in the project file.

The issue is on B-Testers machine

Hmm, those 64-bit systems do seem rather troublesome. I'm beginning to wonder if the problem is with Reaper's 32bit->64bit "bridging". Might be worth searching the Reaper forums to see if other 32-bit (i.e. non-FS) plugins are having similar issues.

Big kudos to you for your persistence with this, and all your detailed reports. I don't know any folks using Win7/8 for music making except for the guys here - I would never have even though about the issue if it weren't for your posts.

[RJHollins]

That's the one I was on about before. But having thought about it some more, I'm not sure if it will help - will need some small experiments to see if loading a DAW project counts as a "preset change"; could be that the host just updates each parameter individually from the settings stored in the project file.

I tried testing the 'After Preset Change' within FS, with a 'trigger counter' tapped in. Saved it, then reloaded schematic .... no trigger. So I stayed with the notion of putting an 'AFTER LOAD' prim into a Delay that triggers the LOAD section to the Marshal routine. I've up'd the delay time from 4 to 8 sec for testing.

***** NEWS ALERT **** Email just in !!! ******

From my Beta-tester:

... As the fx chain loaded, I was so disappointed to see the wrong presets getting loaded....until one by one, they all re-set in a few seconds with the right presets!! So I re-saved and reloaded a few times and everything loaded right. I even changed the settings, and those reloaded right too.

So now what? It seems to be WORKING!!!

.... would somebody please pinch me ...

[RJHollins]

What an education this has been ...

There have been so many head scratching surprises during the testing of my project. What had worked so well on my computer was sometimes not the case during outside beta-testing.

Beside the strange issue of Reaper's 'Master Track' refusing to load any kind of file [including the standard PreSet Manager text file .... that is until the VST was first inserted on a standard track Still don't know what's up with that

But what I now know ...

Since my VST supplies all the MIDI data for a series of other VST plugins, I have found that SOME computers need extra time to first load in the 'slave' plugins before my controller issues the MIDI patches and settings. [the great mystery is why my, less than stellar. computer requires NO delay in sending this data]

Since the addition of the Marshal routine [which is maybe the speed contributor], I had to add on 8 sec delay to the AUTOLOAD prim trigger into the Marshal routine. This is not a big deal ... but it raises an important concern !

Since I'd never be able to anticipate what 'delay' might be needed [based on somebody else computer], I'm looking to add a special CONFIG file that stores a single piece of data, that being an INTEGER value that would be saved on the VST folder. When the VST first loads, it would need to grab this file and immediately load this into the delay setting that would be used to trigger the main config file.

I've not tested this idea as yet ... so I'm guessing as to how I should manage this dynamic setting.

My thought would be the AUTOLOAD prim would grab this 'delay time' file, read it and then send to the trigger delay module. I'm thinking that I could generate a 'file done' trigger that would start the delay module, which would wait the loaded time before kicking a trigger into the Marshal load trigger.

Has anybody ever had to do something like this ?

Does my 'plan' sound reliable ???

It seems rather straightforward ... but then, so were some other things

What cha think ?!?

[Nubeat7]

When the VST first loads, it would need to grab this file and immediately load this into the delay setting that would be used to trigger the main config file.

I've not tested this idea as yet ... so I'm guessing as to how I should manage this dynamic setting.

My thought would be the AUTOLOAD prim would grab this 'delay time' file, read it and then send to the trigger delay module. I'm thinking that I could generate a 'file done' trigger that would start the delay module, which would wait the loaded time before kicking a trigger into the Marshal load trigger.

isnt this a fixed delay time, so why saving it when it doesnt change?

anyway what i would recommend is a manual trigger to load the last settings, a fixed delay to wait that other stuff is loaded can always make troubles when things where not loaded completely before, the loading time of a project could always be different depending on various things you have no control..(slow computers, huge projects,..)
as long you get no information from the host, that the project is loaded completely, it is just luck to dont trigger to early, on the other hand it makes no sense to wait 8 seconds when the project is loaded in 3seconds..

i think a button, something like"load project settings" would be the savest way to do this.

anyway you could load the config file in your plugin and then just fire it manual

[RJHollins]

isnt this a fixed delay time, so why saving it when it doesnt change?

anyway what i would recommend is a manual trigger to load the last settings, a fixed delay to wait that other stuff is loaded can always make troubles when things where not loaded completely before, the loading time of a project could always be different depending on various things you have no control..(slow computers, huge projects,..)
as long you get no information from the host, that the project is loaded completely, it is just luck to dont trigger to early, on the other hand it makes no sense to wait 8 seconds when the project is loaded in 3seconds..

i think a button, something like"load project settings" would be the savest way to do this.

anyway you could load the config file in your plugin and then just fire it manual

Hi NuBeat,

This 'delay time' thing looks like it may be dependent on the Users system. I was actually surprised that this was to be an issue that needed to be considered. Of course, as I thought more on this, the 'slave' VSTs do take some time to load [they are basically samplers]. I had not really considered how this was going to be handled within a DAW. The main confusion for me was NO delay was required. It wasn't till beta-testing that this was identified as the culprit.

I did consider a manual trigger for configuring ... but I wanted to really see if an 'automatic' would work.

I've put together all the pieces to do this. I have tested this numerous times within FS and in real world DAW [VST].

At least on MY system ... this User definable config delay is working as planned. I have sent out the beta for testing, and waiting to hear back on this function.

I've also implemented the 'Dual-function' slider that you created. Putting this into my project still had a challenge to address. Thankfully you had included an ARRAY output of the available 'states'. Using some PRIM trickery, I was able to implement an important feature my controller needs to perform.
Once I worked out the additional logic, I was able to maintain all user controls when a patch change was made. This allows full A/B comparison. It's now working with the dual-function sliders too.

A side benefit ... not having to add more GUI stuff to take up space on the interface. My project had 5 control sliders already ... this dual-slider module meant that I didn't have to have 10 sliders showing. Not practical in other cases for sure, but for this project needs ... it seems ideal .... thanks for that !!!

Waiting on test results at this moment. I'll have a better sense of where things are at when I get a report back.

If this 'auto delay' concept fails ... I may have to change things to option the choice of 'Manual or Auto', as You may be most correct in what you warn. But this is what's crazy about this ... One of my very early projects involved 13 of these slave VST's to control. This was never an issue [on my computer]. Of course, those earlier projects were also done with an earlier version of FS. I don't really know if that would be ANY issue ... I just don't know.

This Marshal routine IS much faster than what I had to do before [lots of array splitting after reloading]. This current project has become much more efficient in general as I've learned along the way. Just my awareness of counting triggers has forced me to manage that aspect much closer ... so it may be the culmination of things. But I still don't need a delay on my system. But I've left it at 4 Secs for now ... I still have to wait for all the slave VST's to load anyway It will be interesting to see how this plays out, that's for sure. We'll see


The remaining question is the PreSet Manager. I do not see anywhere when it loads and transmits IT'S data ?!?!?
I would have thought the PM was critically involved in not only re-setting my plugin but when I could update all the connected units.

I do not see an AUTOLOAD trigger anywhere inside the PM module I use. Any info on this would help so I could try and understand this better.

Thanks again !!!!!

[RJHollins]

News Update ....

Well folks, its' been a long and winding road ... but it appears from the latest B-Test results that we have achieved a working project on all systems tested.

The user defined 'delay config' routine is working as planned, and is allowing each computer to fully load in all the supporting cast before my controller issues setup parameters.

2nd ... the design and implementation of the 'Dual-function' sliders are correctly doing their job. I've added an additional display that shows the 'in-active' value. This display switches info based on which mode is active. I did this to prevent, 'I wonder what that other value is at'. So now there is no need to switch over to confirm, as there is constant visual feedback.

There is some internal clean-up that I'll be doing, as I've suggested that we continue testing/ playing. I've been playing with this controller on a test mastering session throughout ... the work-flow and ergonomics have been taken to a whole new level.

Finally, as a Master Engineer, I can now focus on the primary mission .... listening.