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

[Spogg]

Well, I'm always interested in seeing any schematic and this one sounds very interesting.
One of the many things I love about Flowstone is the truly open-ended learning process, and seeing other people's work can be an inspiration.
Isn't it just a great feeling when you finally get something working as you want? That's the addiction for me.

Cheers

Spogg

[RJHollins]

Hi Spogg,

It is a great feeling [along with one of ... man, that last brain cell took another beating]

Been a long day ... tomorrow I'll post up the example schematic.

I sure would be interested in hearing any comments, or improvement suggestions. I think this 'feature' was fairly unique in what I have to deal with. [I was surprised what I had to deal with].

I had used several different 'band-aid' concepts to get to this point. For the longest time, I thought there might not be a solution ... that is doing it outside of FlowStone [something I just don't have the time to pursue].

I've implemented this new technique in one of my controllers for testing. I need to be certain that it works flawlessly. I can say, this idea is the most elegant solution to date.

If it stays solid and predictable ... it is a very simple insert/replacement in every one of my other controllers [except for adjusting a couple GUI elements ... and even that might be less of significance. There are a few modules that can also be totally removed [along with data storage routine that handled an attempt at 'User defined delay settings'. Like I say ... those were band-aids. This routine is 'just forget that it is there'. As long as it continues to work

until then ...

[RJHollins]

Hi Gang ...

I'm posting a small module that attempts to handle a special situation. To re-cap:

As a VST plug, I need to insure that the main OUTPUT is always in disconnect state when loaded into DAW [recall].

2. When the plugin GUI is selected [viewed], the MIDI connection is then active [I've a small 1000 ms delay added [adjustable].

The BUTTON shown must also work to allow either connection state. Regardless of what it's state is when the project is saved, the re-loading must be certain that the MIDI connect is OFF, and only re-connects when the VSY GUI is opened.

I've included the audio/midi routing so that a VST can be made.

I would really appreciate if the 'Experts' would look over this example and verify if I've done this correctly [or if there is a better way].

Please ... if there are any questions about this, don't hesitate to ask. I need this to be 100% reliable.

Here's the schematic:

EdOPEN Test-1c.fsm

(4.59 KiB) Downloaded 837 times

Thanks for any comments/help.

[RJHollins]

UPDATE

Still verifying this special module. Found a flaw.

Uploading a new version 1-d.

EdOPEN Test-1d.fsm

(4.58 KiB) Downloaded 898 times

Would sure appreciate help testing this as a VST.

thanks

[RJHollins]

nobody ?

[RJHollins]

Well ... nobody seemed interested

anyway ... the version I last posted here does NOT work the way I need or intended.

Earlier tonite I started with a fresh idea and approach.

Just finished testing in 2 separate FS projects, and happy to see this new version 2 is working exactly as needed. [at least in REAPER with its built-in bridge [32->64].

The concept:

Because my FS projects generate only MIDI data to control up to 16 other 3rd party VST plugins, I was finding conflict with having BOTH the DAW and my FS plugin BOTH configuring these 3rd party plugs.

2. In fact, it was redundant/un-needed for my plugin to basically duplicate the initializing data to these other plugs during RE-Loading of a SAVED session.

The specific 'fix' needed to KILL the MIDI output of my plug for a specified amount of time till all internal data was set in.

Once the GUI was OPENED, the User Controlled ON/OFF button was then able to switch ON [active].

From that point on, Opening and Closing the GUI should NOT affect the ON/OFF status.

So basically, this is a one-time, initialization routine.

Granted ... this is probably a more unique situation than what most FS users would ever need. [maybe accounts for the lack of interest].

Anyway ... it forced me to re-think the logic of all this, and utilize conditional PRIMS that interact and set conditions. The result ended up in a much simpler design, and with all the requirements.

Since I have, some, 15+ FS projects [for specific 3rd party libraries], this special function is needed for all of them.
It is now in the TOOLBOX.