block CC and PG for A CERTAIN AMOUNT OF TIME

Oh, you do like to challenge things!

You can do this using the hold function in the Stream Byter with scene changes.

First, in the scene that triggers the scene change when receiving the controller. Let's call it 'Trigger' and assume it is at slot 000. Let's assume that the scene you switch to is in slot 001. You don't say which controller # you are using. For my example I am going to use hex 71, which on my test keyboard sends a 7F on press and a zero on release. To use this trick, your controller must do the same (ie. it should send 7f and 0 only and not continuous values).

First make sure the current scene is 000 (Trigger)

The Stream Byter rules in your trigger scene probably look something like:

# switch to scene 1 when CC 71 pressed
BX 71 7F = CF 01 +C

Now, change that rule like so:

# switch to scene 1 after 2 seconds
BX 71 = CF 01 +H2000
BX 71 7F = CF 02 +C # switch to scene 2 immediately

Install rules and update that scene, now load scene 1 (the one you normally switch to when you trigger)

Modify the Stream Byter rules to add everything you want blocked using +B rules, for example:

# block cc 71 and all PG changes
BX 71 = XX +B
CX = XX +B

Press 'Install Rules' and save to scene 2 (new scene!)

What will happen is that when you trigger the controller, it will switch to scene 2 which has all those block commands to suppress any further controller/program changes and 2 seconds later it will switch to scene 1.

Naturally your rules are going to vary because you probably use a different controller, channel and so forth, but the concept is to use the hold flag to switch to your 'normal' scene n seconds after you trigger the change to an intermediate scene with the block rules.

Regards, Nic.

sorry sorry

it works!
...of course, how could i doubt it. i just had to take away the "7F" from the delayed PG.

thank you very much again. this has helped me a lot to improve the accuracy and quality of my performance!

david

(edited)
i just hadn't checked all connections to be the same!

one more question: how can i send the same value x3 times?
i have tried

BX 4D 7F = CF 0A +C
BX 4D 7F = BX 12 7F
BX 4D 7F = BX 46 7F
BX 4D 7F = BX 12 7F +D100
BX 4D 7F = BX 12 7F +D200

but the last delayed rules are not received.

thanks

david

mmmm... excuse me nic. but i don't understand... i see that to make a repetition work i need to take away the flag 7F from the event that is received... but in the example of the ramp you made for me, the resulting code of all those CC repetitions has the "7F" flag.

also i have got the problem that if i don't put it, it also will react to the CC 00, and i only want this rule to be performed when the CC is 127.

is there any documentation or examples about this repetition thing and it's logical rules?

many thanks again.

david

Hi David,

I should have been more specific about what I meant. Here is how I would change your rules so that all the events (not just the first one) get sent

BX 4D 7F = BX 12 7F +C
BX 4D 7F = BX 46 7F +C
BX 4D 7F = BX 12 7F +D100 +C
BX 4D 7F = BX 12 7F +D200 +C
BX 4D 7F = CF 0A +C

The reason I added a +C (clone) is because without it the first rule (BX 4D 7F = BX 12 7F) is rewriting that event to Bn 12 7F and because the event has been changed it will no longer match on the next rule since it is now a 12 controller and not a 4D controller. I also moved the rule that triggers the scene change after the others, just to be safe so that those events get sent before the scene change.

BTW, the only time you are forced to remove the (third byte, eg. 7F) is if you are using a +H flag in your rule.

I'm pretty sure I updated the built in doc with the pure detail of the new flags (+H) and posted here somewhere too. 

I will come clean and admit that the Stream Byter was developed so I could add 'unusual' features remotely for customers without having to write C code and go through the App Store update process.

I'm really (pleasantly) surprised that quote a lot of people have taken to writing their own rulesets, but I remain here to help where I can as I know it isn't straight forward!

Regards, Nic.