BrainModular

I asked this elsewhere, but it was a little OT, I think.

I want to double-check that there is no way to do what I'd like, within a rack.

My channel architecture is this:



I would love to put everything to the Left of the VST (input processing) in one patch, the VST wrapper in another, and everything to the Right in a third patch (output processing), all in the same rack without compromising latency.

It seems like since threads are per rack, this should be structurally possible....

Right now, I am having to load the vst portion as a subpatch, which has a lot of compromises compared to loading a patch proper via the loadpatch object.

Is there a way to wire a rack so this is possible? I can't find anything about rack routing in the docs.

Thanks,
-eric

i must probably miss something, but why don't you have all your input stuff in the "in" patch of rack, the output process in the "out" patch, and your load patch in a normal in beetwenn patch?

edit: sorry for cheap gfx but i would do this way personally:




All patches consists as VST + audio io and midi saved as .pat somewhere.

On Input audio patch do the custom whatever proc subpatch, as well on output patch.

On Input midi patch something trig the load patch depending rule/event that place the patch on 1-1 for exemple.

so Vst/patch does get all io and outputs to rack out

Ummmm, because it hadn't occurred to me?

Wow, I will try this. I never thought to make all my input processing part of a 'device'. I guess the term device made me think it should mostly just be 'the device'!! Also, I have had problems with devices becoming unresponsive, sometimes from being plugged into a different usb port, maybe? But if I have everything in a subpatch anyway, I can just copy and paste to a new device..... I guess I didn't even realize I could put a subpatch in a device! Funny how expectations become limitations....

furthermore, if I make changes to one device, will they then be updated to all the other instances of that device??? Awesome!

This would seem to be how it should be set up. I will try this immediately!

Thanks 100x!

Okay, major disappointment.

Any recieves in the input or output objects are not responding to info from the gui on the track. The processing is controlled from the gui, and although the patches are identical, they have different values.

I'm seeing nothing on the receives, which are set to 'rack' scope. These are things like transpose value, input channel, input trim, etc. They can't have different values in each rack, it looks like. And when I do 'get from existing buss' I only see global busses, not those from the track that the device patch is on (((

So this is why the input processing can't be in the device. It was never intended for this purpose.

edit: please tell me if I'm wrong, and there is something else I need to do to. This would be awesome if it worked.

ok, mm not sure i catched it all, but if well understood,
instead of using in/out racks patchs, just making one inproc patch just after in, outproc before out and a slot for the vst in between should do the job no?
so rackIN device ---> IN proc patch (with load patch for vst in next slot, gui params and individual settings) ---> VST patch----> out proc patch ----> rack output
i don't have the vst loaded here in pic but tested and work as expected , the inproc does process audio and receive midi from inputs, with adjustable own settings on gui, and the outproc process as well, if the vst patch contains audio/midi io they will be passed from inproc patch and to ouproc patch.

I will try this... for some reason it hasn't worked for me so far....

I do have need for a 4th slot for the gui, although I could combine it with another slot, with fewer compromises than loading vsts as subpatches. Maybe the midi and audio can just be passed through it?

I will experiment more. Maybe I've had it set up wrong.... It's encouraging to think it may be designed to work this way. (A little info about routing in the wiki under 'rack' would be helpful....)

okay, that worked!!!!
the prob was that I was losing flow with my gui patch. I just put audio in->audio out in the gui patch to pass through, and everything works.

I feel like I am finally using HH as designed!

cool