BrainModular

hi,, trying to find the right combination of modules to prevent data overflow,, i know this is something probably simple im missing but need to have a fader not send midi when receiving or vice versa to avoid midi or osc overflow,,
any help would be greatly appreciated! thanks

last question for today,,,
is there a way to have a generic caption sent when receiving a certain message?
ie ableton clip data sends name to button caption,, name receives yah,, delete clip,, last name stays,,
liveosc sends value of 0 on /live/name/clip i would like it to generate something to clear the buttons caption to either none,, or have nothing showed ect


thanks again for all your help here.... i wont be a noob for ever (hopefully)

about caption , you can use a simple pass event flow module,
osc receive -->pass 0-->inlet caption...?
about your first question do you talk about a fader receiving midi by a midi learn for example or..?

thanks for help nay-seven,

here's an example of data flow problems,,
im trying to have a knob send and receive via osc to ableton,
ie osc receive (lets say live tempo) ---> knob in interface builder -----> =data feedback,, knob starts jumping in value and gets majorly confused,, receiving tempo,, then sending back to it self ect

so my workaround is this,,
osc receive ---> stop data flow module--> knob--->sent to osc send and also sent to "has changed" which is used to triger the "stop event flow"

ultimately trying to have it stop sending data when its receiving data,, eliminating the feedback,, i think this kindof works but not 100% wondering if there is a better or simpler way,,
thaks for your help again!




it works but i dont think its quite right,, less jumpy but still a little bit off kilter,,, keep in mind ive only been using usine for a couple weeks so im just learning all the modules and doing what i can with the ones i have figured out

just to know, is it constant change like a clock ? in this case generally there is a master and a slave . ?if it's only tempo change maybe a pass only if change . ?

i see,,, thats why it works fine for me with clock but not with volume faders ect?

i used stop event pass modules between every fader and have them set to stop if "has changed " gets triggered..
input stops if fader is sending data out,, output stops if data comes in on the right channel

it got my volumes working somewhat,, they dont fight anymore when receiving or sending volume changes,,, seems almost there except...

it seems some data will leak out , i can verify a small degree of data conflicting if i write some volume automation in ableton,,
then when i play it back ableton's "back to arrangement button" gets light meaning that something got sent back to ableton as volume change making the automation stop and "back to arrangement" button go red

so works for me now... as i need it to for performing live,, but i have a feeling that there might be a better way of doing this?

using same item for control/ feedback with osc is a bit tricky. in usine itself generally a pass if change is nicely doing the job, but with delayed data as osc it's a bit more complex. when possible it's better to contol visual feedback and trigger in a separate way.

for example it's really hard for a swich (but possible) to send an info to contol, and get a delayed feedback that will make it updates, resend, ect creating crasy loops. to bypass that, you can use a image/panel that send info on mouse down , then the received data control it's color for visual feedback, there is no interferences, as the panel will send only on mouse down change, not color changes, longer to wire, but more modular and no weird feedback loops.

if realy need "constant" bi-directional:
generally we need to stop for longer time, so there is a rest state and data doesn't change, so doesn't send feedback (if based on a "has chg" system), ie. when receive blink it stops, but if receive goes also to a wait one so its tiny delayed, then out of the wait one also going to stop it can stop the data for two times instead of one, mean for a longer time, can use several wait ones, or time counters to stop longer, depending of "latency" of the loop.

i also often use the mouse module, the "left" output lights up on mousedown, so you can force any data to stop trying to feedback as long as you are controlling a fader for example, while if you release, the other side,can send and the data pass to update. it's often beter to stop with a long continuous 1 than constantly alterning 0,1 0,10,1 of a "has changed" , and then generally to make it stop a bit longer, ie when mouse release trig a counter or wait one tecnique to keep on stoping a bit.
tracking/decomposing events "process" order in it's mind as you do is the solution. and it's often knowing where to put a tempo, pass / stop , to trig in a certain order, visualize event flow and where pb comes from.

and mmm concerning live osc im suposing you're tweaking; |, my feel is to avoid headheach that usine controls should stay the master, and live slave, in a master/slave communication as mentionned by nay. if want to get visual feedback to avoid ie a knob jump, it's seem far less complex to just send a "request" pulse, ie with a button, then the knob update, and don't affect live has it's getting same position, then as we go for tweaking the pot we don't need anymore feedback as it's a master controller, the position it reflects is the real one. total bidirectionnal is possible but now i doubt about utility/complexity ratio
after long wiring,test,complex setups
i said myself woa im moving pot in live why a cheapy buggy mouse and usine upates, ....so what's the point?
the core control unit is on interface buider !;) now it's in usine we can rec/loop automations, put step faders,script some trigger laws, anything we have in mind seems doable, usine is the ultimate master controler/expander, still need to get correct values.
a simple buton request, that make data pass to know position and it's done, why make it complex;..

usine fills the lack of ableton intermodularity very nicely with live osc, controls sidechaining/ducking/inverssing/processing, sending random, rec data, anything , plus create a crasy interface builder, multitouch, that still cover about 2 percent of usine possibilities, we live in a crasy world

"yes we do" i love it!,,, hahha,,
thanks again for the help guys,,
good tip with the mouse down module,, think im going to try that, let you know how it goes,,
i basically am trying to use stop event flow and pass event flow,, i figured that sending the pass event data to the in of the stop makes a kinda one directional switch,, ie,, when passing on one path,, stopped on the other,, one being input,, one being output,, that along with delay ect,, wish me luck,,
how do i change the time of "wait one cycle" is there something simple than chaining a bunch together btw?

23fx23. did you see my post in other thread about sends?
got almost everything i need talking back and forth, sends and pans behaving weird,,

yup just saw your other post, answered for sends..

good luck on your feedback fight
no there is no way to change time of a wait one cycle (maybe a wait n cycle could be a good using futur add, but it should be doable by script, sadly i don't master that part of usine yet, but looking at it..), anyway there is already a datadelay script working nice, or usually for longer time I also use the time (ms) module,
on a pulse it make time pass to a wire, subtracting then this to running time outputs 'elapsed time from pulse received'
then with some A<B, we can say if elapsed time is inferior to ie 100ms, data stop,once 100ms are elapsed, data pass.
this is a bit lower Cpu that using "elapsed time" subpatch, but you can also direcltly use the subpatch if don't want to bother.