persistent, display-only GUI, that doesn't pause?

[dkh]

i must be missing something very simple, but i've been banging my head on this for awhile.

i just need to post some info the screen, with appropriate background colors, at various times while running my scripts.

so, i was hoping i could create a function such as this:

Func say($top_text,$top_color,$bottom_text,$bottom_color)

which i could use in other scripts and functions.

the problem is that, even with Opt("GUIOnEventMode", 1), the presence of the GUI delays the script that calls it, and blocks additional scripts.

ideally, the GUI would be persistent and not block any other scripts. this seems like it should be trivial, since i'm not using the GUI for any sort of inputs at all; it is simply to display info and be updated, even if just by deleting it and displaying a new one.

any ideas??

thank you!

david

[Melba23]

dkh,

There is no reason why merely displaying a GUI should delay the script, nor stop other scripts running. Do you have a While...WEnd or similar loop in your script which is preventing the script from continuing once the GUI is displayed?

Here is a short script which shows a label being updated as the script runs - perhaps something like this might be of use:

#include <GUIConstantsEx.au3>

$hGUI = GUICreate("Test", 200, 200)

$hLabel = GUICtrlCreateLabel("We are just starting", 10, 10, 180, 20)

GUISetState()

$ibegin = TimerInit()

While 1

    Switch GUIGetMsg()
        Case $GUI_EVENT_CLOSE
            Exit
    EndSwitch
    
    Switch TimerDiff($ibegin)
        Case 5000 To 5050
            GUICtrlSetData($hLabel, "5 seconds gone")
        Case 10000 To 10050
            GUICtrlSetData($hLabel, "10 seconds gone")
    EndSwitch

WEnd

If you need more help, please post the code which is giving you the problem.

M23

[dkh]

thanks for that example! i've changed it here to explain what i'm trying to do, and the problem i'm running into.

* i turned the GUI code into a function called "print_info"

* i then use the function call in a simple script

* but the script waits for the function call (e.g., the GUI) to complete before running

expandcollapse popup

#include <GUIConstantsEx.au3>

print_info("FIRST")

MsgBox(0,"","my objective is to have this start " & _
    @crlf & "- RIGHT AFTER the print_info call - " & _ 
    @crlf & "rather than wait for an ESC")

print_info("SECOND")

MsgBox(0,"","ideally, the print_info would show until " & _
    @crlf & "the next print_info(), even after this script " & _
    @crlf & "completes!  this really may be asking too much!!")

Func print_info($say_this)
    
    Opt("GUIOnEventMode",0)
    Opt("GUICloseOnESC",0)
    
    $hGUI = GUICreate("Test", 200, 200)
    
    $hLabel = GUICtrlCreateLabel("We are just starting", 10, 10, 180, 20)

    GUISetState()

    $ibegin = TimerInit()

    While 1
    
        Switch GUIGetMsg()
            Case $GUI_EVENT_CLOSE
            ;Exit
                Return
        EndSwitch
        
        Switch TimerDiff($ibegin)
            Case 1000 To 2000
                GuiCtrlSetBkColor($hLabel,0xFFC000)
                GUICtrlSetData($hLabel, "2 seconds gone " & $say_this )
            Case 2000 To 2050
                GuiCtrlSetBkColor($hLabel,0xBFBFBF)
                GUICtrlSetData($hLabel, "3 seconds gone " & $say_this )
        EndSwitch

    WEnd

EndFunc

I suppose that this is not the model that was imagined when creating the GUI functionality, but it seemed that OnEventMode=1 was attempting to speak to this.

Here is the context:

* this is a music performance script that takes a song playlist as input and opens each song in alternating instances of my music app (Ableton Live) so that I can perform a continuous set, rather than having to wait in between songs to close the Song 1 file and open up the Song 2 file (wouldn't make for a very continuous dance experience).

* the key functions right now are LOAD (the next song), SWITCH (to the next song), PLAY. of course, this involves a bunch of switching windows and waiting for closing etc, so i'm trying to "print" status type info for the two instances of Ableton to my screen with bright colors, so that I can see it easily while continuing to play my instruments.

* a developer friend of mine said that it's best to avoid big, ongoing loops (if possible), but rather have discreet chunks of functionality that can do their thing independently. so I have a script called LOAD, one called SWITCH and one called PLAY, each of which I can trigger from a MIDI foot controller.

This was all going fine until i got to the GUI part!

Perhaps this is a solution though:

1 - i create a script that runs all the time which has defined the GUI itself

2 - i have a function call that sends out only GuiCtrlSetBkColor and GUICtrlSetData to the named ControlID's in the named GUI

Is this on the right track? Is there a more elegant solution I'm missing?

Thanks!!

David

[Melba23]

dkh,

Take a look at this - is it getting somewhere near what you want?:

expandcollapse popup

#include <GUIConstantsEx.au3>
#include <StaticConstants.au3>

$hGUI = GUICreate("Test", 500, 500)

$hLoad   = GUICtrlCreateButton("Load",   10,  10, 80, 30)
$hPlay   = GUICtrlCreateButton("Play",   10,  50, 80, 30)
$hSwitch = GUICtrlCreateButton("Switch", 10, 200, 80, 30)

GUICtrlCreateLabel("Ableton 1",         200,  10, 100, 20)
$hActive_1 = GUICtrlCreateLabel("",     200,  30, 290, 200)
    GUICtrlSetBkColor(-1, 0x0000FF)
$hAbleton_1 = GUICtrlCreateLabel("Status", 220,  50, 250, 160, $SS_CENTER + $SS_CENTERIMAGE)
    GUICtrlSetFont(-1, 24)
    GUICtrlSetBkColor(-1, 0x00FFFF)
GUICtrlCreateLabel("Ableton 0",         200, 240, 100, 20)
$hActive_0 = GUICtrlCreateLabel("",     200, 260, 290, 200)
$hAbleton_0 = GUICtrlCreateLabel("Status", 220, 280, 250, 160, $SS_CENTER + $SS_CENTERIMAGE)
    GUICtrlSetFont(-1, 24)
    GUICtrlSetBkColor(-1, 0x00FFFF)

GUISetState()

$fAbleton_Action = True

While 1

    Switch GUIGetMsg()
        Case $GUI_EVENT_CLOSE
            Exit
        Case $hLoad
            If $fAbleton_Action Then
            ; Ableton 1 loading code
                GUICtrlSetData($hAbleton_1, "Loaded")
                GUICtrlSetBkColor($hAbleton_1, 0xFF0000)
            Else
            ; Ableton 2 loading code
                GUICtrlSetData($hAbleton_0, "Loaded")
                GUICtrlSetBkColor($hAbleton_0, 0xFF0000)
            EndIf
            
        Case $hPlay
            If $fAbleton_Action Then
            ; Ableton 1 play code
                GUICtrlSetData($hAbleton_1, "Playing")
                GUICtrlSetBkColor($hAbleton_1, 0x00FF00)
            Else
            ; Ableton 2 play code
                GUICtrlSetData($hAbleton_0, "Playing")
                GUICtrlSetBkColor($hAbleton_0, 0x00FF00)
            EndIf
            
        Case $hSwitch
            
        ; I am not sure what you mean by "Switching"
        ; but I imagine you want change the value of
        ; $fAbleton_Action so the correct instance was selected
        ; ready for the next action
            
            $fAbleton_Action = Not $fAbleton_Action
            If $fAbleton_Action Then
                GUICtrlSetBkColor($hActive_1, 0x0000FF)
                GUICtrlSetBkColor($hActive_0, 0xFFFFFF)
            Else
                GUICtrlSetBkColor($hActive_1, 0xFFFFFF)
                GUICtrlSetBkColor($hActive_0, 0x0000FF)
            EndIf
        
    EndSwitch

WEnd

If not - give me some more clues!

M23

[GaryFrost]

_Timer_SetTimer

[dkh]

that's definitely right in several key ways, but i need the colors and text to change as part of the other scripts being run. the example you provide (and indeed, all the examples in the documentation) seems to assume a GUI-input-centric model. my input is a foot controller, and i'm just trying to have my scripts update two color boxes on the screen as the scripts run along. it's kind of inside/out.

here's an example use case:

a- i click a foot pedal, sending a midi msg which triggers LOAD.au3 (e.g., no GUI involved)

b- LOAD calls a function called "swap_song" (as part of a Select/Case), passing it current variable values:

swap_song($priorSong,$priorInstance,$loadSong,$loadInstance)

c- "swap_song" then does a bunch of stuff, occasionally calling a function called "say", which is supposed to update the text and bkcolor of the two label controls in the gui. note that say() is called repeatedly within swap_song():

expandcollapse popup

Func swap_song($song_to_close,$instance_to_close,$song_to_open,$instance_to_open)
    
    ;close old song
        
            If $song_to_close = "dont know" Then
                
                Exit
            
            Else

                say($currentSong,"olive",$song_to_close,"grey")
                
                WinActivate($instance_to_close)
                
                say($song_to_close,"grey",$currentSong,"olive")
                
                WinWaitActive($instance_to_close)
                
                Sleep(500)
                Send("{SPACE}")
                Send("^s")
                Sleep(500)
                Send("^w")

            EndIf
        
    ;open new song
                    
            If $song_to_open = "none" Then
                
            ;do not open anything
            
            Else

                WinActivate($instance_to_open)
                WinWaitActive($instance_to_open)                            
                Sleep(500)
                Send("^o")

                say($song_to_open,"red",$currentSong,"olive")
                
                WinWaitActive("Open Document:")
                sleep(500)
                Send($songDir & $song_to_open)
                Send("{ENTER}") 
    
            EndIf

    ;re-activate currently playing Instance
    
            WinActivate($currentInstance)
            WinWaitActive($currentInstance)
            set_instances()
            
            say($currentSong,"green",$loadSong,"yellow")

EndFunc

given that there are so many changes throughout the script, it probably does not make sense to try to break everything down from a gui object level, then reassemble the flow that way. i really just need some graphical equivalent of "print line" or print to console.

here's an approach i'm trying now and the text updates are working - and it is NOT delaying the script - but I don't know how to do the color updates.

To get the text working I'm using ControlSetText instead of GUICtrlSetData, which seems to get around the delay problem. But, i don't know what the color "equivalent" of ControlSetText is!!

Here's the approach:

1. create a gui, never mind about events coming from the GUI, because there are none.

Func setup_gui($gui_loop,$top_label,$bottom_label)
    
;specify location & sizes
    
        Local $width = 500
        Local $height = 80
        Local $left = 1000
        Local $top = 0
        
;create gui
        Opt("GUIOnEventMode", 1)
        $gui_loop = GuiCreate("huffhead",$width, $height,$left,$top,$WS_POPUP)
        GUISetOnEvent($GUI_EVENT_CLOSE,"close_gui")
        GUISetState(@SW_SHOW)
    
;create labels
    
        GUISetFont(16,700)
        
        $top_label = GuiCtrlCreateLabel("label 1",0,0, $width, $height/2)
        $bottom_label = GuiCtrlCreateLabel("label 2",0,$height/2,$width, $height/2) 
    
;show control info
    
;~      MsgBox(0,"","$gui_loop =" & $gui_loop)
;~      MsgBox(0,"","$top_label ControlID =" & $top_label)
;~      MsgBox(0,"","$bottom_label ControlID =" & $bottom_label)
    
;hang out
        While 1
            Sleep(1000)
        WEnd
EndFunc

however: i haven't figured out how to get the GUI handle or ControlID's out of this function and available to other functions. i made them global variables, but for some reason when i try to read them after running setup_gui, they are blank! any ideas?

2. have a different function that can update the controls

Func say($top_text,$top_color,$bottom_text,$bottom_color) 

;update colors
    
;~  ;top 
;~      $top_color_number = _ArraySearch($colors,$top_color)
;~      $top_color_hex = $colors[$top_color_number][1]
;~      GuiCtrlSetBkColor($top_label, $top_color_hex)

    ;bottom 
;~      $bottom_color_number = _ArraySearch($colors,$bottom_color)
;~      $bottom_color_hex = $colors[$bottom_color_number][1]
;~      GuiCtrlSetBkColor($bottom_label, $bottom_color_hex)
    
;update text
    
;~      GUICtrlSetData($top_label,$top_text)
;~      GUICtrlSetData($bottom_label,$bottom_text)

        ControlSetText("huffhead","",3,$top_text)
        ControlSetText("huffhead","",4,$bottom_text)


EndFunc

Note that:

1. I'm using "3" and "4" for $top_label and $bottom_label because i can't figure out how to get those variables out of setup_gui() and into say()

2. GUICtrlSetData just doesn't work. I tried those in the same situation. no go.

3. Same with GUICtrlSetBkColor()

Is there a color equivalent ControlSetText like "ControlSetBkColor"?

Does this all make sense?

(Thanks by the way, for your generous attention!)

Dave

[Melba23]

dkh,

A lot clearer.

A major part of your difficulty was because you were declaring your setup_gui() function expecting parameters in the calling statement:

Func setup_gui($gui_loop,$top_label,$bottom_label)

I assume you declare these variables as Global elsewhere in your script.

The controls of the same name you create within the function are only Local in scope (even though they have the same name) because they have been declared as parameters in the function. So once the function ends, the named variables revert to the Global values you declared initially (probably undefined). I hope that makes sense - if not tell me and I will try and explain more clearly!

Anyway, if you omit the variables in the calling statement, you can use the ControlIds of the labels created within the function in your say() function:

expandcollapse popup

#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>

Global $gui_loop, $top_label, $bottom_label

; create the gui
setup_gui()

Sleep(2000)

; change colours and text
say("I am top", 0xFF0000,"I am bottom", 0x00FF00)

Sleep(2000)

; change colours and text again
say("I am still top!!", 0x00FFFF, "And I am still underneath", 0x8888FF)

Sleep(2000)

Exit

; -------

Func setup_gui()
    
;specify location & sizes
Local $width = 500
Local $height = 80
Local $left = 1000
Local $top = 0
        
;create gui
$gui_loop = GuiCreate("huffhead",$width, $height,$left,$top,$WS_POPUP)
    
;create labels
GUISetFont(16,700)
$top_label = GuiCtrlCreateLabel("label 1",0,0, $width, $height/2)
$bottom_label = GuiCtrlCreateLabel("label 2",0,$height/2,$width, $height/2) 

GUISetState(@SW_SHOW)
        
EndFunc

; -----

Func say($top_text,$top_color,$bottom_text,$bottom_color) 

;update colors  
;top 
;$top_color_number = _ArraySearch($colors,$top_color)
;$top_color_hex = $colors[$top_color_number][1]
GuiCtrlSetBkColor($top_label, $top_color);_hex)

;bottom 
;$bottom_color_number = _ArraySearch($colors,$bottom_color)
;$bottom_color_hex = $colors[$bottom_color_number][1]
GuiCtrlSetBkColor($bottom_label, $bottom_color);_hex)
    
;update text
GUICtrlSetData($top_label, $top_text)
GUICtrlSetData($bottom_label, $bottom_text)

EndFunc

So you should now be able to integrate this into the larger script.

Another thing - you declare OnEvent Mode as you create your GUI - why? Your GUI will vanish when you exit the script - and as you are using the POPUP style, you do not get a [X] to click to activate the $GUI_EVENT_CLOSE event in any case! :-)

I cannot debug the swap_song() function - there are too many unknown variables - but it looks as if it should work.

Fingers crossed, that should get you pretty close now...

M23

[dkh]

got it. thanks for the info on parameter treatment.

at this point, though, i'm really back where i started. i already had everything working fine, with both text and colors, assuming i was willing to pause and do nothing while the gui is displaying something, and that it's ok for the gui to go away while something else is happening. these were the problems i was trying to solve, and why i was messing around with parameter passing etc.

however, i've now got a working approach up in which one script sets up the gui, and another script can update the text, and there is ZERO waiting or pausing or hanging etc, and the GUI is persistent: it remains on the screen until the next time it is updated by a separate script. the catch is that it works for updating the text, but not for updating the color (which is really quite key to the application).

essentially, it seems that ControlSetText can act on a Control that was created by another script, but I'm unable to get GuiCtrlSetBkColor to do the same. is there some kung fu to make GuiCtrolSetBkColor act directly on an existing control? Or, is there some way to update background color of a label control in the same way that ControlSetText updates text?

here's a complete working implementation (less the color updating):

Script 1: GUIfunctions

expandcollapse popup

;GUIfunctions.au3

#include <GuiConstantsEx.au3>
#include <StaticConstants.au3>
#include <WindowsConstants.au3>
#include <Array.au3>

;DEFINE COLORS

    Global $colors[8][8] = _ 
    [["red","0xFF0000"], _
    ["burnt","0xF4740A"], _
    ["orange","0xFFC000"], _
    ["yellow","0xFFFF00"], _
    ["green","0x00B050"], _
    ["olive","0x9BBB59"], _
    ["black","0x000000"], _
    ["grey","0xBFBFBF"]]


;FUNCTIONS

Func setup_gui()
    
;specify location & sizes
    
        Local $width = 700
        Local $height = 70
        Local $left = 1000
        Local $top = 0
        
;create gui
    ;Opt("GUIOnEventMode", 1)
        $gui_loop = GuiCreate("huffhead",$width, $height,$left,$top,$WS_POPUP)
        GUISetOnEvent($GUI_EVENT_CLOSE,"close_gui")
    
;create labels
    
        GUISetFont(16,700)
        
        $top_label = GuiCtrlCreateLabel("label 1",0,0, $width, $height/2)
        $bottom_label = GuiCtrlCreateLabel("label 2",0,$height/2,$width, $height/2) 
    
;set state
    
        GUISetState(@SW_SHOW)
    
 ;hang out
        While 1
            Sleep(1000)
        WEnd
EndFunc


Func say($top_text,$top_color,$bottom_text,$bottom_color) 

;update colors (these currently don't do anything)
    
    ;top 
        $top_color_number = _ArraySearch($colors,$top_color)
        $top_color_hex = $colors[$top_color_number][1]
        GuiCtrlSetBkColor(3, $top_color_hex)

    ;bottom 
        $bottom_color_number = _ArraySearch($colors,$bottom_color)
        $bottom_color_hex = $colors[$bottom_color_number][1]
        GuiCtrlSetBkColor(4, $bottom_color_hex)
    
;update text
    

;~      GUICtrlSetData(3,$top_text)
;~      GUICtrlSetData(4,$bottom_text)

        ControlSetText("huffhead","",3," " & $top_text)
        ControlSetText("huffhead","",4," " & $bottom_text)

EndFunc


Func close_gui()
    Exit
EndFunc

Script 2: GUIstart

;GUIstart.au3

#include <GUIfunctions.au3>

    setup_gui()

Script 3: GUIupdate1

;GUIupdate1.au3

#include <GUIfunctions.au3>

        say("hello","green","there","olive")

Script 4: GUIupdate2

;GUIupdate2.au3

#include <GUIfunctions.au3>

        say("bye","orange","now","red")

I like to create shortcuts to these scripts on my desktop so i can emulate the way that they'll be triggered in practice via a foot controller.

Thanks,

Dave

[Melba23]

dkh,

What does your foot controller do? Run a script? Send different parameters to the same script?

I am having problems with the fact that you have

to pause and do nothing while the gui is displaying something, and that it's ok for the gui to go away while something else is happening

There is no reason why the GUI should pause anything - nor that it goes away at any time. That is why I would like to know just what your foot controller does. I hope we can integrate that input into a single script, which will make the whole thing tidier and permit us to use AutoIt GUICtrl* functions rather than external Control* ones - which makes the problem go away. :-)

Another thought - are you running these scripts compiled or via AutoIt.exe? I have a possible solution in mind, but it requires compiled .exes to work.....

M23

[dkh]

i've discovered a very ugly workaround, so if there's no better approach, this is what i could implement:

1. set up separate mini-GUI's with color blocks just to the left of the text labels, e.g,. setup_green() does nothing but set up a small GUI with GUISetBkColor(0x00B050).

2. use ControlShow and ControlHide to associate colors with the text labels

ControlShow and ControlHide seem to be able to work directly on the controls, whereas SetCtrlBkColor seems to only work when in the same script as the GuiCreate statement.

This approach would end with one GUI running for each color, to the left of two labels, or about 12 GUI's plus the text labels GUI. I'm not sure if that would be a performance issue or not!

best,

dh

[Melba23]

dkh,

Sounds dreadful! We must be able to do something more elegant!

What does your foot controller do? How does it interact with the scripts?

M23

[dkh]

FOOT CONTROLLER

The foot controller launches AutoIt scripts, such as "LOAD.au3", "SWITCH.au3" and "PLAY.au3", each of which do things like open and close files, send keystrokes and do mouseclicks, during which various updates to the GUI need to be triggered. E.g., when i'm opening a file in the background, it's the bottom label and orange. when it opens and is ready to be switched to, it turns yellow. when switched to (WinActivated), the GUI shows it as the top label. When i click play and it starts playing, it turns green. The implementation is that I've got a small windows utility (custom made) which listens for MIDI program change messages on a given MIDI port, and when it hears - for instance - program change = 50 on MIDI port 8 - it runs LOAD.au3.

PAUSES

The pauses I'm talking about seem to be built into the model you proposed last time:

; create the gui
setup_gui()

Sleep(2000)

; change colours and text
say("I am top", 0xFF0000,"I am bottom", 0x00FF00)

Sleep(2000)

; change colours and text again
say("I am still top!!", 0x00FFFF, "And I am still underneath", 0x8888FF)

Sleep(2000)

Exit

setup_gui() does set up the GUI, and say() does change the GUI values, but they show only as long as the sleep() is set. whereas, i may need to play an 8 minute song, look over at the screen to see that the next song is ready, then click a foot pedal to kick of SWITCH.au3, which switches to the new song and preps it for playing.

Using this approach, the GUI script seems to become the wrapper for all other activity. But, how do I then trigger another thing happen from totally outside this script? Note that I'm not using the GUI for input of any kind. And, how do I then impact the existing GUI when an external script is running and needing to update the GUI colors multiple times during the script? As I mentioned, updating the text works beautifully using ControlSetText, since it seems to be able to act outside of the context of the script that created the GUI.

At one time, I had things set up such that the foot controller would trigger scripts that would open a window of a given name (e.g., Selection_Play), then a loop that was waiting for windows of certain names (e.g., WinExist="Selection_") to open would snag the name and feed it to a select statement which would kick off a function, but this was very, very clunky, (perhaps because I didn't know about GUI windows and i was opening notepad.exe windows) and we hadn't yet solved the "leave the GUI persistent until the next say() command" problem. So I changed everything such that each command (LOAD, SWITCH, PLAY) was a discreet script that could run at any time on its own. This seems much simpler and more elegant, and now the GUI is very fast/simple/clean for the text updates, but i still have the "how to update the background colors on the GUI" problem.

I think if I had to choose between going back to the big WinExist Loop & Select/Case version or using tons of little color block GUI's, I'd try the latter first!! Maybe I'm just biased because of how clunky the first implementation of it was. Perhaps if I opened GUI windows (instead of notepad windows) in order to pass foot pedal inputs to the Select/Case statement, it'd be faster and not have visible windows opening up. And, if we've really solved the GUI persistance issues between say() statements, then I could go back to the one big fat loop solution.

COMPILED

Regarding AutoIt.exe vs. compiled, I haven't spent any time trying to understand the difference, but I'm guessing it'd be relatively easy switch to compiled versions of the scripts and still trigger them from the foot controller, no?

dkh

[Melba23]

dkh,

I will have to take some time to digest that lot! I will try and reply tomorrow - if it rains and I cannot paint the front gate. :-)

The only quick response is that the Sleep lines in that code fragment were only there to allow us mere humans to see the changes - there is no requirement for them beyond that!

As to the foot controller - how does it trigger the scripts? I have never worked with such a beast and have no idea what sort of interface it has. Does it pass a command line?

M23

[dkh]

FOOT CONTROLLER TRIGGERS SCRIPTS

* The MIDI foot controller (http://www.roland.com/products/en/FC-200/index.html) can be set to send any kind of MIDI message type, e.g., Program Changes, Notes or Controller messages. For a variety of reasons, I've set it up to send Program Changes, of which there are 128, or roughly 10 unique pedal pushes in each of 0 through 12 "banks" of the foot controller.

* The messages are routed via MIDI cable to an external sound card (https://www.motu.com/products/motuaudio/ultralite-mk3) and then via FireWire to my laptop (quad core cpu with solid state drive). The device shows up as a soundcard as far as Windows is concerned.

* I use a MIDI utility (www.midiox) to route and translate MIDI messages between various bits of hardware and software, and accompanying MIDI "yokes" - or software-generated virtualized MIDI ports. The yokes/ports can be "seen" by music software and used for input and output of MIDI messages.

* The program changes from the foot controller are routed to another utility, "OnMessage.exe", which was very kindly custom created for me by Div Slomin (http://public.sreal.com:8000/~div/midi-utilities/). Here's the script that I use to set up OnMessage:

Func run_onmessage()
    
    If WinExists("OnMessage") = 0 Then 
    
    ShellExecute("cmd","/C onmessage --in 7 " & _
" --program-command 47 insert_stopA.au3 " & _ 
" --program-command 40 send_leftA.au3 " & _ 
" --program-command 41 send_rightA.au3 " & _ 
" --program-command 43 insert_sceneA.au3 " & _ 
" --program-command 50 LOAD.au3 " & _ 
" --program-command 51 SWITCH.au3 " & _ 
" --program-command 52 PLAY.au3 " & _ 
" --program-command 67 insert_stopB.au3 " & _ 
" --program-command 60 send_leftB.au3 " & _ 
" --program-command 61 send_rightB.au3 " & _ 
" --program-command 63 insert_sceneB.au3 " )
    
    WinWaitActive("C:\Windows\System32\cmd.exe")
    WinSetTitle("C:\Windows\System32\cmd.exe","","OnMessage")
    
    EndIf
EndFunc

* as you can see from the list of scripts above, many of the scripts are dedicated to sending keystrokes and MIDI notes to my audio software (Ableton Live) during performance. This is the primary reason I need this stuff automated: I'm playing guitar synth or saxophone synth with my hands, but need kick off various things in Ableton during the song.

* The LOAD, SWITCH and PLAY scripts are the scripts I'll be using to automate the sequential opening of song files in two separate instances of Ableton Live. E.g., Song 1 goes in Instance A, and while I'm playing Song 1, Song B can be loaded into Instance B of Ableton Live. Then when Song 1 is coming to an end, I can switch to and enable Song 2 in Instance B (while Song 1 continues playing), and start Song 2, doing beat matching etc., so that there is continuity between the songs (I can't think of how else one would do a dance set if you're performing the song live and you've got one song per song file).

* This is also why the color coding is so important: I'm trying to eliminate having to work directly on the computer (not very interesting stage show!) and minimize how much time I even have to look at the monitor. So, big color coded indicators of what's happening at the moment will do the trick. If I were to send a command at the wrong time (e.g., while the wrong song is active), I could barf up the show pretty hard.

[dkh]

WORKS!

I decided to stop fighting the dominant paradigm and set up a big loop.

* create gui

* set up listening while loop

* put all the discrete scripts into functions

* then all the say() updates can update text and color

The tricky bit was getting MIDI-launched scripts to trigger into the loop:

* MIDI program changes are each mapped to launch a corresponding scriptlet

* the scriptlet creates a temporary GUI called "Selection_XXX"

* this GUIlet hangs around just long enough for WinExists("Selection") to see it

* and for a StringSplit to peel off the second half of the GUI name

* to then feed it into the SELECT/CASE, which then triggers the right functions.

Thanks for sticking with me. It was really critical for all the pieces to fit together.

Let me know if I should post the finished product somewhere for someone else to use.

Best,

Dave H.

[Melba23]

dkh,

And I had just worked out a solution for you! :-(

Of interest, I added 2 small hidden labels to the GUI which could be updated via ControlSetText (just like the main labels) but which held the colour values. Then the GUI loop checked their contents and used the value to set the colour of the main labels.

Glad you found your solution, though - always more satisfying that way! Maybe talking it over helped. ;-)

Good luck with the music.

M23

[dkh]

ooh, that's brilliant.

i'll definitely keep that in mind in case the loop thing becomes too unwieldy.

thanks for everything.

david