MIDI data conundrum - FS, 3rd party plugs, & DAW

[RJHollins]

I have a situation that has me stumped. I'm either programming this project wrong, or not thinking correctly about the workings. Here's the issue:

Making a MIDI plugin with FS. Generally not that difficult ... ok.

Through MIDI, I want to have my plugin talk to another plugin [3rd party]. Again, fairly straight-forward.

Of course, my plugin would have the usual knobs, buttons, sliders ... so the 'PRESET MANAGER' handles the storing and recalling in the DAW data file.

The 3rd party plugin ALSO has parameters, and has ITS settings stored in the DAW fill as well.

The conundrum.

When my plugin loads, it gets all its parameters loaded and set, and sends this out the MIDI. However, the 3rd party-plug is already getting its data settings loaded back from the DAW.

I have [UN-necessary] 'duplication' of data, in a sense. It also cause issues like patch presets of the 3rd party being loaded twice [once from the DAW, and the 2nd time from my plugin]. Not good.

Obviously, I need to keep the MIDI channels open for normal use ... but, how do I stop/prevent this double data going on ?? I can't really post an example about this ... I'm trying to get my thinking/strategy proper.

I have experiment with several ideas ... one being, blocking the MIDI data stream from my plugin ... minor success, but this and other attempts seem like a band-aid approach, and don't get to the actual issue.

I could really use some insight to re-think this situation.

Thanks everyone

[Spogg]

What's the actual manifestation of the issue?
From your text it seems this is only when you initialise either by opening the DAW or loading a new song. Does the 3rd party plugin end up with wrong parameters? Does the whole process take too long for comfort?
I'm wondering if it would be really bothersome to a user you see.

Cheers

Spogg

[RJHollins]

Hi Spogg.

Yes, it is the first loading up from DAW.

I am controlling very large 'sample' libraries. At least 8 at a time. Would like to have 16 [1 for each MIDI channel].

With the data flying around doing initial load, it locks up the DAW [Reaper]. If I block the MIDI output, everything loads fine. Each unit [including mine] is set properly.

During use, my plugin controls everything fine as expected. It's that first initial loadup that causes a freeze of Reaper when it tries to load the very last file [it's project UNDO file]. not good.

[Spogg]

I personally can't offer a suggestion but I've found Cockos support very helpful.

Is it worth kinda trying to delay your plugin's initial actions? I'm thinking of a timed retriggering of the Clear Audio Prim started by an After load Prim.

As I type this I have to confess to having had a couple of glasses of wine so I may regret that suggestion tomorrow!

Hope you can get a solution.

Cheers

Spogg

[RJHollins]

Hi Spogg ... I've tried several 'ideas' ... most made me want to start drinkin'

I had a User defined delay timer that was looking to give time to all the samplers to load in [these can be very larger libraries]. This idea, like few others, were like trying to stomp out fires AFTER they had already started.

I've been dealing with this for quite some time. Fortunately REAPER allows loading a project with all FX taken OFFLINE. Then I could manually activate and then continue work. A real pain ... but it worked.

Last night, and a bit today, I've put together a little piece of circuit that just 'kills' the MIDI output [my plugin only generates MIDI data, the audio is only a pass-through.

With the MIDI output OFF ... everything loads up just fine, and the 8 support samplers all have their correct patches and settings [as expected from the DAW].

I've also used a idea posted earlier using HASH technique in RUBY to correlate Knob values to actual sampler values [128 MIDI points]. I had to add a 'TICK-5' to activate the HASH so that the numeric data transfered to the display at start-up initialization. [Sometimes thing work in FlowStone, only to find that the actual VST might have an issue] The TICK works [until I can find a better way].

Back to the MIDI OFF ...

I'm trying to put together a switching circuit that turns this main MIDI output to OFF [disconnects] when my plugin GUI is loaded up. I'm looking at the EdOpen prim as one way to trigger the Boolean state. Only when the GUI is open [view-able] would any MIDI data need happen, as one makes adjustments to knobs, buttons, sliders, etc]. When the GUI is CLOSED ... no need to have MIDI output active.

Basically, I just need the MIDI output to be OFF when first loaded. If I can 'automate' turning MIDIoutput active, that would be convenient.

There is one PRIMITIVE that I've never used. It is called 'CLOSE' [something like that]. It says that its use is to trigger when the schematic is about to close [possibly used to alert user to save, etc].

I wonder if this 'CLOSE' PRIMitive can be used in our VST plugs ??? anybody know ? If so, I could use that to kill MIDIout just before saving the DAW file ... and then, when reloading project, the MIDIout would be OFF.

sorry for the long explanation. This is a situation that I've not heard discussed anytime on the forum .. and may be unique to the type of FS designed MIDI controller I've made .... OR ... my design concept is just flawed ... cannot rule out the idiot putting this together

Thanks for following Spogg. Sometimes writing about the issue, and talking it through with someone help generate ideas/solutions. I CAN tell you ... I have nobody near me that has a clue about any of this stuff. Talk about the 'glazed over eyes' in 3 seconds... or less.

[RJHollins]

OK ... here is my first idea to dynamically switch/disconnect MIDI output at start-up.

capture.jpg (76.41 KiB) Viewed 21582 times

1. The AfterLoad sends trigger to a RESET module that outputs FALSE.

2. into a TRIGGER SWITCH set to pass only on TRUE [supplied by Button Status]

3.If Button status is FALSE, no change [blocked]
If Button status is TRUE, trigger is received/allowed to switch Button FALSE.

4. Button also toggles SELECT routing to main MIDI OUT port.

Tricky ... I had to add a 'Boolean to False' trigger to make the button status switch. Not sure why, but it don't work without it.

Finally ... the BUTTON must be able to work as expected.

At this point [early in testing], I need to verify that AFTERLOAD will kick in BEFORE any MIDI data leaks out when first loading up the VST.

I also looked at EdOPEN primitive. This could be handy, for as soon as the plugin is viewed, the MIDI connection could be automatically engaged ... ready to go.

With this current design, in order to make MIDI changes, the BUTTON needs to be clicked.

Possible issue ... What if my VST plugin was the last to be viewed [opened] when saving the DAW project. When the project RELOADS, my VST will be the first to open, triggering EdOPEN and connecting MIDI ... that could put me back into the initial problem

I know ... this is kinda a strange one to deal with. Appreciate any consoling, ideas ...

Here's the above schematic:

MIDI disconnect at startup-1.fsm

(4.43 KiB) Downloaded 876 times

Thanks Guys for following.

[RJHollins]

OK ... my kill MIDI out is working, and does prevent Reaper from locking up ... that's good.

I would like to make more user friendly, rather than manually having to click the MIDI ACTIVATE button. So I'm looking at the primitive, EdOPEN.

Another candidate ... the 'CLOSE' PRIMitive'. Does anyone know if this works as a function inside a VST format ?

Basically I'm looking to see what options available to proceed.

thx

[it would be very useful if a sequencer could be 'polled' as to its status, and report that info to our VST plugins].
Is there anything like that ?

[RJHollins]

Well ... I hooked in an 'OPenEditor' primitive that outputs a BOOLEAN value.

If the VST is OPEN, the primitive outputs TRUE.

The problem.

It seems the FIRST time the plugin is opened to view, the OPenED is not triggering. If I close the plugin, then THEN open it again ... it triggers TRUE. So ... the plug has to be opened twice in order for the BOOLEAN value to go TRUE.

Maybe this has something to do with having to BRIDGE 32-bit in a 64-bit DAW [using REAPER's Bridge]. I don't know ...

Anyone with any insight or suggestion ?? Has/can this be verified ?

Could really use some help on this .... Thanks !

[of course ... could be operator error ...]

[RJHollins]

---- edit ---

I did another troubleshoot check ... and did find an issue with the 'button' I was using. It was one of the custom buttons from the forum.

Looking inside, the STATE TOGGLE of the button was using plain TRIGGERS to switch the colors and text of the button.

I corrected that by making the select react to BOOLEAN values [on/off, true/false]. This change corrected the visual aspect ... HOWEVER ... the MIS-function was and is, still there.

The VST plugin GUI has to be opened TWICE before the EDOPen boolean triggers the TRUE state. Once you do that ... then it finctions correctly from there out. If I click to button to BYPASS, close and then open the GUI, the boolean goes TRUE, switches the button state, and everything works. Multiple testing proves this out.

It is just that the very first time, it takes 2 opens to start working ! Do you Guys need to see a schematic example ??

What's the problem ... is it because of 'bridging" ?

[RJHollins]

Alright ... alright .... so it WAS operator error

Sometimes [all too often], I make things more difficult than they should be

Now I have a working module that does exactly what I need to happen [and I learned a better troubleshooting technique along the way].

What we have:

1. When the VST plugin loads up, the AFTERLOAD triggers a FALSE boolean to switch the MIDI output OFF [disconnect].
This has turned out to be important to prevent double loading of parameters that happen in the DAW. Since each of the 8 to 16 samplers that I'm controlling via MIDI are all getting set by the saved DAW values, AND my plugin also has the same parameters that load and send to the samplers ... it was causing a lock-up of REAPER at the very end when loading the UNDO file. I don't know exactly why it would lock-up [freeze] but it did.

Having the MIDI output OFF during the load up stopped all the freeze problems. I could manually turn the MIDI connection back ON, and everything was working fine.

What I then wanted ... to have the MIDI turned ON after opening the VST GUI [the only time MIDI data would be changed/sent is via the open GUI [and adjustments by the User].

To that.

The AFTERLOAD trigger kills the MIDI.

Connected to the schematic is an EdOPEN primitive tied to a Trigger Delay. When the GUI is opened, this STATE is sent into a LAST primitive. A TRUE will connect the MIDI output.

I also have a trigger going back to the AFTERLOAD section from the EdOPEN, so that when the GUI is closed, the MIDI output disconnects. [I may be able to streamline that signal flow if this is redundant].

Tied to this circuit is a User button that allows manual control of the MIDI output connection. This is important should I make any major changes to my VST core [which would change the order of the saved PRESET Manager ... which usually creates a mess]. With the manual 'disconnect' I can load an updated VST, bypass the MIDI out, and manually match the settings to the collection of samplers under control. Then swap the old with the new, and back in business.

Sounds crazy ... maybe But what I'm working on is a 'core' MIDI generator engine. It is designed in a modular fashion that is held within a RACK format. Each module gets its custom design of knobs, buttons, layout, and an assignable MIDI CHANNEL.

From there, these modules can be duplicated as many times as needed to build a Rack of modules, each assigned to 1 of 16 MIDI Channels. These correspond to the number of samplers to support.

The samplers are housed in the chaining plugin, PlogueBIDULE. Inside BIDULE are are the MIDI Channel Filters, audio routing, CC controlled bypass routines, as well as metering to monitor Gain Staging throughout the chain.

Currently I have, some, 15+ VST controllers created with FlowStone. Using REAPERS FX Chains, I save these pre-made groups so that we can quickly Rock-n-Roll with whatever flavor of Equalizers, Consoles, Compressors needed for a Mastering session. [mainly EQ's].

The whole point of all this is to streamline the workflow. A central control GUI to handle all the support samplers at a single glance. No more opening 16 different windows to see what settings are there, or to make adjustments. Now I don't even need to LOOK at those VST collections. All functions are accessed via my controller.

Lastly ... I can use these in most any DAW and need only 2 INSERT points. One for the controller, the other for BIDULE.

Lastly ... lastly ... so much of this would NOT have been possible [or taking forever], had it not been for the gracious help from so many Members here. [i don't want to try and name them all, cause I might accidentally leave off some] ... I'm so bad remembering names

anyway ... that's the report.

If anyone interested ... I can post the schematic.