Statistics: Posted by 23fx23 — 02 Jan 2017, 18:36
]]>
I feel like I am finally using HH as designed!
Statistics: Posted by woodslanding — 02 Jan 2017, 16:30
]]>
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....)
Statistics: Posted by woodslanding — 02 Jan 2017, 15:54
]]>
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.
Statistics: Posted by 23fx23 — 02 Jan 2017, 07:32
]]>
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.
Statistics: Posted by woodslanding — 02 Jan 2017, 03:53
]]>
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!
Statistics: Posted by woodslanding — 01 Jan 2017, 22:31
]]>
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
Statistics: Posted by 23fx23 — 31 Dec 2016, 12:44
]]>
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
Statistics: Posted by woodslanding — 31 Dec 2016, 02:32
]]>