OrderedBytes
OrderedBytes User Forum
FAQ FAQ     Search Search     Memberlist Memberlist     Usergroups Usergroups     Register Register
Profile Profile     Log in to check your private messages Log in to check your private messages     Log in Log in
Solved an old mystery
Display posts from previous:         View previous topic :: View next topic
Post new topic Reply to topic Subscribe to this topic    The OrderedBytes Forum -> ControllerMate Discussion
Solved an old mystery Sat Aug 04, 2018 2:16 am  •   #13670
xltrader100



Joined: 16 Dec 2008
Posts: 236
Location: Canada

I've found what I think is a bug, unless I'm doing something wrong, in which case i guess I'M the bug. So here it is. Actually, I started seeing this years ago and it's been plaguing me ever since with random "stuck buttons", but until just now I didn't know what was causing them and couldn't reproduce them.

The problem is that under certain conditions, the sender and responder units of a virtual button can get out of sync, and stay out of sync for an extended period of time, causing havoc with the logic of the config. This picture illustrates the effect.
https://photos.app.goo.gl/jBoczSbUantQa45LA

The root of the problem is that the responder doesn't start to follow its sender until the sender has gone through a complete ON-OFF cycle. You can see this by opt-dragging out a copy of the sender while it's in the ON state, and then convert the copy to a responder. The sender will still be ON but the responder will be OFF. It doesn't start to follow its sender until the sender first turns OFF and then ON.

If this was the only problem it would be trivial, but the real mischief happens if the sender is Reset while it (and all its responders) are ON. This Reset could come from a Right Click and "Reset all Building Blocks", or it could come from enabling a Page when the pref is set to "Reset items when enabling the Page", or it could come from cycling Master Enable, and probably other places. After any of these Resets, the sender is set to OFF but the responder(s) stay locked ON, and at this point no amount of Resetting will put things right. The only way to get the sender and responder(s) back in sync is to either quit ControllerMate or step the sender through an ON-OFF cycle, but that means I would have to know which responders (of hundreds) are out of sync.

So, end result is that after a Reset, every responder whose sender was ON at the time of the Reset will now be in an incorrect state, and so restarting CM after every Reset is the only way to make sure all the button states are accurate. But even that is not very satisfactory because I might have Pages being enabled and disabled frequently, and if each event triggers a Reset which leaves an unknown number of buttons in an iffy state, then that's not very good.
View user's profile Send private message Reply with quote
Sun Aug 05, 2018 5:39 pm  •   #13674
Ken
Developer


Joined: 27 Mar 2006
Posts: 4049

Do you see this when using any other building blocks besides the virtual source blocks? They are a bit different than the other blocks in that they can affect programming that is not on the same page.

The objective of the "Reset all Building Blocks" function is to reset a group of blocks to a known state without triggering output. To keep both sides of the virtual source blocks synchronized, I would need to extend that reset to other (potentially all other) pages of programming. I'll have to think about how that could be accomplished.
_________________
Ken
www.orderedbytes.com - www.controllermate.com
ControllerMate -- Programming controllers for Mac OS X since 2005.
View user's profile Send private message Visit poster's website Reply with quote
Sun Aug 05, 2018 10:56 pm  •   #13676
xltrader100



Joined: 16 Dec 2008
Posts: 236
Location: Canada

Quote:
Do you see this when using any other building blocks besides the virtual source blocks?


Well, I'm glad you asked. Smile I wasn't aware of any, but when I went poking around looking for an answer to your question, I found a couple more examples of strangeness having to do with Resets. These aren't the Resets we've been talking about but rather the individual component Resets on Toggle and Counter blocks (and maybe others, but these are the only ones I tried).

Firstly, the Toggle https://photos.app.goo.gl/6WcnzNxDxxEnwc236
When this is working normally, the Responder follows the Sender as expected. If the Reset is pulsed when the Toggle and Sender and Responder are all OFF, then nothing bad happens, but if the Reset is pulsed when the Responder is ON, then bad things do happen. The Responder initially turns OFF as expected and everything looks normal, but now when the Toggle input is repeatedly pulsed, the Sender and Responder go in and out of sync.

Same type of problem with the Counter https://photos.app.goo.gl/MsNus5jHrzPczt7Q9
When the Counter input is pulsed repeatedly, the Responder follows the Sender as expected when the Value Selector gets triggered. Likewise, if the Reset is pulsed while the Sender and Responder are both OFF, then everything continues to work normally. But if the Reset is pulsed while the Responder is ON, then not only does the Responder get out of sync with its Sender, but also the Responder starts responding to pulses on the Counter input. It still switches ON when the Value Selector turns ON, however now it also switches ON with (approx) every fourth pulse on the Counter input, even while the Value Selector output doesn't change.
View user's profile Send private message Reply with quote
Mon Aug 06, 2018 12:04 am  •   #13677
Ken
Developer


Joined: 27 Mar 2006
Posts: 4049

OK, so these are both additional examples of the virtual source building blocks being out of sync with each other. Whether the triggering blocks are Counters or Toggles doesn't really affect the underlying problem.
_________________
Ken
www.orderedbytes.com - www.controllermate.com
ControllerMate -- Programming controllers for Mac OS X since 2005.
View user's profile Send private message Visit poster's website Reply with quote
Mon Aug 06, 2018 12:20 am  •   #13678
glennv



Joined: 20 Oct 2015
Posts: 51

This and similar state related problems (i mainly have it with modifiers and midid device objects) has been an issue since day one and the only current way to have a proper known and expected state of all objects is to restart the helper deamon ( obviously with controllermate app closed as always). Specialy if you have a very high object count there is no other way atm to be sure. I stopped using page on / off features as found much less reliable conpared to a hard process respawn.
You can write a little automator app and put that onto your desktop . Thats what i do.
Only after that i connect my controller device(s) that are used in the config so it inits all device objects/states.

A global reset button / feature that imitates this would be handy
_________________
Controllermate based solutions for AKAI APC-40 and Arturia Beatstep to Davinci Resolve
View user's profile Send private message Visit poster's website Reply with quote
Mon Aug 06, 2018 3:56 am  •   #13680
xltrader100



Joined: 16 Dec 2008
Posts: 236
Location: Canada

Quote:
glennv - ... has been an issue since day one ...

I hear ya. I had to completely give up using virtual buttons several years ago because of this exact problem. They were unreliable and totally random (it seemed) in when and where they chose to quit. Now that I know what the problem was, and more importantly how to avoid it, I'm totally stoked about it. I feel like I've a got a whole new arsenal of tools back that were just sitting on the shelf. Because except for that one little quirk (they liked to quit) they worked just fine.

To fill the void left by abandoning virtual buttons I put together a large number of MIDI pair templates to use anywhere that I used to use a virtual Sender/Responder. You do a lot of MIDI signalling, so you might find this scheme helpful. I put each MIDI channel on its own Page for easy indexing. For instance, here's Channel 7.
https://www.dropbox.com/s/8p5zii75b47e2jo/MIDI%20Ch-7%20mated%20pairs.cmate?dl=0

Each separate part of your program can work with it's own channel number and this really helps in keeping track of what each block does. Just looking at a block's ch# can tell you a lot about its function. Also, it's a plus that with almost no extra effort you're maintaining an up-to-date list of all the MIDI pairs in use, by name and number, all in one place. The Page shouldn't be enabled.
View user's profile Send private message Reply with quote
Tue Aug 07, 2018 2:45 am  •   #13682
glennv



Joined: 20 Oct 2015
Posts: 51

Yeah i moved from a crazy wire spaghetti way of programming to using (virtual or hardware tied) midi objects with modifiers . The AHAAAAA moment i had then was amazing and cleaned up my code and allowed it to grow to its insane size now.

I dont have such a nice and absolutely beautiful administration page as you provided here . I did start that way when i initially used them in pairs like you, but quickly lost it and specially when i found out it does not matter if you double triple or 10000x use the same virtual/hardware tied midi object for other stuff in the way i use it currently. I typicaly dont use it for actually recieving midi from its paired partner but just for changing state based on modifiers. That way the midi channel/value is not relevant as long as i pick one that is not actually used for a real midi message i use elsewhere. So typicaly pick a note on the highest octave or similar.
I do that because i need to keep track of all states continuously and relative to each other and midi itself is just not the best way to do that. That just gives you state changes in pulses (on/off ) but not actual current state (unreliable at best and whe high midi traffic/system load easily lost or delayed/buffered). But the virtual/hardware midi objects can be (ab)used for keeping track of thousands of absolute direct modifier states with ease all over the place, cross pages. And i then just label in place to indicate the function(s) it monitors. And absolutely rigorously properly label the modifiers.

So lots of possibilities if you just take care of a proper way to init all these states as mentioned with a process restart. But the results as you have discovered now as well are beautiful low cable-count connections. Powerfull stuff (tnx Ken !!!)
View user's profile Send private message Visit poster's website Reply with quote
Page 1 of 1 All times are GMT - 6 Hours
Post new topic Reply to topic Subscribe to this topic    The OrderedBytes Forum -> ControllerMate Discussion
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Copyright © 2005 — 2012 OrderedBytes
All rights reserved.