Hello everyone,
I want to control each voice of a synth with a dedicated midi channel (e.g. pitch bend and modulation on this channel should also only affect the one voice).
There are only few synths that have this feature, so I wanted to simulate it by using several synth instances and rewireing the parameter outs of one instance with the in of the next and so on.
If every knob has a parameter then I can still comfortably create patches by modifying the settings of the first synth instance - all other instances automatically inherit the settings of the first synth.
I tried this with two instances of the ME80 synth and it seems to work great in principle. The problem is that the rewireing is rather tedious for 8 or even 16 synth instances and hundreds (or even thousands) of parameters. (You can rewire two instances, copy both and rewire the two blocks, copy the 2x2 blocks and connect the two 2x2 blocks etc,, but even this way you go mad when doing this 4 times per synth for 16 instances.) So: Is there an efficient way to connect the outputs of a module to the corresponding inputs of a second instance of this module?
Thanks for any tips,
NaN
efficient way to rewire several synth instances
Hi NAN, i see 3 solutions that could make the thing go faster:
0)Probably not working: relink midi out of first to second, if first emit midi on params change 2nd should folow? then filter if necessary...
1)SIMPLE: prepare a subpatch with your synth and collect the infos you want to an "Array display or set" for inputs and ouputs. so then you can duplicate the patch and only wire one wire from Arrayout of first to array out of second ect.
2)MEDIUM: Use SendUsineInternalMessage module in /inteface control (IML), where you can say "wire form A 1 to B 1", make the text once for all needed IN/OUTs, then just sending the message will auto wire the stuff each time you need on a new subpatch
without retyping.
3) ADVANCED: Use IML and script , with the advantages the script can avoid you typing all the lines one by one, a bit more complex but easy if you're used to script and iml.
im also after this feature so i will try to make a script/iml patch exemple, i think the most handy solution would be a combinaison
of 3) and 1). one script/iml would auto wire to an array, then only use one array wire to connect the instances...
you can find more infos about IML HERE if wanna test, or here is an exemple using send internal msg module:
and most of the time interesting in/out will not start on 0 or 1 but more 4-5, have to test/check.
be aware IML can wire several times, so before resending should destroy all wire first (use Ctrl X to delete the module, then rePaste it with Ctr V and re-send the message).
hope it helps
0)Probably not working: relink midi out of first to second, if first emit midi on params change 2nd should folow? then filter if necessary...
1)SIMPLE: prepare a subpatch with your synth and collect the infos you want to an "Array display or set" for inputs and ouputs. so then you can duplicate the patch and only wire one wire from Arrayout of first to array out of second ect.
2)MEDIUM: Use SendUsineInternalMessage module in /inteface control (IML), where you can say "wire form A 1 to B 1", make the text once for all needed IN/OUTs, then just sending the message will auto wire the stuff each time you need on a new subpatch
without retyping.
3) ADVANCED: Use IML and script , with the advantages the script can avoid you typing all the lines one by one, a bit more complex but easy if you're used to script and iml.
im also after this feature so i will try to make a script/iml patch exemple, i think the most handy solution would be a combinaison
of 3) and 1). one script/iml would auto wire to an array, then only use one array wire to connect the instances...
you can find more infos about IML HERE if wanna test, or here is an exemple using send internal msg module:
note you have to name your synth via right clicking on it, the nb correspond of inputNb.SET_TARGET_PATCH SENDER_PATCH // will auto consider the active patch to make operations
CREATE_LINK SYNTH_A 1 SYNTH_B 1 // will link output 1 of module "SYNTH_A" to Input1 of module "SYNTH_B"
CREATE_LINK SYNTH_A 2 SYNTH_B 2
....or
CREATE_LINK SYNTH_A 1 ARRAY_OUT 1 // so ya link all to an array and have then only one wire to link between instances
.....
and most of the time interesting in/out will not start on 0 or 1 but more 4-5, have to test/check.
be aware IML can wire several times, so before resending should destroy all wire first (use Ctrl X to delete the module, then rePaste it with Ctr V and re-send the message).
hope it helps
Hi 23fx23,
Good tips!
I'll use variant 1) for making the ME80 multichannel aware.
Zebra is also on the list of synths that I would like to use, for that I'll probably have a more in-deepth look at your suggestions 2 and 3.
Thanks a lot!
NaN
Good tips!
I'll use variant 1) for making the ME80 multichannel aware.
Zebra is also on the list of synths that I would like to use, for that I'll probably have a more in-deepth look at your suggestions 2 and 3.
Thanks a lot!
NaN
I have finished a first version of the multichannel patch for ME80 with "technique no 1", works very nice!
Some questions to the experts:
* adding new wires is really slow in this patch (depends on the subpatch, adding a wire in MultiME80 takes nearly a minute). Is there a way to accelerate this?
* currently I have 15 copies of the SlaveSynth subpatch. Now it would be handy to link all those patches in order to be able to make changes to them without having to do the work 15 times or having to disassemble and reassemble the whole patch. (E.g. SynthMaker offers a link feature for components, is there something similar in Usine?)
* Usine crashed about 10 times when I built this schematic (mostly when I dropped a math component into the schematic). Is that memory related? (I only have 4 GB RAM but as Usine is a 32 bit app more presumably wouldn't help...)
I have uploaded the patch here if someone wants to have a look.
EDIT: sorry, forgot to compress the patch, replaced the original file with a zip archive now. (Is it normal that the uncompressed patch is about 90 MB? That seems rather big to me, the patch is not overly complex)
Some questions to the experts:
* adding new wires is really slow in this patch (depends on the subpatch, adding a wire in MultiME80 takes nearly a minute). Is there a way to accelerate this?
* currently I have 15 copies of the SlaveSynth subpatch. Now it would be handy to link all those patches in order to be able to make changes to them without having to do the work 15 times or having to disassemble and reassemble the whole patch. (E.g. SynthMaker offers a link feature for components, is there something similar in Usine?)
* Usine crashed about 10 times when I built this schematic (mostly when I dropped a math component into the schematic). Is that memory related? (I only have 4 GB RAM but as Usine is a 32 bit app more presumably wouldn't help...)
I have uploaded the patch here if someone wants to have a look.
EDIT: sorry, forgot to compress the patch, replaced the original file with a zip archive now. (Is it normal that the uncompressed patch is about 90 MB? That seems rather big to me, the patch is not overly complex)
nan, some observations from your post:
* adding wires can become very slow when your patch is too big as all of the current patch get a copy saved for undo every time you add a wire, etc.. The best solution for this is to split your patch into sub patches or more patches in the grid.
* there is no patch linking persay but if the master sub patch "master" were loaded as a top parent patch accross multiple cells in the grid, you could use the reload patch command to load the changes saved to the master patch. ATM, this is not possible for sub patches.
* your crashes are very likely memory related. Usine memory or virtual memory use can grow during patching so if the patch is already approaching your memory limits, adding another module could cause a crash. Sometimes it can be usefull to monitor Usines memory use with Process Explorer http://technet.microsoft.com/en-us/sysi ... 96653.aspx and then restart Usine when you are nearing your limits.
* 90MB for a patch seems excessively huge ! If I get a chance I'll take a look later today...
* adding wires can become very slow when your patch is too big as all of the current patch get a copy saved for undo every time you add a wire, etc.. The best solution for this is to split your patch into sub patches or more patches in the grid.
* there is no patch linking persay but if the master sub patch "master" were loaded as a top parent patch accross multiple cells in the grid, you could use the reload patch command to load the changes saved to the master patch. ATM, this is not possible for sub patches.
* your crashes are very likely memory related. Usine memory or virtual memory use can grow during patching so if the patch is already approaching your memory limits, adding another module could cause a crash. Sometimes it can be usefull to monitor Usines memory use with Process Explorer http://technet.microsoft.com/en-us/sysi ... 96653.aspx and then restart Usine when you are nearing your limits.
* 90MB for a patch seems excessively huge ! If I get a chance I'll take a look later today...
one other thing you could check that can avoid some wiring if splitting is using buses.
collect what you need to an array out of first master instance then use a Datasendbus.
in other instances you get that single same bus, then demultiplex the array.
no need to reroute then outputs in serial (wich would return 2x more wires), all their inputs are wireless linked to first array out.
collect what you need to an array out of first master instance then use a Datasendbus.
in other instances you get that single same bus, then demultiplex the array.
no need to reroute then outputs in serial (wich would return 2x more wires), all their inputs are wireless linked to first array out.
Thanks for the infos!
* it seems as if the undo function is looking through the complete subtree of the patch structure (so adding wires to the topmost subpatch is very slow while editing leaf node patches is quite fast). So presumably structuring it into even more subpatches could help for the inner patches but wouldn't make things faster for the outer ones.
Is there a way to disable the collecting of undo information? (Getting this faster for big schematics is imho essential, this one minute per wire delay takes out much of the fun when making patches. Only bearable while listening to really good music in the background
)
* Making the slavesynth subpatches root-level patches would occupy 16 patch slots. This would make things a little bit unhandy (especially if the multichannel instrument is not the only one in the workspace) and couldn't be loaded at all with the free version. Hope a linking feature for subpatches will come one day!
Thanks again for your answers and if you could have a look at the schematic - would be really cool!
Greetings,
NaN
* it seems as if the undo function is looking through the complete subtree of the patch structure (so adding wires to the topmost subpatch is very slow while editing leaf node patches is quite fast). So presumably structuring it into even more subpatches could help for the inner patches but wouldn't make things faster for the outer ones.
Is there a way to disable the collecting of undo information? (Getting this faster for big schematics is imho essential, this one minute per wire delay takes out much of the fun when making patches. Only bearable while listening to really good music in the background
)* Making the slavesynth subpatches root-level patches would occupy 16 patch slots. This would make things a little bit unhandy (especially if the multichannel instrument is not the only one in the workspace) and couldn't be loaded at all with the free version. Hope a linking feature for subpatches will come one day!
Thanks again for your answers and if you could have a look at the schematic - would be really cool!
Greetings,
NaN
@23fx23: thanks for the tip, will do that!
Greetings,
NaN
Greetings,
NaN
Ok, the schematic makes extensive use of busses now, I completely removed the arrays. The overall number of wires didn't get much lower (so adding a wire at the top level patch is still slow) and the file is still as big as before. But the number of wires at the upper levels is much lower now - and modifying those takes the most time. So the schematic is much more maintainable that way.
(I just replaced the zip file, so the link above points to the new version now).
(I just replaced the zip file, so the link above points to the new version now).
mmm i thought more about keeping the arrays, sending to one bus for the array out/in, i feel that will be less heavier for usine than x busses, (notes busses are handy but cost more cpu than wires)but names busses can be handy...
but it has the pb of not getting lost in array elmts, maybe you can keep busses but arrange for controls being sent as well by busses on another supbatch, so you don't have to patch on top level...
i will have a look at your patch, there bust also be a better iml possibility maybe..
but it has the pb of not getting lost in array elmts, maybe you can keep busses but arrange for controls being sent as well by busses on another supbatch, so you don't have to patch on top level...
i will have a look at your patch, there bust also be a better iml possibility maybe..
hi nan, if you want Ive made a script that wireless link all parameters of a master module/vst to all slaves, that way there is no wires at all and usine keeps fast. basically you choose a nb of inputs, if you give a name to the master and slave like those in the script
'MASTER' and 'VST_0 , VST_1, VST_2' ect you then get a button to auto wire from master to script, and then when an input changes it will be reflected on all clones.same input nb. seems cpu/memory correct and seems to work as well when several values together, quite cool, fast and modulable maintenance, but only tested with 3 vst and 3 simultaneous controls yet..
i guess it can have some limits..but it seems Prgm change test will quasi instentaneous chg all clones parameters, so
seems working not bad and might be a cool technique for your stuff, one cool thing being slaves folow master but can
then be independantely tweaked, and this trigged me lot of cool ideas
copy paste the text to an empty script and compile,
then put master and clones modules/vst in same patch as the script and name them, then the Wifi link should work
or can get a direct exemple Wksp with Helios
Here
note it uses and requires latest 5.17 version as it uses new great iml in script improvments.
well done olivier
'MASTER' and 'VST_0 , VST_1, VST_2' ect you then get a button to auto wire from master to script, and then when an input changes it will be reflected on all clones.same input nb. seems cpu/memory correct and seems to work as well when several values together, quite cool, fast and modulable maintenance, but only tested with 3 vst and 3 simultaneous controls yet..
i guess it can have some limits..but it seems Prgm change test will quasi instentaneous chg all clones parameters, so
seems working not bad and might be a cool technique for your stuff, one cool thing being slaves folow master but can
then be independantely tweaked, and this trigged me lot of cool ideas
copy paste the text to an empty script and compile,
then put master and clones modules/vst in same patch as the script and name them, then the Wifi link should work
//////////////////////////////////////////////////////////////////////////////////////
// IML_LINK 23fx 14.06.2K10
///////////////////////////////////////////////////////////////////////////////////////
// Allows to wireless reflect some inputs parameters of a module/vst to N slave clones.
///////////////////////////////////////////////////////////////////////////////////////
const Max_Ins= 64; // nb of input parameters (if changing ctrlX-ctrlV the script to destroy prev wires first)
const Nb_vst = 2; // nb of slave clones
const StartInput = 7; // start interesting input nb
const VstName = 'VST_'; // prefix name of slaves
const MasterName = 'MASTER'; // name of master for auto wire
const ScriptName = 'IML_LINK'; // name of actual script for auto wire
////////////////////////////////////////////////////////
var WIRE : Tparameter;
var INPUTS : array of Tparameter;
var i,j : integer;
///////////////////////////////////////////////////////////////////////////////////////
Procedure Init;
BEGIN
wire:= CreateParam('wire master',Ptbutton); SetIsOutPut(Wire,false);
setArrayLength(INPUTS,Max_Ins);
for i:=0 to Max_Ins-1 do begin
INPUTS:= CreateParam('Input'+IntToStr(i), PtDatafield); SetIsoutput(INPUTS,false);
end;
END;
//////////////////////////////////////////////////////////////////
Procedure callBack(n : integer);
BEGIN
for i:=0 to max_ins-1 do begin
if (n=INPUTS) then begin
sendInternalMsg('SET_TARGET_PATCH SENDER_PATCH');
for j:= 0 to nb_vst -1 do begin
SendInternalMsg('SET_VALUE',VstName+IntToStr(j),IntToStr(i+startInput),floatToStr(getValue(INPUTS)));
end;
end;
end;
if (n=Wire) and (getValue(Wire)=1) then begin
sendInternalMsg('SET_TARGET_PATCH SENDER_PATCH');
for i:=0 to max_ins-1 do begin
SendInternalMsg('CREATE_LINK',MasterName,IntToStr(i+startInput),ScriptName,IntToStr(i+2));
end;
end;
END;
//////////////////////////////////////////////////////////
or can get a direct exemple Wksp with Helios
Here
note it uses and requires latest 5.17 version as it uses new great iml in script improvments.
well done olivier
whaoo,interesting problem and impressive script !
+1
+1
Wow, thanks a lot, 23fx23, this is really cool!
Will try this out immediately when I come home.
Greetings,
NaN
Will try this out immediately when I come home.
Greetings,
NaN
Unfortunately it doesn't work for me. Nonetheless nice idea!
Here my console log:
Invalid internal message : SET_TARGET_PATCH SENDER_PATCH
process msg : SET_VALUE SLAVE_0 12 0.584999680519104
Var patch not found :TARGET_PATCH
Can't Set Value : SLAVE_0 12 0.584999680519104
process msg : SET_TARGET_PATCH SENDER_PATCH
Looks like the SET_TARGET_PATCH command is not recognized on my setup.
(The autowireing worked - it takes about 10 minutes or more though for 151 parameters, I already thought Usine has crashed)
I am using the 5.17 full version, should I use some internal beta instead? (If yes, where do I find this?)
Greetings,
NaN
Here my console log:
Invalid internal message : SET_TARGET_PATCH SENDER_PATCH
process msg : SET_VALUE SLAVE_0 12 0.584999680519104
Var patch not found :TARGET_PATCH
Can't Set Value : SLAVE_0 12 0.584999680519104
process msg : SET_TARGET_PATCH SENDER_PATCH
Looks like the SET_TARGET_PATCH command is not recognized on my setup.
(The autowireing worked - it takes about 10 minutes or more though for 151 parameters, I already thought Usine has crashed)
I am using the 5.17 full version, should I use some internal beta instead? (If yes, where do I find this?)
Greetings,
NaN
mmm strange, in any cases that should take not that long to wire, here it wires the 64 params in few seconds..im using official latest 5.17. mmm what's the pb with SET_TARGET_PATCH, im sure it's the good command, here retested works like a charm.
mmmm,Can't see.....Did ya test Nay or anyone? or maybe there is a limit above a nb of iml messages...
do ya get same msg even when opening the wksp on link above?
This one
mmmm,Can't see.....Did ya test Nay or anyone? or maybe there is a limit above a nb of iml messages...
do ya get same msg even when opening the wksp on link above?
This one
I've test quickly , was a bit long too about maybe 2 or 3 minutes
and a strange wiring ( check jpg ) but works ok even this way ..
and a strange wiring ( check jpg ) but works ok even this way ..
thanks for testing nay. mmm that's not that long here, maybe that quad core is very efficient
anyway you got it working and no usine console log, so i wonder what's pb on nan setup...mm
are ya sure ya named the master ans slave (not caption, using right clic, maybe avoid spaces in names)
strange wiring Nay indeed, but note there is a "start input" constant on script wich is 7 by default that was working well with helios, have to adapt for VSTs, here it seems should change to 15 or 16 for input0 to start on first param...(we count in/out pins before the one we wanna start from.
anyway you got it working and no usine console log, so i wonder what's pb on nan setup...mm
are ya sure ya named the master ans slave (not caption, using right clic, maybe avoid spaces in names)
strange wiring Nay indeed, but note there is a "start input" constant on script wich is 7 by default that was working well with helios, have to adapt for VSTs, here it seems should change to 15 or 16 for input0 to start on first param...(we count in/out pins before the one we wanna start from.
I've test again with an other vsti ( Oatmeal ) : correct wiring this time and 1 minute..
all seems working ok except some parameters like waveform..
oatmeal (freeware )
all seems working ok except some parameters like waveform..
oatmeal (freeware )
ok cool thanks nay, will try to check that wavform pb, should work as well normally...
me again..ha ha
i confirm , the processor/system is important :
first test was on a 2 years dual core with windows vista sp2
new one made on my laptop seven 64 bits : a few seconds...
an other test ( if you change to 120 parameters for example ( Helios has only 81 )
82 and more connect to first outlet ( like latency and invisible one..? )
i confirm , the processor/system is important :
first test was on a 2 years dual core with windows vista sp2
new one made on my laptop seven 64 bits : a few seconds...
an other test ( if you change to 120 parameters for example ( Helios has only 81 )
82 and more connect to first outlet ( like latency and invisible one..? )
Hi folks,
have tested 23fx23's workspace (the one with the Helios plugin).
The buttons of the one Helios instance are in motion (so the lfos work) but the others do nothing.
The console log is similar to my previous attempt:
...
process msg : SET_VALUE VST_0 14 0.355041712522507
Var patch not found :TARGET_PATCH
Can't Set Value : VST_0 14 0.355041712522507
process msg : SET_VALUE VST_1 14 0.355041712522507
Var patch not found :TARGET_PATCH
Can't Set Value : VST_1 14 0.355041712522507
process msg : SET_VALUE VST_2 14 0.355041712522507
Var patch not found :TARGET_PATCH
Can't Set Value : VST_2 14 0.355041712522507
process msg : SET_TARGET_PATCH SENDER_PATCH
Invalid internal message : SET_TARGET_PATCH SENDER_PATCH
etc.
My computer has an Intel Core2Duo 6700 2.66 GHz processor, 4 GB RAM and runs Windows 7 64 bit with a Juli@ audio card with ASIO drivers and several MIDI interfaces (E-MU XBoard 61 internal USB interface, UM-1 dedicated MIDI interface, Loop BE30 MIDI Loopback interface, Juli@ MIDI outs) . The Usine CPU profile is the "2cores : 12/12/12" setup, "nb threads" is 8. (These were the default values, didn't change them)
Greetings,
NaN
have tested 23fx23's workspace (the one with the Helios plugin).
The buttons of the one Helios instance are in motion (so the lfos work) but the others do nothing.
The console log is similar to my previous attempt:
...
process msg : SET_VALUE VST_0 14 0.355041712522507
Var patch not found :TARGET_PATCH
Can't Set Value : VST_0 14 0.355041712522507
process msg : SET_VALUE VST_1 14 0.355041712522507
Var patch not found :TARGET_PATCH
Can't Set Value : VST_1 14 0.355041712522507
process msg : SET_VALUE VST_2 14 0.355041712522507
Var patch not found :TARGET_PATCH
Can't Set Value : VST_2 14 0.355041712522507
process msg : SET_TARGET_PATCH SENDER_PATCH
Invalid internal message : SET_TARGET_PATCH SENDER_PATCH
etc.
My computer has an Intel Core2Duo 6700 2.66 GHz processor, 4 GB RAM and runs Windows 7 64 bit with a Juli@ audio card with ASIO drivers and several MIDI interfaces (E-MU XBoard 61 internal USB interface, UM-1 dedicated MIDI interface, Loop BE30 MIDI Loopback interface, Juli@ MIDI outs) . The Usine CPU profile is the "2cores : 12/12/12" setup, "nb threads" is 8. (These were the default values, didn't change them)
Greetings,
NaN
mmmmm strange, i can't see where pb could come from. mmmmmmm
edit : now i reopend my patch and i got same behaviour: can't set Target patch and pots don't upd anymore here same mmmm,
will investigate
edit : now i reopend my patch and i got same behaviour: can't set Target patch and pots don't upd anymore here same mmmm,
will investigate
ok it seems if putting all in a subpatch first and recompile script if necessary that will work again, maybe try this and report if ok for ya nan.
nay: ill check if find a solution but im affraid the inputs nb must be well calibrated by good old manual couting sadly, didn't yet found solution for counting Vst inputs, will investigate.
nay: ill check if find a solution but im affraid the inputs nb must be well calibrated by good old manual couting sadly, didn't yet found solution for counting Vst inputs, will investigate.
i've also had the pots problem time to time and resolve it this way :
just add a knob or fader to any parameter of the master and move it , then all others works
so maybe an initialization problem..?
but don't have the console message for the moment..,
@23fx : don't worry about input , it's not a big deal , maybe add a knob to set it manually if it's possible..?
for my part , this script give some cool ideas about auto wiring array with inlets of vsti , but i've to work more on scripting..; -)
just add a knob or fader to any parameter of the master and move it , then all others works
so maybe an initialization problem..?
but don't have the console message for the moment..,
@23fx : don't worry about input , it's not a big deal , maybe add a knob to set it manually if it's possible..?
for my part , this script give some cool ideas about auto wiring array with inlets of vsti , but i've to work more on scripting..; -)
ok nice trick, will check that.
one other thing i noticed that as you said wavform don't emit from vst, wheas it do when putting a fader on input,
for me it doesn't come from the script but from VST as nothing goes to the wire when changing... but this is another pb maybe.
yup as it can be interesting, i will make some inputs for names and nb and post as addon maybe, this can have various applications. i imagine some stuff as Nan, or progressive decrease of interactions, ducking/sidechaining, presets/automations
global apply, think their are many things even with classic modules and not vsts that could be interesting, and time saving.
In fact ive checked the input Nb thing, and it seems normal, we feel it goes to some first invisible input but it doesn't, it's the query system, can scroll the inputs on script/vst via scroller, usine display about 80 of them, (92 if well remember) but other exists and are accessibles. i was able to wire 343 wires on the go to Oatmeal, also it was a bit lagging then in wksp, the parameters still updated smootly wireless to two other instances, exept some as wavform, but ok with a fader on input.. maybe a little request to olivier
for Vst array out could higly reduce wires once more and allow to count paramnb if doable... but definitely an interesting way to explore...
one other thing i noticed that as you said wavform don't emit from vst, wheas it do when putting a fader on input,
for me it doesn't come from the script but from VST as nothing goes to the wire when changing... but this is another pb maybe.
yup as it can be interesting, i will make some inputs for names and nb and post as addon maybe, this can have various applications. i imagine some stuff as Nan, or progressive decrease of interactions, ducking/sidechaining, presets/automations
global apply, think their are many things even with classic modules and not vsts that could be interesting, and time saving.
In fact ive checked the input Nb thing, and it seems normal, we feel it goes to some first invisible input but it doesn't, it's the query system, can scroll the inputs on script/vst via scroller, usine display about 80 of them, (92 if well remember) but other exists and are accessibles. i was able to wire 343 wires on the go to Oatmeal, also it was a bit lagging then in wksp, the parameters still updated smootly wireless to two other instances, exept some as wavform, but ok with a fader on input.. maybe a little request to olivier
for Vst array out could higly reduce wires once more and allow to count paramnb if doable... but definitely an interesting way to explore...
Also tried to understand what's going on. Unfortunately Usine crashes every few minutes here atm 
Results:
* Initially it doesn't work
* If I manually modulate a parameter of the master (e.g. with a button - like nay wrote above) then it also works on my side!
* If I open the console then it stops working
* If I try to manually modulate a parameter of the master while the console is open the Usine crashes. (Beside from that Usine also crashes with a 9 out of 10 chance if I try to recompile the script after starting the audio engine, remove and readd the script module or press the "rewire" button that is connected to the script module.)
Will use the bus variant for the mean time and wait for a new Usine version where the scriptable IML is more stable.
Nonetheless very interesting and promising technology!
Thanks again to all of you (and expecially 23fx23) for your good ideas and dedication, really a nice community! And thanks to Senso for the interesting concepts of the software. This will offer so many possibilities once it's more mature!
Greetings,
NaN
Results:
* Initially it doesn't work
* If I manually modulate a parameter of the master (e.g. with a button - like nay wrote above) then it also works on my side!
* If I open the console then it stops working
* If I try to manually modulate a parameter of the master while the console is open the Usine crashes. (Beside from that Usine also crashes with a 9 out of 10 chance if I try to recompile the script after starting the audio engine, remove and readd the script module or press the "rewire" button that is connected to the script module.)
Will use the bus variant for the mean time and wait for a new Usine version where the scriptable IML is more stable.
Nonetheless very interesting and promising technology!
Thanks again to all of you (and expecially 23fx23) for your good ideas and dedication, really a nice community! And thanks to Senso for the interesting concepts of the software. This will offer so many possibilities once it's more mature!
Greetings,
NaN
yup in fact checking console or tracing values in wire can be very cpu/ram consumming, especially with large datas transfers with iml, and can lead to crashes. IML is a fresh powerfull tricky part, and maybe there are init things or better scripting for it to performs better, but i was quite surprised of very positive results here, ill let ya know if find some better things...
I suspect im sending the "set_target patch" msg X times where it could be sent only one..
I suspect im sending the "set_target patch" msg X times where it could be sent only one..
Who is online
Users browsing this forum: No registered users and 23 guests