buss update issue

[woodslanding]

Okay, I posted on this before, and it double-posted on me, and when I tried to remove the extra post, the whole topic went away.

But I am much better prepared now!

I've uploaded a simple patch. It contains a switch which chooses one of two subpatches to be active and also visible. Each one contains a fader controlled by a buss recieve. The buss send is driven by a third 'master' fader. Here are two attempts:

http://sensomusic.com/forums/uploaded/faderTest2.pat

http://sensomusic.com/forums/uploaded/faderTest.pat

Here is what I would like to have happen:

The visible fader should be controlled by the master--this is working.

BUT: when I switch the display to the other fader, I do NOT want it to update to the current position of the master fader---until the master fader is actually moved!

I have tried every combination of usine event handlers I can think of, stop event, freeze event, etc, and nothing I have done keeps the disabled fader from updating to the current master fader value, as soon as it becomes visible again.....

Any thoughts???

Thanks!!
-eric

[23fx23]

hi Woodslanding, Ive uploaded a patch i remade from scratch sorry, but does exactly what you mean:

http://www.sensomusic.com/forums/upload ... T%202b.pat

Bus can freeze the data when patch is turned off this seems normal and not really a bug.,just often need to put a wait one to make it active one bloc more, send the value, then swich off.

then here the new mouse down option on fader is what i was after to make thingz like this much simpler:

you can convert the sentence to " I want the values to pass to active subfader ONLY when I got my mouse down on master fader"
this way even if swiching from one or the other, values don't upfate as long as you didn't modify master fader, just a pass linked to mouse down and you're done.. In case of you use prestets or master is suposed to change even without a direct mouse contol, a hascghd sending to pass bus should do the job..

hope it helps..

btw can go deeper with the master fader updating the corresponding value, but as it wasn't the case in your example I let it like that..

[gurulogic]

one possible problem with your solution 23fx23, is that it does not work when the master fader is midi learned.

(edit: it would make a lot of sense if a mouse down could be sent when an interface item was receiving midi control. Senso?)

[gurulogic]

Here's a solution that works with midi learn (thanks to Senso set VST params script) I am still trying to figure out how to update the master fader so I wouldn't quite call this the perfect solution yet but maybe a good place to start?

http://www.sensomusic.com/forums/upload ... T%202c.pat

[gurulogic]

How about this...now we are sticking with your busses idea and I think it now works how you want?

http://www.sensomusic.com/forums/upload ... T%202e.pat

edit:
removed a useless stop event flow module

[woodslanding]

"one possible problem with your solution 23fx23, is that it does not work when the master fader is midi learned."

yeah, the whole point of this is to midi-learn the master fader. And I am only doing this because midi-learn still affects the faders even when a page is disabled and invisible!

*****

Interesting solution, gurulogic.....

but it does call for a lot of busses. I have 14 pages, each with 8 faders. I have 8 sends now, and with your patch I would have 120! I worry about CPU.

I don't care if the master fader updates to the value (it won't even be visible in the IB) I just don't want it *sending a value*.... so I think this is still not a great solution.

There must be some way for a recieve to become enabled without sending a value.... or a way to discard that value. "only if changed" normally works this way, but it unfortunately considers the re-enabling of a buss to be a "new" value. I would think the buss would have a null value since there is a 'pass only if changed' module just before it. But the buss itself seems to "hold" the value, and there's nothing I can do about that.

Senso, do you think busses need to behave that way???

This pb would be so easy in reaktor where events are actually events, and not 'pseudo-streams'. And I guess that brings me back to using internal midi busses for this. But it seems like it would be useful to have an actual 'event' mode in usine, which behaves more like midi CC messages do.

Here's the midi solution:

http://sensomusic.com/forums/uploaded/faderTestMIDI.pat

I guess that works just fine, and is not too complicated. Overkill, but no new busses required.

I encountered this problem before when I wanted to send a series of events of value '1'. Usine has no way to deal with this..... Reaktor looks at actual individual events, and can do something every time it sees a "1". It seems like Usine just sees a constant value of 1, and no way to change this.

-e

[23fx23]

In case of you use prestets or master is suposed to change even without a direct mouse contol, a hascghd sending to pass bus should do the job..
.

this should apply with midi learn as well, if the master fader has an has changed sending to pass buss(instead of msedwn),
if one midin has changed, the master fader changes and make the data pass to activated subfader, and only, without midi interacting on both subfaders. Ive no midi here to test but im 99percent convinced it works, give a try.