Statistics: Posted by 23fx23 — 10 Feb 2018, 22:52
]]>
http://www.sensomusic.com/forums/upload ... erTest.wkp
Seems to work effectively for both vsts. I can't believe this actually works!
Thank you Gurulogic for the great starting point for this.
cheers,
-eric
Statistics: Posted by woodslanding — 10 Feb 2018, 17:40
]]>
Cut out the poly object in the lower right and paste it wherever you want. You only need one of these, set the poly to 64, and you'll have all you need.
What remains is the wiring each vst needs to have. And each needs to have a different index.
Not tested much, but it's looking functional!
http://www.sensomusic.com/forums/upload ... thLFOs.pat
cheers,
-e
Statistics: Posted by woodslanding — 10 Feb 2018, 09:10
]]>
Third example (example2waymap(alt)) is another approach where I circumnavigate the buses latency issue by having the plugin parameters kept in a local loop and sending the remote parameters data to manipulate the local loop directly. This would work fantastically except that I cannot even begin to comprehend how I would dynamically map the necessary index references and parameters from apprx 64 controller sources to their respective plugin destinations. This seems this would be extremely complicated so I doubt this is a solution.
http://www.sensomusic.com/forums/upload … alt%29.pat
Okay, I have run with this, and I think you will be happy with the results.http://www.sensomusic.com/forums/upload … alt%29.pat
This is preliminary, but it is working well in my tests. Still left to do: mechanism for setting destination param via learn (but I have already figured this out elsewhere) and support for multiple vsts. This may be tricky... but I think it will be possible, if every vst has this script attached to it. You'll probably need to use renamable busses....
http://www.sensomusic.com/forums/upload ... thLFOs.pat
Try it out, see what you think.
cheers,
-eric
Statistics: Posted by woodslanding — 10 Feb 2018, 08:27
]]>
I'm not sure a delay of one bloc is a problem at data level (could be at audio level).
In my experience, block delays are a big problem in data loopback, as you get 'jitter' where two different values chase each other around the loop, and the parameter never stops changing. This happens any time you use sends in a loop, and has to be accounted for. You can't ever have a completed loop with a delay in it, the loop must always be broken at some point.Statistics: Posted by woodslanding — 08 Feb 2018, 22:11
]]>
Statistics: Posted by sm_jamieson — 08 Feb 2018, 19:14
]]>
that test for each parameters if it as change or not, and only change the ones that changed
Statistics: Posted by oli_lab — 08 Feb 2018, 17:41
]]>
else if ( Message->wParam >= offsetParamsArrayInOut && Message->wParam < offsetParamsNamesOut )
{
// sanity check in case array size != numOfParams InsOuts
int numOfArrayParams = std::min (numOfParamsInOut, (int) sdkGetEvtSize (m_arrParamsInOut));
// update all params
for (int i = 0; i < numOfArrayParams; ++i)
{
float oldValue = sdkGetEvtData (m_fdrParamsInsOuts);
float newValue = sdkGetEvtArrayData (m_arrParamsInOut, i);
if (newValue != oldValue)
{
pluginInstance->setParameter(i, newValue);
setModuleParamValue (i, newValue);
}
}
}
If the plugin wrapper is the one used in Usine, we could produce a User module to test some different types of logic.
Statistics: Posted by sm_jamieson — 08 Feb 2018, 17:36
]]>
preserving current way of working, just adding a new check if user new array size is >0, wich also has prob slightly less cpu/mem overhead for big arrays if not used.
good trick for out of range value
Statistics: Posted by 23fx23 — 08 Feb 2018, 11:38
]]>
_add a new "param_need_import" array input of param size. it would be a boolean type where user specify for each id values from array in if it will be updated.
if user didn't fed an array, assume all need to be "imported" and use the 'legacy' curent schema.
if user fed an array, ie here the array would be filled with 0, exept on id3 iwould be 1, when the array in changes, it would scan that array id as well, and pass internally only value@ id3.
OR
_ add 1 new arrays in or variable size, that would list only params id to change, say 5-8-12. or here only 3. so on arrayIn changes, it pick only those IDs values from array in to the internal structure
Yes either of these are better than internal pass-if-changed, which has its own problems if you want to enforce the same value as last time. With internal pass-if-changed, if you sent a value on the input, then the value was changed from the VST GUI or something, and you wanted to send the same value again on the input it would not be registered.if user didn't fed an array, assume all need to be "imported" and use the 'legacy' curent schema.
if user fed an array, ie here the array would be filled with 0, exept on id3 iwould be 1, when the array in changes, it would scan that array id as well, and pass internally only value@ id3.
OR
_ add 1 new arrays in or variable size, that would list only params id to change, say 5-8-12. or here only 3. so on arrayIn changes, it pick only those IDs values from array in to the internal structure
By the way, I have solved this problem before by sending a value that will be ignored by the end module, but will "reset" the pass-if-changed module.
Statistics: Posted by sm_jamieson — 08 Feb 2018, 10:42
]]>
but not always. say i want to just add 5 lfos to 5 ids, (that will dynamically change so array is more conveniant than wiring individual pins).. the wiring would be much simpler without dealing with feedback. array out would recflect both Ui set values and values set by the lfo,
don't really need array in to be updated in that case for ex. as the arrayin would only update the lfo values internally, not the others that remain as were set by the ui. dk if make sense
there are cases when using busses that go outside of the patch somewhere else say 'gloabl managing' for a ui param then get back in where 1 bloc latency occur on the feedback data, so that can make crazy 'fight' loops .think some patch posted earlier by guru shown that problem or ill try to make an exemple. ie vst 'send' value 1 but next bloc it receive 0, so resend 0, get back 1 ect
i have to update usine to check the wksp, ill have a look thanks
Statistics: Posted by 23fx23 — 07 Feb 2018, 20:31
]]>
you'll always need a loopback if you want the array on the left to be refreshed when you tweak the knobs on the VST GUI, don't you ?
I'm not sure a delay of one bloc is a problem at data level (could be at audio level).
as for the screening of the parameters you want to modulate, that can be done with a mapper value module.
http://www.sensomusic.com/forums/upload ... lation.wkp
cheers
Statistics: Posted by oli_lab — 07 Feb 2018, 19:37
]]>
we have an UI element of param0. if it changes, it updates the internal data. so far so good.
on input, say we prefer using array for conveniance. we set up an lfo constantly modulating value3. we feed that array to the vst module.
A) top diagram, current usine implemantation.
the array is analysed, detected changing, all individual array datas are passed to the internal stucture, overriding ALL current values by those of arry in, including value0
B) modified with 'INTERNAL' pass if change.
the array is analysed data by data, only the one that changed (here lfo val3) update corresponding value in internal datas. value0 is not affected.
In reality, that kinda normal, usine does what we ask it to do. but on a 'workflow' thing, its a bit of a pain.
so actually we are trying to counter with feedback schemas, that in several case can have a block latency in the loop making things quicly complex
my sugg to senso if reading for making things simpler, while *i suppose* not being overly complex changes to usine would be a modification of VST module:
_either use an internal pass if change shema like B;
OR
_add a new "param_need_import" array input of param size. it would be a boolean type where user specify for each id values from array in if it will be updated.
if user didn't fed an array, assume all need to be "imported" and use the 'legacy' curent schema.
if user fed an array, ie here the array would be filled with 0, exept on id3 iwould be 1, when the array in changes, it would scan that array id as well, and pass internally only value@ id3.
OR
_ add 1 new arrays in or variable size, that would list only params id to change, say 5-8-12. or here only 3. so on arrayIn changes, it pick only those IDs values from array in to the internal structure
Statistics: Posted by 23fx23 — 07 Feb 2018, 19:00
]]>
so when you change preset should be good !?
At least, it's working well for my one hand sound tweaking simulator !
Statistics: Posted by oli_lab — 07 Feb 2018, 14:53
]]>
]]>
Oh well....
Statistics: Posted by woodslanding — 06 Feb 2018, 22:25
]]>
For some reason, 'force' is not working.... I can't figure out why.
CODE:
//Pass If Changed Array//By Eric Moon Jan 2018//GLOBAL VARIABLES AND TPARAMETER DECLARATIONSvar arrIN :TParameter;var arrOUT :TParameter;var forceIN : TParameter var arrMemory : array of single;//values of parametersvar arrChanged : boolean;///////////////////////////////////// //INIT///////////////////////////////////// PROCEDURE INIT();BEGIN arrIN:=CreateParam('array',ptArray); setIsOutput(arrIN,false); forceIN:=CreateParam('force',ptButton); setIsOutput(forceIN,false); arrOUT:=CreateParam('array',ptArray); setIsInput(arrOUT,false); arrChanged := FALSE; setLength(arrOUT, -1);END; ///////////////////////////////////// PROCEDURE Callback(n : integer);var i,count : integer;BEGIN if (n = arrIN) OR ((n = forceIN) and (getValue(n) > 0)) then begin count := getLength(arrIN); setLength(arrOUT, count); for i := 0 to count - 1 do begin setDataArrayValue(arrOUT, i, getDataArrayValue(arrIN,i)); end; arrChanged := TRUE; end; END; ///////////////////////////////////// PROCEDURE ProcessIdle();BEGIN if arrChanged then begin setLength(arrOUT, -1); arrChanged := FALSE; end;END;Statistics: Posted by woodslanding — 06 Feb 2018, 21:34
]]>
if the module had internal 'pass only if changed', it would be able to detect only the lfo param/params in the array that changed over last bloc, and update only it/them, the other values would not pass internally, and the user could still tweak other params on the ui with no 'fight' occuring. that seems the easiest mod to usine current implementation to me.
^this!Statistics: Posted by gurulogic — 05 Feb 2018, 23:05
]]>
if the module had internal 'pass only if changed', it would be able to detect only the lfo param/params in the array that changed over last bloc, and update only it/them, the other values would not pass internally, and the user could still tweak other params on the ui with no 'fight' occuring. that seems the easiest mod to usine current implementation to me.
Statistics: Posted by 23fx23 — 05 Feb 2018, 15:20
]]>
]]>
Statistics: Posted by oli_lab — 05 Feb 2018, 13:19
]]>
Rereading this, I have completely not dealt with the lfo param control issue!
I do SO miss Max's parameter control method here. Just send a 2 item array where item 1 is the param# (or name) and item 2 is the value.
Similarly, when a param is changed in the vst, you get a 2 item array out.
That could easily be added to the VST plugin-in module.I do SO miss Max's parameter control method here. Just send a 2 item array where item 1 is the param# (or name) and item 2 is the value.
Similarly, when a param is changed in the vst, you get a 2 item array out.
In fact it would be useful if all modules had this function. Then you could receive details of parameter changes over one "array" wire instead of lots of wires, but use the separate wires when needing signal processing rather than messsages. Actually, since several parameters could change in the same bloc, this might need to be extended to an array containing parameter number and value pairs, with the array as large are need be. A similar array input on all modules could be used to set parameters.
Of course at the moment that array only has data parameters, so this could not be used to set a text parameter for example.
I think a "message" is simply an array that gets sent once and does not stay on the wire. And a converter to a message is just a create array module. The things missing to make this act like a message areDoesn't work very well with Usine's circuit model tho (as opposed to Max's message model...)
But Usine uses the message model with MIDI.... and Reaktor uses both messages and circuits with converters from one to the other.... and vst singleparamArrayOUT could send [-1] in between arrays....
Have you tried addressing params through midi? I suppose that requires lots of internal mapping in plugs, and not all plugs support it.
1. If cannot be received as a array then when then array items are extracted you can get a callback for one of them changed, but the other ones have not yet been updated. With a message you need to know that when you are told a message has arrived that all of its parts are there.
2. A message needs to be only sent once. Usine MIDI flow is like a message, but you have to manually delete it from the wire on the next bloc else it will be received twice.
It would be useful to have a parameter flag when the signal stays on the wire for 1 bloc and is then then wire is "disconnected" (like setting size to -1).
I think a "message" facility in Usine would be extremely useful and could be done in a way that does not add much overhead to the CPU. I might put some of this as a suggestion/improvement.
Simon.
Statistics: Posted by sm_jamieson — 05 Feb 2018, 11:22
]]>
that seems to do the trick
Statistics: Posted by oli_lab — 04 Feb 2018, 13:55
]]>
I do SO miss Max's parameter control method here. Just send a 2 item array where item 1 is the param# (or name) and item 2 is the value.
Similarly, when a param is changed in the vst, you get a 2 item array out.
Doesn't work very well with Usine's circuit model tho (as opposed to Max's message model...)
But Usine uses the message model with MIDI.... and Reaktor uses both messages and circuits with converters from one to the other.... and vst singleparamArrayOUT could send [-1] in between arrays....
Have you tried addressing params through midi? I suppose that requires lots of internal mapping in plugs, and not all plugs support it.
Statistics: Posted by woodslanding — 04 Feb 2018, 04:55
]]>
Hasn't been exhaustively tested, but seems to work.
http://www.sensomusic.com/forums/upload ... erBank.pat
To use:
Press learn. Move slider. Move VST control. Rinse and repeat (actually rinsing is done for you)
Learn button should turn off, and slider is mapped. So far I can move params in either vst or slider bank without issue, but try it out and let me know how it is working.
Mappings are stored in faders in subpatch so they can be stored/recalled with a preset. If you change poly value in slider bank, make sure to change CONTROL_COUNT in the script to match.
cheers,
-eric
Statistics: Posted by woodslanding — 02 Feb 2018, 19:09
]]>