BrainModular

edit 14/09 Uploaded V3.5.

hey
if some are interested
I ve updated a new version using a different technique that allows this time to tweak the other parameters even if automations
are running, and other various improvments.

changelog:

_less wires: only one wire to connect for auto learn, (then can erase).
_Shift/scaleY function wich can make kind of cool live morph between static or automation values via cliquing and moving XY on the curve.
_same XY but controlling roll and scale (not perfect,but trycky;)

_no wiki yet :rolleyes:...but a massive use of cool Hints strings:) and tutorial text that i think it's ok to undertsand

//adons/others

great !

just 2 things :
maybe better provide a complete example ( with the VST named and linked )..?
when i use the reset function, the lines is reseted , name don't change but I've to re-use the learn button to have it work..?

mmm will check the reset thing.

olivier said last time he prefered a .pat than a .wksp, that's why i did that, but maybe
i can include the vst in the .pat, or provide another file with wksp, what would you do?

yes, I'm also talking about a patch , but ready to use
think about the newbies...

ok i tweak a bit that a reupload a patch with helios.

Ok I replaced the file with a direct exemple patch with Helios already linked for newbies

you were right nay there was a pb, i added pins to my script and the indexs wire was wrong connected..!

so identified and fixed the reset thing, and that lead to a pb with indexes not being stored. now everything seems to work fine.
also deleted previous array version, think this one is better anyway.?.. maybe i should add a way to control a param from
fader without affecting the automation, to tweak live then on release it reverts to previous automation.. what do you think.?
any ideas, suggz, review, bugz report welcome..


//addons/other

mmm
seems that's there's another problem now : can't add any midi in module or any other modules to inlets or outlets..????
precisely the modules are created but they are created in your subpatch ( but not linked of course )
with a Usine console error in bonus...

arf that goes again... that helped me to lighten many similar pb i had in liveosc patch, some connections/creations were strange.

i think using iml accessing parent patch make usine can't then create modules in current patch while automations are
running, as they contantly try to set parent patch... i ve got no solutions yet exept temp turning the patch off.

can be an issue indeed, i have to find another way mmm. ..

seems that's there's another problem now : can't add any midi in module or any other modules to inlets or outlets..????
precisely the modules are created but they are created in your subpatch ( but not linked of course )
with a Usine console error in bonus...

it's an Usine bug; will be solved in the 5.25beta7

i thought it was a user bug lol

automations are trying to set 'PARENT_PATCH', im not even sure this officially exist and is allowed lol, but it worked,
so i guess when creating a module it can't set sender patch as active one.

you mean this could work with next beta?
does the PARENT_PATCH really exist or i invented it?, i start to wonder lol

so I was getting in hard wiring complex stuff,
and
just retried with new usine beta8, now works like a charm, can still modules. impressive.

it was a conflict with TARGET_PATCH between the script engine and the template engine.

great , that draw/shift script is impressive ! really interesting !
little suggestion : add a has changed to the out of the fader-->rec , this way we can use the midi learn on the fader..

@senso and you managed to give some priority to template? anyway that's really cool! that will fix and secure many things for me

@nay: thanks, yup i like, its a simple shift/scale but gives interesting reults live.

i see what you mean by midi learn. A reflexion i had why finally touch items could be better in some cases like this one
is that they provide 2 infos: the mouse down and the value, wherease a real knob as only a value info.

in this case rec apply to automation 'when mouse is down', and won't give good results with the haschanged of an external
midi, cause will set steps only when changed, cannot detect "my hand is on the knob",, see what i mean.
if you try you will see spikes.

a solution could be to add an absolute rec swich we enable, tweak the pot, then disable,
i will post an updated version, also with a matrix to enable/bypass lanes, but still controllables via fader i just implemented.

@senso and you managed to give some priority to template? anyway that's really cool! that will fix and secure many things for me

Simply, the target patch variable for script is different those from templates.
but it's a very technical and internal problem....

23fx23, did I forget to properly thank you for this? If so, Thank you! This addon is perfect really!

One thing is I might like to set up an 8 parameter version. Is there anything major that would need changing in any of the scripts or could I simply edit the SCRIPT_AUTOMS to say const nb_cvs = 8; and duplicate the clocks script ?(and all other necessary modules)

Also, I se that it is probably imposssible in this patch but would be cool if we could midi learn a cc for each parameter and record or override any or all of values at the same time without having to switch.

But anyways I am very happy with this patch how it is

thanks guru, glad you like it. I got a V2.5 here that i worked on since with few improvments:
yes normally you could by waiting, need to chg Cvsto 8, duplicate and rename and increase array size.
but if you patient a bit , i really improved it:

_better global patching and scripting
_use new store array possibility in script, cleaner.
_activations swichs: automations can be activated or not (save cpu and let the control being editable on vst),
_ rec swich: if on will rec, if not will control the param overriding autom, without affecting autom that will replay on release.
_refresh speed setting . (can save a lot of cpu, was set to high previously)
_precision (step_bar) setting, if need to rec very fast changes.
_No more long params names commatext dealing with, iml getting only single param name, lower Cpu.
_Fader auto update to vst value when assign, changing active or selecting lane to avoid jumps.
_8x based now via a Tab to display/edit 1_4 or 5_8.

but have to wait next beta as ive seen something that senso improved on IML.

_ I see what ya and Nay mean by CC and yes that would be cool to rec several at once,
pb is the concept is based on rec only when msdwn, wich is not a info cc send, a has chg don't work but i can
add an absolute rec swich. I llsee how to implement the ability with midi
this will be my tonight reflexion:)

if ya interested, made a 'i find rocking now, quite proud' V3

8x version, via tab.
improved patching and scripting. new swap and select playing zone modes, more stable shift an roll modes.
Midi handling: now can assingn and rec up to 8CC. fader now auto updates in all needed cases for no jumps
auto rec start when detected a midi in matching one of the lanes and can autoloop_stop once loop length is achievedd,
few dynamic colors subtilities..


need beta11 Matriv1.2


addons/others.

I am all over it! Feedback to come....

hey guru im happy i quasi all implemented the new features we were after , that's quite cool:

_all/sel swich so that all types of manipulations.(clock,active,shift,roll,zone select,swap) can be applied to all or only sel. /done
_Pgm change (or other pulse temp) mute automs, get all values from vst and reset automs to each values. /done
tested working nice with program change, previously automs were messing directly controlling vst. now the vst takes over.
_ Send then values to 8CCs midi out for HW feedback, (checking console seems working ok). /done
_Any midi inCC override corresponding automation, with a smooth decay time so that automation retakes over if no more changes.
quite tricky to script in polyphonic but works nice. kind of morph.
_ now automs are send only if they changed, so if flat line as reseted from pgm change or other
can move the param on vst even if other are running, was not the case previously /done
_now auto detect nb_of pins of vst before params access to avoid enter manually ./done

i just got a tiny pb where i can get smoothdecay or overide but not booth perfectly in poliphonic but i should get over it tonight...

Ill count on ya soon for beta test for the midi out stuff..

wow! I look forward to trying this. If it's ready by tomorrow I can try then I will be away a couple of days...

If some are interested, reuploaded V3.5

with any midi now overrides with polyphonic morph of adjustable length back to automations, pick all Vstparams on PGM changes, sending 8CCs to midiOut, selection/All mode. fixed on/off occasional bug. start to rock now.

higly recommended update

edit:found a bug in all mode, reuploading in 5mn

redit: ok now working dine and reuploaded.

v 3.5 is sooo perfect now! Well done! Only comments I have to make so far are:

-don't forget to cnnect the midi out module and assign your midi output or you won't get on device feedback.

-perhaps it would be a good idea to link getAll to preset manager change so values update when the preset changes? (easy enough)

--perhaps also also a 'lock automs' switch that would prevent the automs from being flattened when changing presets?
(usefull for sometimes trying the same automs on different presets)

--the default preset that loads with patch load will overwrite your midi learn and other settings if you forget to store preset. Maybe better to upload with preset 0 empty to avoid confusion?
Also...MUST store current preset before saving or you will lose your settings!

-the presets allow for making multiple pages of learned VST parameters. This is good!

-I think this is a bug but for some reason double clicking the help comments to "self destruct" causes the output audio to stop untill I close and reopen the patch window

That is all for now....

yep that's some very valid points i was altought thinking of, ill update with those mods. thanks for feedback.

so is midi feedback working ok for you?

yeah self destruct was a bas idea hehe.

Midi feedback seems fine. No reltime feedback when changing parameter from the VST but that is ok for me.

just for fun, here's a simple little addon for your patch that selects from presets 0-11 with midi note input so that if using with a VSTI you can set different automs or set fixed parameter values for each note input or if using with a VST you can use midi note input to 'play' autom changes. Kind of fun.

http://www.sensomusic.com/forums/upload ... %20NUM.pat

yep i didn't made constant midi out to save cpu for those who dont use midi feedback, but maybe ill implement with a switch/

Nice idea the note preset swicher linked to a vsti sequence that can be cool indeed!

relating presets yes that's abit tricky. i wonder if i shouldn't separate if possible lines datas from the rest...

I just realized GetAll flattens all automs so that is not a very god thing if linking to preset changes...I was thinking of that as a solution for updating midi feedback but maybe this is the wrong solution?

yes i wanted to ask you cause it's a bit unclear for me.

actually the system is when a pulse is detected on getAll, it scan the vst array for corresponding automs and reset them
to thoses values, and send the 8values to midi cc out, i can arrange to make a swich for the reset process, so could anytime get
and send to midi the values, and reset only if the swich was on. this must be prettydoable.

anyway it's sure got to make a swich somehere to prevent from reseting automs in certain cases.

but what do ya mean by preset changes, wanna send the automs values? cause as they constantly run, mean should emmit non
stop (possible ,but higher process, but as the petch is not that high in cpu can test) or one static snaphot of 8values just when preset changed?

but what do ya mean by preset changes

yeah, maybe that doesn't really make sense to send value updates on preset change when automs are running, but it might make sense if an autom lane were flat to have the value updated on the controller when changing preset. Also it would be cool if there were an option to always send automs feedback to the controller but I don't know how much more cpu that would need? Maybe there could be a refresh setting to change how often the CC values were sent to the midi out?

I also was trying to think of a way to make an option to have the current preset auto save before changing preset but this doesn't seem so easy when controlling presets directly from the PM UI. I think I would make a new interface for the preset manager in this case...

Also, I would vote for putting the interface in a container but I can do that myself easy enough (I think)

btw, that is a monster script! Wish I could understand how it worked...
In a funny way the patch reminds me very much of a design for a circuit board with the Script Automs being the central microprocessor and everything else being resistors and capicitors and other logic controllers etc.... definately a strange similarity with Usine and electronics circuits.

Not to get off track, but I just had a though of using your patch to control groups of Usine interface objects
within a sub patch but it does not work like I hoped. Is this possible?

you see yhe exact same as me, thats cool yep. i thinks the preset save/load stuff need work.

i will try to add this to reflect how to my todo list (i speak like senso lol)
_a swich for reset automations or not
_a way to send to midi cc constantly or something when input pin is 1,. if too high cpu ill make a reresh clock but will probably not be that high, anyway will be mutable.
_ auto save finding, yeah from what i experienced in other patch need to overide pm with list box iml or other for that. ill think about it ,but i can make kind of similar system that my iml equivalent of your 128pm that should be able to do that.
it's a bit messy actually, need find a better system, but then it also should be a bypassable option .

the scipt start to be a bit messy but yep im quite happy of results, there are lot of possibilities and features
for a relatively descent cpu althougth it must have tons of ways to make it better, but well it worlks not bad

also right about contenair, i reckon ive been lasy on this one.

cool you helped me spot the next adds for a quite perfect V4.. before V5 ive put lot of energy, think will keep on improving this one..

yeah that was my first thought when running usine. electronics. script is the Cpu, automs are ram/rom

I missed that post

Not to get off track, but I just had a though of using your patch to control groups of Usine interface objects
within a sub patch but it does not work like I hoped. Is this possible?

mmm that's a reflection i also add, wanted to reuse this work for my liveOsc patch.

i think it's doable with few adjustments, the only limitations will be it can only be fixed range for all, ie alll 0..1,
i don't think i can get Min/max via iml mmmm all thing considered maybe if there are individual faders... i will investigate
the SX modular version, that could be really powerfull indeed... but i think it will be then a separate one, feel a combo will be hard,
but maybe possible..

might need some version .1 increments or else we are going to have a v37.5 before long
(btw, did u catch my last post just before your last one?)

lol

lol there are wait ones sometimes yep im working on 3.51 til the next 3.6

i didn't test but theorically if renaming the subpatch patch same as suposed Vstname and creating a 'program' inlet as fist one (out of the array) (the script search index of it on vst, as params are just folowwing) that may work like this...(in 01 range however if ever that works);

the only limitations will be it can only be fixed range for all, ie alll 0..1

That is easy enough to work around I think.

I just did a test with Senso's Set VST Params patch and I can control faders in a sub patch if I set the name of the patch and set the caption of the faders, so yes it is possible...
I don't get the same results in your patch, the control learns but I assume does not send the parameter name so that is why it doesn't work? Or did you mean something different. I think as a workaround if I really wanted I could connect a bus from the ouput pin of a simple VST to a fader and use the VST as a relay between automs and fader...

(btw, have you noticed the console spitting errors when clearing the patch? Also had a couple crashes and some other strange behavior when modifying stuff in this patch but I don't know if it the beta or the patch? Have you noticed anything? )

edit: the console errors do not happem when Helios is deleted first (btw, I think it's about time a better free VSTI was bundled with Usine. It would be nice to be able to share 'good' sounding examples...Helios has some good sounds but I find it's palette limited)

illl check that , yes normally that's possible (did ya tried by adding the program inlet?). i was working on the script, will check
already got the will reset or not swich and constant midi send but may have to optimize, but no crasy cpu jumps cool.

this patch use in a very(too much?) intensive way iml wich is not at basis made for such stuff but more to set some values with slow refresh/callbacks , once or i don't know exactly but feel it's asking a bit too much iml is not buses and i behave as it was
. I also got crash and error logs but it's more my unknowledge of how to handle yet carefully iml i guess than usine pbs. also senso fixed various things that made iml out of a script could interfer with others "iml", whenn creating faders or other modules, wires ect. it's far more secured, now but i suggest ya
to swich off when possible the patch when manipulating inside of it, then reenable when modules created and wired.

I'm not sure I understand what you mean about adding a program inlet? Anyways it's not important...