MIDI Kinetics Forum

Hey there,
i hope i can explain my problem in a way that everyone understands...

- i have 2 different tabs
- a switch-object in every tab
- when i switch on switch1 in tab 1, switch2 in tab 2 should also be switched on and a message (for example 'hello') should be sent to for example Max/MSP
- visa versa: if i switch on switch2 in tab2, switch1 in tab 1 should be switched on also....

if i do so, i create a loop....cause switch1 always triggers switch2 which triggers back switch1 which triggers back switch2 and so on and so on....
i absolutely need to put the state of each switch to '1' when the other one is triggered cause otherwise when i for example trigger switch1 and just send a message to switch2 to change the color, i wouldn't have a '0' message next time i switch off switch2....

so shortly: how do i change the state of another switch without this switch sending out the state-message.....(in Max/MSP it would be something like using a 'set' or not using a 'set' message').

is this possible with Lemur?

sorry, i know it sounds complicated...

thanx so much anyway

greetz
Peer

i solved the problem

thanx anyway

cheers
P

no, not really solved...i created another loop which works fine but which is IMHO still a loop....maybe u can post your ideas about that...

thanx
Peer

So, is it essential that the second switch doesnt send a message when its state changes by switch 1 ? Because, in Lemur, there really is no loop created.

Example:
two switches, switch1 and switch2

Lets say we have a script in each switch

switch1, on expression x, any switch2, on expression x, any The two switches are now "connected". Lets say both are off and we turn switch1 on.

The script executes so it turns switch2 on and it sends its message. But then the script in switch2 is executed so it tries to set switch1 on - BUT which is already on. AND HERE is where the "loop" is stopped - no further message is sent. Because switch1 is already on, no loop is happening.

IF however you still dont want the switch2 to send its message when turned on by switch1, then you need to set up some custom expression - BTW, if your two switches are identical in size and color, consider using an alias. If you rather prefer different ones, I can provide you an example with custom expression to do what you want so let me know.

wow...that's cool...i didn't know that the loop stops...then there is no problem of course ..i was just thinking that Max/MSP doesn't show me any loop but that some internal loops will take place within Lemur which could cause a crash or strange behaviour sooner or later....

2 things:
1) could u tell me more about the 'using an alias' solution please ?
2) it would be nice if you could send the example with custom expression of which you are talking - if it's not too much work for you.
even if i won't use it - it always gives me new ideas and new point of views if i read somebody else's scripting...would be very kind of you, really....

thanx, thanx, thanx !

Peer

Looks like you are eager to learn so I'll happily help...first of all...why the loop stops....

pay attention to WHEN the script is executed

"on expression x, any"

this essentially means "when the x makes ANY change"

So, if the button is on (x=1) and we instruct it (via an outside script) to set x to 1, theeeeeeen.....x stays the same (it was 1, we set it to 1)....so.....the script is not executed. (there is no loop).



aliases: right click on a switch - click on "create alias". A "duplicate" switch will be created which will be similar in size, color and everything else - its in fact a second "manifestation" of your switch. Aliases are handy when you want the same element in your Lemur templates to appear more than once (in different containers, or even in different interfaces-pages). For unknown reasons, this very handy feature is not mentioned at all in the Lemur manual.

about the custom expression...I'll be back!

Ok now here's an example. It uses pads although they behave as switches. The difference with using two actual switches is that when the second Pad is turned on via the first one, it does NOT send its message out - it just turns on visually. This is achieved by using the custom expression t for both the pads (which is set to alternate between 0 and 1, essntially making the pads behave like switches). We also use the custom t expression to "light up" the pad (so that it looks like a switch) by using

light = t in both of them.

We then use a "scripted" output (ctlout function) which will only function when the pad is pressed (on expression x, rising from zero). You could similarly use the oscout function fi you are planning to use OSC instead of midi. The downside? No bi-directional communication (no feedback) - unless you also script it yourself that is.

In simple words, these two "connected" pads-switches only send midiout when they are individually pressed but not when they are turned on-off from an outside script.

hey there,

this is all some great information.....i can't thank u enough !

i think the aliases trick can save some programming in certain situation.

about the example....it's fantastic...i come from JAVA and maybe i'm not busy long enough with that programme, but I don't understand:

if(t==0) t=1;

why don't u have to wright:
if (t==0){
t=1};
else{
t=0;
)

i don't understand why you have to set t=0...it means: x = t = 0 and this value is changed anyway when u change the x value. i think i don't understand a basic thing concerning expressions

p.s.: the trick to set light to t is fantastic...thanx so much !!

Ok first of all
can be written because there is only one argument after the if-else statements so there really is no need for the {}.

______________________________________________
SIDE NOTE:

Keep in mind the same thing can also be written as:
or even
Generally speaking,
if(x) is true for any x!=0
if (!x) is true if x=0

END OF SIDE NOTE
______________________________________________________

The t=0 you see in blue, initializes our custom expression t to be zero every time the project-template is loaded. After that, the above scripts make sure that t goes 1 after a press of a pad, then 0 and so on and so on. NOTICE that we use a pad (x=1 when the pad is pressed, x=0 when the pad is released).
To achieve the switch functionality, we have set the script to execute

"on expression x, rising from 0 (up arrow)"
This essentially means "everytime the Pad object is pressed" - the release is ignored by the script (when we release the Pad x goes from 1 to 0)

The reason we bother with all these things (and we dont use native switch object) is that we want to seperate the script trigger (the x triggers the scripts and sets the t value) and the actual on - off state (t value). This way, we can change each Pad's t (what we now consider to be its on-off state) without affecting the Pad's x, therefore without triggering the scripts. Notice, for example that in the script of Pads1 we have:
This changes the on-off state of Pads2 object WITHOUT causing its script to be executed (because the script is set to execute on expression x, NOT on expression t)

disclaimer: there might be a faster, easier way to achieve all this - take note that Im not a professional programmer and as such, the above are only what I could (at the spur of the moment) think of as a solution to our "problem".

super all that !
now i got it i guess:
x is assigned to the expression t which get's the value 0.

if the script is triggered on the expression x, x is assigned to t and if so, to the number '0' which we set as default.
if so, (if x is triggered) t==0 and we assign the value 1 to t which lights the other switch.
honestly i get an x output within max/msp. but that problem is easily solved if you just disable the output of the variable within the object.
and then it's just
oscout(0, '/i_think_i_understood/value',t);



thanx again for all your help !
have a great week.
cheers
P