Blinking Status Leds? [solution explained]

[MarKo]

Hi Alexey,

As i´m beginning to understand and implement the power of "states", i came up with an idea that i could not implement now.
Perhaps it´s already possible in some way, but i did not find a solution?

Example: i have a sw-state "shift", which has not 2, but 3 states (off, 1-time, locked).
So pressing shift causes the next action to be a "shifted" action, while pressing shift a second time will lock the shift-state until it´s pressed again.
Of course i have now more states than button-leds, so my idea was to use blinking leds to show different states.
I tried some things, but could not find a way. I think it could be possible, if function-calls could be executed after some time (as it´s now in triggers: x cycles, 1 second,..).
I would even use different blink-rates (slow/fast) to show more conditions.
E.g. you could have the "Play-Led" to indicate Loop-Mode with slow blinking, while fast blinking would show "Record".
Or the mode switch Tracks/Bus/ACT could be shown that way.

What do you think?
If it´s not already possible - could this be implemented?
I´m thinking of new values in the feedback, where you would choose instead of "value" - "blink-slow", "blink-fast".

And again, i have to thank you for this masterstroke and remind that i really want to donate something

[azslow3]

Hi,

I attach "PlayLed" preset so I do not have to type it here and you do not have to follow my text...

It should produce:
* no light in stop (loop independent)
* continuous light in play without loop
* slow blinking in play with loop
* fast blinking in record (loop independent)

To test it, reassign MIDI for PlayLED control (in the Hardware tab, select PlayLED, "Forget MIDI", press your pad, "Assign MIDI"). This button does nothing in that example (but it can do whatever it should). Note that example use one Pad with LED, MIDI signal to light is the same as the MIDI signal it sends when pressed. Just modify MIDI sends if required (4 actions in PlayLED Monitor).

And here is the explanation:
* Transport System control (without MIDI assignments) just has 2 Monitors, for Transport and Loop. They both have the same action: trigger PlayLED Timer Monitor. We could skip Loop monitor, but in case you turn on Loop during playing LED will not start blink. Every time Transport or Loop states are changed, I simply ask PlayLED Monitor to react (note "now" option, "as usual" will produce no effect, since usually that "timer" never triggers,).
* PlayLED has MIDI assigned. That is not a requirement, but "<Use Ctrl MIDI>" was handy in my case. The control has just one timer. That "Timer" has speed "Once". It is not triggered periodically, we do not want it triggers when we do not need blinking (in stop and not looped play).
* In the PlayLED Timer (which is not really a timer as I have explained), I:
1) check "Stop" state, and turn off LED. Final state. No other monitoring will go on till triggered from Transport Monitor.
2) check "Play" with Loop Off, and turn LED on. Final state. No other monitoring will go on till triggered from Transport Monitor.
3) Turn LED on/off dependent on "Play LED State". It is user defined State Set with just 2 states, On and Off.
4) Change "Play LED State" to opposite, note "Loop" and "Set engine state" flags (without first it will not move from On, without second it will not be saved between monitor calls).
5) Dependent either we are in "Play" or in "Rec" (we already know we are in "Loop" if we are in "Play", since "Play" "Without loop" was already configured, with "Final" flag) we retrigger ourself(!) with required delay.

I guess you need as many such configurations as blinking buttons in your setup. MIDI signals, conditions to blink, may be even blinking speed are going to be different.

If you "Tweak configuration..." to the Faderport preset, you can see how I do "Shift". I distinguish between "Shift"+Something  (ShiftUsed StateSet) and "just" Shift (which Lock/Unlock). That way it is possible "temporarily unshift" as well. A kind of combined in one key Shift and CapsLock solution.

[MarKo]

You are really GENIUS!!!

This is exactly what i was trying to do.
Although i assumed it should be possible in a similar way, i did not find it.

Now i have to spend some more hours trying to completely understand how you are doing it.
I think i´m still missing something about the event-flow and what/when gets triggered.
But with your explanations (i have to re-read them very slowly) i hope to get it.

I also had a look at your "Shift" implementation, i´ve seen details there that will also need some time to make it into my brain 

If i may ask for just a little change - that´s the blink-frequency.
I changed it to 1/2 cycles, because 1 sec was to slow for me, but that is also not optimal, maybe just adding options for 3,4 cycles would be nice.

Many, many thanks again for the best ever ControlSurface and also the time you spent on my wish.

[azslow3]

Now i have to spend some more hours trying to completely understand how you are doing it.
I think i´m still missing something about the event-flow and what/when gets triggered.
But with your explanations (i have to re-read them very slowly) i hope to get it.

SONAR call plug-in under 2 conditions only:

• Some MIDI event is received
• ~13 times per second, independent from the MIDI input

"Logic" actions list is what is executed on MIDI events (in the first case).

13 times per second I check system states (what transport is doing, etc) and then execute Monitors (Feedback) which are "armed". State monitors are armed for next cycle once the state is changed and not armed otherwise. Other monitors arm "cycles" are configured in the Action. And there is "Reset Monitor", which arm Monitor explicitly.

I forgot to mention (and set) other important parameter. Priority. Set priority of Transport monitors to 0 and priority of PlayLED to 1. That way you can be sure that in case the transport state is changed, LED start light within 1/13 of second, not 2/13 ( 1/13 till I detect the change + 1/13 after Monitor reset, in case LED Monitor WAS already executed BEFORE state check monitor in the same cycle). But that is really "fine tuning".

If i may ask for just a little change - that´s the blink-frequency.
I changed it to 1/2 cycles, because 1 sec was to slow for me, but that is also not optimal, maybe just adding options for 3,4 cycles would be nice.

Download the latest version 

In case your head still ready to accept even more "programming". You can do "not regular" blinking as well. Add another state to "Play LED State", call it "Nothing". You should see the effect (no other changes required). In the PlayLED Monitor, change condition "Play LED State:ON" to "Play LED State:Nothing". You get one more blinking "pattern".

[MarKo]

SONAR call plug-in under 2 conditions only:
...

Thanks for the explanations, the picture gets clearer now!

If i may ask for just a little change - that´s the blink-frequency.
I changed it to 1/2 cycles, because 1 sec was to slow for me, but that is also not optimal, maybe just adding options for 3,4 cycles would be nice.

Download the latest version 
In case your head still ready to accept even more "programming". You can do "not regular" blinking as well. Add another state to "Play LED State", call it "Nothing". You should see the effect (no other changes required). In the PlayLED Monitor, change condition "Play LED State:ON" to "Play LED State:Nothing". You get one more blinking "pattern".

Man, you are so fast - terrible!

And ok, it´s time now to admit that i´m a programmer myself (a bit ashamed that i have to ask things which seem so logical to you).
But i´m more into GUI-stuff (mostly classic VB6), and one of the key-points i learned is that´s the hardest part to transport the logic of a program/programmer into a nice intuitive GUI for the average user.
In NO way that should sound critical - i know it´s a fun project and how uncountable hours you must have spent.
And i would not know of a much simpler solution either, without spending similar hours.

But i could imagine to help some day eg. with a nice Display-GUI, if you expose it via COM...
i don´t know if this makes sense, perhaps it get´s even more complicated for you.

[azslow3]

But i could imagine to help some day eg. with a nice Display-GUI, if you expose it via COM...
i don´t know if this makes sense, perhaps it get´s even more complicated for you.

Thank you for willing to help, but....

• You have programmed VB6, but are you ready to write VB6 itself, so that it is "average user" friendly? AZ Controller is an interpreter, the GUI is its IDE.
• While AZ Controller is free to use, it is not open source. And I do not want violate any licenses. So I could not use any GPL GUI for example. And I do not want spend money for commercial staff.
• To make it long living and lightweight, I do not use ANY library at all, except Windows RunTime (unavoidable, but pretty stable).
• I am not fun of nice looking GUI. I still program in Emacs for Linux. AZ Controller is developed in Geany.
• As you can see, I implement new featured pretty fast. If I need new combo, I just add it. Any intermediate layer (like COM) is going to slow down the development (and introduce something which can be buggy). The GUI you see is historical, there was no plans to make the plug-in so powerful as it is now. And I have no idea how far I am going to go with it.
• After the preset is configured, you do not need the interface. So I do not think its old style is so disturbing.
• Most users are waiting for "ready to use" preset. My "build-in" presets are generated from C code, not inside the GUI

In general, every time I think to improve look/fell of this GUI, I remember all that and decide to implement yet another useful controller feature instead 

[MarKo]

Thank you for willing to help, but....

i completely agree with all your arguments and hope you did´nt get me wrong!
as i´ve said - in no way that was meant critically, maybe you misunderstood.
i was just talking about the display (the matrix), because i´ve seen that in other plugin.
this guy also spliltted the real plugin (C++) from just the display (VB6), because it´s much easier to get relativelly nice GUI.
I was not talking about the plugin-gui itself (the logic part) - that seems impossible, since you see that i have even problems in using it with all it´s possibilities.

[azslow3]

Sorry, my fault.

Yes, Display (what is now is text matrix) should be reworked at some point.

In todo list I have support font selection, bg and fg colors and may be bg image

But what could be really nice is a (WYSIWYG) editor (think of dialog editor) with the following elements:

• Label (static)
• Text (what you see now)
• Border (panel)
• Image
• "Knob"
• "Fader"
• "Switch" (to display state graphically)

Unfortunately, taking (2) and (3) into account that is not a one week job.

[MarKo]

I would not say that a nice display is SO important, but it´s always something people look at.
In fact, i´m not using it that much, so for me personally i would´nt spend too much either.
i like more to look at the surface itself (BCR) and see alle important states, instead of looking up to the monitor (although i have a second one there).

But now, maybe a dumb question - i see no way of copying/pasting between diff. Presets - is this possible? and another related question: to copy a whole list of actions, nothing has to be selected. How to do that? i found no way "de-selecting"

[azslow3]

I would not say that a nice display is SO important, but it´s always something people look at.
In fact, i´m not using it that much, so for me personally i would´nt spend too much either.
i like more to look at the surface itself (BCR) and see alle important states, instead of looking up to the monitor (although i have a second one there).

I use it in ACT mode to see which parameters are mapped.

But now, maybe a dumb question - i see no way of copying/pasting between diff. Presets - is this possible?

Unfortunately there is no such possibility. In todo list is "copy/paste" to/from text. I have to implement "text form" of internal format for that. My todo list is so long...

and another related question: to copy a whole list of actions, nothing has to be selected. How to do that? i found no way "de-selecting"

In Logic actions, temporarily select another control. In Monitors it is not possible, but if you copy monitor is the Logic its action list is copied as well.

[MarKo]

I use it in ACT mode to see which parameters are mapped.

i see, in ACT mode the display is more neccessary.

Unfortunately there is no such possibility. In todo list is "copy/paste" to/from text. I have to implement "text form" of internal format for that. My todo list is so long...

it´s ok, i was just not sure if i overlook something.

In Logic actions, temporarily select another control.

hm - i have tried that before and it does not work, but i found now another way:
if i temp. select a different preset, then the action-list gets deselected.

[azslow3]

In Logic actions, temporarily select another control.

hm - i have tried that before and it does not work, but i found now another way:
if i temp. select a different preset, then the action-list gets deselected.

I use that all the time... Select another control, select the source one (not click any action in it!), press Copy.

[MarKo]

In Logic actions, temporarily select another control.

hm - i have tried that before and it does not work, but i found now another way:
if i temp. select a different preset, then the action-list gets deselected.

I use that all the time... Select another control, select the source one (not click any action in it!), press Copy.

Sorry, too stupid, i was reading "select another control" in terms of windows-control, but did not think of Az-control! Of course it´s working that way, thank you.

[azslow3]

Small tip for that: since using some control switch Logic tab to this control, you cat press/turn "from" control, "Copy", press/turn "to" control, "Paste". That is a bit faster then changing controls in the drop box (especially if you have long list). We are configuring the Control Surface for faster operations, we can use it to accelerate the configuration as well 

[MarKo]

ok, the last tip was good!
Unfortunately i had not much time the last week, so i got a bit stuck.
But i´ve already managed to implement many things like i want.

and i think i had a nice idea for my rew/ff buttons:
to get more possible actions with these 2 buttons, i can press them now also together - but in different order!
while this may sound complicated, i think it´s a quite intuitive way (at least for me).

so: rew/ff-buttons pressed alone act like normal (rewinding/forwarding while hold down)
but pressing left button(rew), and then together pressing the right button(ff) does "marker back".
same the other way: first pressing(holding) the right(ff) button, then together the left(rew) does "to next marker".
of course, rewinding starts (shortly) while i press the left button, but that does not matter, because the next marker is always more far away.
this is additionally to the "shift"-functions! so 2 more useful actions directly available, which are "nice to press".
i´m currently trying if it´s better to have 1 measure back/forw on this 2-button-presses, and using Shift for the markers,
but the concept should be clear and is expandable to other/more buttons and actions of course.

so i thought about sharing the idea in form of a preset, because your example for the blinking Led´s was really helpful
(i think better than a complete preset, which is not simple to understand).
but my preset as a whole is far from complete and would cause more confusion then help -
so is there a way to get only some selected logic exported?
copying the preset and deleting the rest is even more work than creating it new.

And because the thread is still about Status-Led´s another question:

i´ve got 2 Led´s, which i want to show the "WAI"-position.
e.g. for WAI 1-8 i want Led1, for WAI 9-16 i want Led2, for 17-24 both,...
(could be expanded with blinking, but 32 tracks is enough for now)
how do i get the WAI-position into a state?