Server GUI

The programmer will expect to build:

-the server GUI as the given design experience
-fill it with some smooth animation
-fill missing parts in the GUI with the same
design language to meet the document description
-build the client python app 3.7 with raspberry
pi in concern and server will be made using
flutter with all functionalities working as
described in this document.

The programmer will use The JSON files to allow

dynamically in this app.

**ANY PART THAT NEEDS MORE CLARIFICATION PLEASE

CONTACT ME TO DO SO**

**THE APP (server/clients) SHALL NOT PERFORM ANY

AUDIO NOTIFICATIONS OR SHOW ANY CONTROL FOR ANY
MEDIA, MESSAGE, OR RING FOR ANY PART OF IT**

There is only one server and as many clients as

needed. Every client has their properties
(explained later) to be identified

__CN__ stands for client name ('__' symbol before and after to help recognize in a string)
whenever the program found it at the end of any client order string, then that action order
will be sent to the client with that name only, if no __CN__ found at the end then send to
all client in the client list. If the program found wait__CN__, the client with name __CN__
must complete the order before the server process the action. For example, for a client with
the name = 'gls' the __CN__ = '__gls__', remember some clients can't handle all types of
orders like run media.

The server GUI has two size options only; full-screen mode or minimized mode (no resize
allowed).

The client's application should always listen to the update order (which fires by clicking on
a client's update button on the server GUI); when receiving it, all clients should scan files
in specific folders on the server-side. If a client finds any update during the scan, it
should automatically update its copy on its local folders. Folders on the server-side that a
client will scan are CLIENT, SHARED, and MEDIA; these folders can contain but are not limited
to:

SHARED:
-[Link]
-pins__CN__.json

CLIENT:
-client__CN__.json

MEDIA:
All media files from (audio, video, photo)

** client shall also automatically perform the files update sequence described above on each
new start of the app.

** MD5 is the preferred function to find out updated files in folders.

**All GUI list is scrolled able, and the scroll order is given with a simple modern scroll
bar(visible when touch or scrolling only) to the right of each list, by the mouse scroll, or
by finger scrolling for touch screen, and as an indication for scrollable it uses inner liner
shadow at the bottom if scroll down available and an inner liner shadow on the top if scroll
up is open these indicators are visible all the time scrolling is available**

**ANY MENTION OF TIME IN THIS DOCUMENT DOESN'T MEAN REAL-TIME BUT TIME
FROM THE GAME STARTING POINT; 01:22 means 1 minute and 22 seconds from
the time the game started in**

**app must always expect a human error in JSON and the python functions and shall show a
warning message**

**CLIENT QUEUE IS SHARED QUEUE BETWEEN MEDIA (CLIENT IN GUI ACTIONS LIST), MESSAGES AND
RINGS, THIS QUEUE FOUND ON EACH CLIENT TO ARRANGE SHOWING ITEMS ON THAT CLIENT SCREEN, 10
SECONDS IS A DELAY BETWEEN PLAYING NEXT ITEM IN THE QUEUE AND THE CURRENTLY FINISHED
PLAYING**
Server GUI Button function:
START button: perform all start needed actions from reset timer, initialize everything
required for the app to work, and then call the 'start' reserved function in the [Link].
In the end, it changes the appearance and function to the 'STOP' button.

STOP button: perform all STOP needed actions from reset timer, apparent emergency, and clear
all pins status, and then call 'stop' reserved function in the [Link], in the end, it
changes the appearance and function back to START button.

EMERGENCY button: perform all EMERGENCY needed actions to alert the user of the emergency by
showing full-screen emergency flicker word with the X button and calling 'emergency' reserved
function in the [Link].

**note closing the full emergency screen by clicking the 'X' button will not end the
emergency; it only ends by pressing the STOP button.

Update clients button: used to force all the clients to update their files in specific
folders if they found any change (explained above).

CLEAR ALL button: this will clear all the effects currently running in the mixer.

SEND MESSAGE button: will show a full-screen dialog that the user uses to send a message.
This message can be pre-defined or set a new message and time shown on screen and a media
file if needed. The client then performs a message order (explained later).

CALL button: Send the default ring client to perform a ring action without audio.
***it changes to HANG UP button that sends end_call order to client-side***
**EXPLAINED LATER IN CLIENT-SIDE DOCUMENT HOW TO PERFORM RINGING AND WHEN THIS BUTTON
CHANGED**

+ button: a button near timer countdown, it calls the 'add_time' reserved function in the
[Link].
GUI Actions Lists

There is four GUI Actions List: STEPS, EFFECTS, CLIENT, RINGS. Their items are declared by
reading [Link] [Link]; everything in these lists is crossbedding to an object with
an 'action' attribute that the server will process when double-clicked perform on it, objects
found in [Link], [Link].

The CLIENT RINGS GUI list does have many dialogs, including different text and status
strings, one for each client name connecting to the server at that time.

The text that is above the CLIENT, RINGS GUI list is the text attribute for a client; this
text is to make it clear for the user that the shown list is for which client; when the user
performs a double click on any button from that list the server will send the order to the
selected client only, note the list contain a filter and its use 'for' attribute in both
media, ring, and messages object to do the filtering. 'for' attribute could include either a
one client name ("for": "CN") or an array of CN ("for": ["CN2", "CN1", "CN"]), the object is
allowed only to show in the list for the client that it is CN is listed in the 'for'
attribute value. If no 'for' attribute is used, that item should use the 'visible' attribute
as the filter. If this attribute is true, then show for all clients list else for none.
Clicking on the text above the CLIENT, RINGS GUI will show selecting the client overflow
dialog, which lets the user choose the client to filter for the button.

'for' attribute does control the ability to send the file in direct server/clients orders.
This attribute can be used in media, messages, and ring objects if the server asks to show
media on a client. That media 'for' attribute does not include the CN of that client. The
server order will be canceled automatically, so it doesn't show wrong media on a client that
was not supposed to handle it; a log should be added for the cancelation. If no CN is present
in the order string, then send to default media handler if it is named found in the 'for'
attribute value if no default is found that fits this situation, then send to all clients
with name CN that is in 'for' attribute value.

Under each GUI list, 'STEPS', 'EFFECTS', 'CLIENT', 'RINGS' found a status that is specific
for that listing status. GUI list ('CLIENT' and 'RINGS') does have more than one status for
each; it depends on how many clients can handle it. The server updates it with any action
reported from the owner client regarding that list

All possible GUI list status text:

STEPS statuses:
- fire “name”
- finish “name”
- empty (no status just empty status bar)

**click on this status shows all STEPS fired and the time it ends if completed.

EFFECTS statuses:
- Waiting in the queue
- Playing '5' effects
- Playing '3' effects
- No effects playing
 **click on this status shows all EFFECTS name started with time left to end and two-
button to remove this effect and change if it is loop attribute or not.

CLIENT statuses:
- Waiting in the queue
- "name" is shown
- a message is shown
- Nothing is shown

**click on this status shows all media or messages displayed and the order's time.

RINGS statuses:
- Waiting in the queue
- Ringing 1/8…
- Ringing 2/8…
- Answered
- No Answer
- Call Ended
- No Calls

**click on this status shows all RINGS, and the time it was called in.

All GUI list STEPS, EFFECTS, CLIENT, RINGS items only work with a double click.

Log: A list On the right bottom corner of the server GUI shows all logs by the clients,
server(computer logo), any status update from clients like:
-CN connected
-CN disconnected
-Fail: CN not found
-New game # started (use real clock) # is game auto number
-Game # ended (use real clock)
-Error: Function (name) not Found
-Error: Media Json line 20
-Error:…
-Time ended
-Emergency fired
-Emergency stopped
-(pins group text) on for pins group with the 'log' attribute set to true
-(pins group text) off for pins group with the 'log' attribute set to true
-(media text) shown for media with the 'log' attribute set to true
-(media text) ended for media with the 'log' attribute set to true
-(rings text) called for rings with the 'log' attribute set to true
-(rings text) ended for rings with the 'log' attribute set to true
-(Effect text) shown for effect with the 'log' attribute set to true
-(effect text) ended for effect with the 'log' attribute set to true
-(message text) shown for messages with the 'log' attribute set to true
-(message text) ended for messages with the 'log' attribute set to true
-(steps text) started for steps with the 'log' attribute set to true
-(steps text) ended for steps with the 'log' attribute set to true
-update clients started
-auto-update clients started
-app started on (real clock)

Every logged message should include the time the server adds from game run time or real-world
clock.

Pins status: the bottom left to the bottom center is the status of pins group that was
defined in all pins__CN__.json, it shows their text and icon attribute from pins__CN__.json,
the green circle to the right of shows if the group of pins is "on" (for "off" status no
circle icon is shown), double click on one of them change the 'status' of it from 'on' to
'off' and vice versa, changes the status will also fire the high and low function in client-
side on that double-clicked pins group (will be explained later in the document), an update
must happen in real-time for every change in group pins status.

** Pins status list is divided by the pins__CN__.json that it belongs to; the name and icon
shown in the top corner of Pins status is the text attribute for the client that its name is
__CN__.

**** Pins status list is scrollable to the left and right with the same techniques to show
scroll of other lists.

**double click on 'input' pins ( will be explained later) will not change any status or do
anything; it shall report that is double-clicking is not available by doing red flicker for
text, for example…

**input pins should show input icon (#) instead of the green circle in the server GUI all the
time.

**there is no default icon for pins group status; if no icon is given in pins__CN__.json then
the GUI will show no icon.

**If the "visible" attribute is used with 'false' as a value, whatever type it is, this
object shall not appear to the user in the Server GUI.
SERVER-SIDE JSON

Properties
** properties object contains the main server properties to use in the server GUI, it
consists from:

"title": "GLS is the best", set the title of the window in the server GUI.
"logo": "[Link]", set the logo file to use instead of the "[Link]" word in the server
GUI.

The following attributes are true or false values that show or hide a button or a specific
GUI list. If a GUI actions list was hidden, then the rest of the GUI actions list should take
the space it was using.
"allow_rings": true, show, or hide the rings GUI action list.
"allow_media": false, show, or hide the client GUI action list.
"allow_messages": false, show, or hide the message button in client GUI action list.
"allow_effects": false, show, or hide the effects GUI action list.
"allow_steps": false, show, or hide the steps GUI action list.
"allow_emergency": true, show, or hide the emergency button in the server GUI, and forget any
emergency order.
"allow_add_time": true, show, or hide + button near countdown in GUI action list, and disable
or enable the "add_time" action function in both client and server.
"allow_calls": true, show, or hide call button in rings GUI action list.

"timer_countdown": 120, the attribute's value is the number of minutes for the game countdown
start from.

Actions
** actions attribute is a dynamic list of to-do pre-defined functions that should happen to
perform the related object job. This list of functions is read in sequential order.

**Not all pre-defined functions must be presented for all actions objects; for example, some
action attributes will not remove action functions.

**actions attribute value can be empty or not in one order or even no use all functions**

All possible actions pre-defined function:

-"greedy_ lock": the value of this attribute is an array of clients' names or objects of a
greedy array of or combination. Objects of a greedy array is an array with the first index
being the CN of a client and the second index is an array of what this lock is greedy for
from this client; it can contain a combination of a reserved word:
media: make sure that no media or messages play on the client.
 rings: make sure no ring is going on the client.
action: make sure no action is processed on the client.

If any reserved word is not given in the greedy for an array, then the app should
not care if it is used or not

for example [["CN", ["media", "rings"]], "CN2"]

on the other hand, the client's name makes sure that all the above-reserved words

"greedy_ lock" works in concerning the following:

-The greedy_lock respects its turn in the client queue. It always sets it in a place before
any greedy reserved word items it is greedy for, and any greedy lock comes before it. For
example, if it is greedy for media only, it scans the queue from end to the start until it
finds the first media order. If it found other greedy locks directly before that media
queued, it adds itself before that queued greedy locks, then directly after the founded
media.

-Suppose the value contains client names only that are still running a media, performing a
call, processing an action client, queue not empty, or waiting for another action that asks
for greedy_ lock. In that case, it is queued itself action sequence in each client queue of
client name found in the value of this attribute concerning the first rule.

-The greedy_ lock will block the client queue reading if it is on top of that client queue
until it finishes.

-If this greedy_ lock is on top of the client queue of all needed clients, then the
server/client shall start doing the action sequence connected to that greedy_lock.

-during the action sequence been processed, the greedy_ lock should not allow any outside order
from running a media, performing a call, processing an action client until finished (they all
add to client queue.

-When the action sequence is connected completed, the server unlocks the greedy_ lock on all
clients, and the app refills again.

-the server does control and manage the greedy_locks.

-when any client needs one, it asks the server to create it.
-the greedy_lock consists of (key, data).
-The greedy_lock key implementation should be like an increment key for each new greedy lock
associated action sequence; it increments that key.
-the greedy_lock data is an array of CN or greedy for an array of objects that this greedy
lock asks for.
-the greedy lock key should be sent with any action order from a client or the server that is
still connected to the action sequence associated with that greedy_lock. This is to prevent
dead road locks from happening if the client asks for a greedy lock that has already been
taken by the same process, which may keep waiting forever.
-if at any part of the processing, the action sequence associated with that greedy_lock ask
for more CN than this greedy_lock provides, then a new greedy_lock will be created asking for
other needed CN.
-The new CN perform the same except it die after it levels back up, not at the end of the
action sequence associated with that old greedy_lock

-"conditions_met": the value of this attribute consists of an array of on_special conditions

strings that were met by doing this step in action; ["Hello conditions", " love__CN__", "
die"] it should be sent to all clients in real-time, every client must check on_events and
see if any events have it is all conditions met with this change and then run it if found.

All met conditions are for all clients if no __CN__ is used in that condition else; it only
concerns the client that name is equal CN.

-"conditions_unmet": the value of this attribute consists of an array of on_special

conditions strings that were unmet by doing this step in action; ["Hello conditions__CN__","
love", " die"].

All unmet conditions are for all clients if no __CN__ is used in that condition else; it only
concerns the client that name is equal CN.

-"Add": add step buttons, effect buttons, rings buttons, and clients' buttons (media buttons)
to their GUI actions list. The value of this attribute is a list of objects' names found in
[Link] and [Link].

-"remove": remove step buttons, effect buttons, rings buttons, and clients' buttons (media
buttons) from their GUI actions list. The value of this attribute is a list of objects' names
found in [Link] and [Link].

-"clear": remove all action GUI list buttons that are listed by their objects' name in the
value of this attribute ['steps', 'effects', 'clients', 'rings']

-"mixer_add": add an effect or an array of effects to play in the audio mixer, the effect is
given in either an object's name found in the effects object in [Link] or file name in a
specific media folder saved on the server-side, the value is either a single effect "live" or
an array of effects ["live", "gls. acc", "die"].

-"mixer_remove": remove an effect or an array of effects from the audio mixer, the effect is
given in either an object's name found in the effects object in [Link] or file name in a
specific media folder saved on the server-side, the value is either a single effect "live" or
an array of effects ["live", "gls. acc", "die"].

-"play": remove all effects that are playing in the audio mixer and play a new one from
either an object's name found in the effects object in [Link] or file name in a specific
media folder saved on the server-side.

-"mixer_clear": remove all effects that are playing in the audio mixer, except an effect or
an array of effects, each effect is either an object's name found in the effects object in
[Link] or file name in a specific media folder saved on the server-side, empty array []
or an empty string "means to remove all effects.
-"disable": disable the action GUI list buttons. The value is either an array of GUI Action
names or a single GUI Action name from ['steps', 'effects', 'clients__CN__', 'rings'].
For the Clients and Rings list, It disables all clients' GUI lists if no __CN__ is used in
the list string else; it only concerns the list for the client that name is equal CN.

-"enable": enable the action GUI list buttons. The value is either an array of GUI Action
names or a single GUI Action name from ['steps', 'effects', 'clients__CN__', 'rings'].

For the Clients and Rings list, It enables all clients' GUI lists if no __CN__ is used in the
list string else; it only concerns the list for the client that name is equal CN.

-"add_time": the value is the minutes to add to the timer countdown. For each time minutes in
the value, it called the add_time reserved function once.

-"client_cn": the value of this function is a client name. It changes the client action GUI
to list the client with the name equal to "CN" media and messages. If messages are not
available on that client, then set to default. If CN can't handle media, forget the order. If
value equals default, then set to the default for media and messages.

"client_cn": “GLS”
"client_cn": “default”

-"rings_cn": the value of this function is a client name. It changes the rings action GUI to
list the client with the name equal to "CN" rings. If value equals default, then set to the
default for media and messages. If CN can't handle rings, forget the order.

-"action_sets": do all the action sets listed in the array sequentially. You can find each
one in action_sets in [Link].

-"send": send a list of string orders to clients through the network in sequence.

The 'wait' order used at the end of the string means the server will stop reading the action
sequence until the client report finishes the order.

The number after the 'wait', if found, is the max time in a millisecond to wait ("hi_call
wait 1500__CN__").

***__CN__ at the end of the string means to send that order to the client with a name equal
to __CN__if no __CN__ found then send to the default media client only***

If wait__CN__ is found, then the client must complete this order with the name CN before
reading the rest of the orders.

-"functions": a list of functions that are written in the python app. The value of this
attribute is an array of function arrays; each function array's first item (at index 0) is
the function name to call. The rest is a list of variables to send to that function.

**functions can be dynamically changed over time in the server python app as needed.
-"ring": send an order to the client to do the ring function with a ring object that is found
in rings in [Link] to play.

***__CN__ at the end of the string means to send that order to the client with a name equal
to __CN__if no __CN__ found then send to the default ring client only***

-"reserved": execute one or many of the reserved functions. When the ring reserved process
runs, it also orders the client to perform the call without any media to play.

-"others": a list of pre-defined functions in the python app functions written by the
programmer start_timer, stop_timer, set_timer written like this: "set_timer 120" which means
set timer to 120 minutes.

-"log": add a log to the log list in the server GUI.

-"sleep": sleep for the value of this attribute, time given in milliseconds.

-"show": send an order to the client to show the media on the clients' screen. The value of
this attribute is the name attribute in the media file like video or photo or an array of
media [Link] “gls__CN__” or [“gls__CN__”,”gls2__CN__”]

***__CN__ at the end of the string means to send that order to the client with a name equal
to __CN__if no __CN__ found then send to the default media client only***

If wait__CN__ is found, then the client must complete this order with the name CN before
reading the rest of the orders.
"message": send an order to the client to show a message for a while. The value for this
attribute is a message name from messages object in [Link] ("message": "dead_call"), or
a message string ("message": "dead call with love", the string will not equal any of messages
object names in [Link]), or an array of messages object, each message object consist of
a list of data; the first index is the message name from messages object in [Link] or
the message text and *****if the first index is the message text then the second index is the
time to show in milliseconds, and the last index if found in the video or photo file or media
name (in [Link]) that you like to send with the message to show (you can distinguish if
it a file or media name from file extension that only file has an extension (.jpg)), else
only message name shown *****.

***__CN__ at the end of the string means to send that order to the client with a name equal
to __CN__if no __CN__ found then send to the default media client only*** ("message":
"dead_call__CN__"),

If wait__CN__ is found, then the client must complete this order with the name CN before
reading the rest of the orders.

The message text will be shown centralized surrounded in a black on the client screen for a
while, and the media, if found under it (check the GUI DESIGN), a warning_sound from
[Link] should be played as notification for any new message shown. The default time to
show a message if only a text is presented is 30 seconds.
Remember between every two items in the client queue there should be a gap of 10 seconds to
show the next item in the client queue

**note if video send with the message, then at least wait for the video length to dismiss the
message, forget about the time send if it is less than the video length**

Examples of messages attribute value: "dead_call__CN__”

"dead call with love”

[["YOU ARE DEAD", 30000, "[Link]"],

["dead_call ", 40000],//override the time to wait to 40s
["Dead DEAD", 30000, "dead.mp4"],
["MA MA", 30000, "video2"]]
Reserved
** reserved are must-have functions that every server JSON file must have:

All reserved function types:

-start: fired when the START game button fired in the server GUI, it set first STEPS,
EFFECTS, CLIENT screen, and RINGS and may start effect or send orders…etc.

-end: fired at the press of the 'STOP' button of the game button at server GUI, it
prepares the game to be restarted, including the rest of the GUI and the emergency.

-emergency: fire when the 'EMERGENCY' button clicked at the server GUI, or if received
status from the client telling an emergency physical button has been pressed from the client
side in any part of the game.

-ring: will be fired after each phone ring.

-add_time: will be fired after each pressing the + button near the timer in the server
GUI pressed.

"reserved": [{
** type attribute is used to set the type of the reserved function: start, end
emergency, ring
{
"type": "start",
"actions": { "greedy_ lock": true,

"conditions_unmet": ["LOVE LOve"],

"clear": ["steps", "effects"],
"mixer_clear": [],
"enable": ["steps", "effects"],
"add": ["step1", "step2", "effect1", "love", "dead", "media1"],
"remove": ["button3", "effect3", "love", "media1"],
"mixer_add": ["effect4", "[Link]"],
"mixer_remove": ["effect3"],
"play": "effect2",
"show": "video1",
"send": ["gls", "hi_call wait"],
"functions": [
["call", 1, "no"],
["yaa", "lol"]
],
"message": [

["YOU ARE DEAD", 30000, "[Link]"],

["HA HA HA", 40000],
["Dead DEAD", 30000, "dead.mp4"],
["MA MA", 30000, "video2"]
],
 "action_sets": ["action_set1", "action_set2"],
"ring": "dead_call",
"reserved": ["ring", "emergency"],
"others": ["start_timer"],
“log": "gls is go on"
}
},
{
"type": "end",
"actions": {
"others": ["end_timer"],
“log": "gls is go on"
}
},
{
"type": "emergency",
"actions": {
"add": ["step1"],
"remove": ["button3"]
}
},
{
"type": "ring",
"actions": {
"add": ["effect1"],
"remove": ["effect4", "effect3"]
}
}
],
Client Statuses
** contain all the client statuses that have an action in the server-side to do when
triggered by the client as respond using a 'status' action type. The 'type' attribute is used
to distinguish the status objects, and the 'actions' attribute contains the response of the
server to execute.

"client_statuses": [{
"type": "done",
"actions": {
"mixer_add": ["effect4", "[Link]"],
"mixer_remove": ["effect3"],
"play": "effect2",
"send": ["gls", "hi_call wait 2000"]
}
},
{
"type": "moon",
"actions": {
"others": ["end_timer"],
“log": "gls is go on"
}
},
{
"type": "alive",
"actions": {
"add": ["step1"],
"remove": ["button3"]
}
}
],
Action sets
It is a pre-defined action attribute that may be used in the [Link] by writing down its
name.

"action_sets": [{
"name": "action1",
"actions": {
"play": "effect2",
"send": ["fire", "no"]
}
},
{
"name": "action2",
"actions": {
"play": ["effect2"],
"send": ["fire", "nero wait"]
}
}
],
STEPS
Steps objects declare all possible steps buttons, and the program distinguishes them by the
("name") attribute; The name attribute is unique in [Link] and [Link]. When needed,
they add into the 'STEPS' action list in the server GUI by using the 'add' action order.
STEPS objects attribute does set the main attribute of the button: the text ("text") to be
visible to the user in server GUI, and the icon ("icon") of the button. Sometimes STEP could
contain only text or icon or none, so the app should adapt to it and use the ("name") instead
of text if the program didn't find the text attribute in the object. The GUI should use a
general STEPS icon; if the program didn't find the 'icon' attribute in the object.

The programmer should save icons in one icon folder

**If the program finds "visible" attribute with false as a value, then this object shall not
appear to the user in the Server GUI, even if it is added by 'add' action order, it is just
in case of mistakenly adding this item by the JSON programmer

"steps": [{
"name": "step1",
"text": "love message",
"icon": "[Link]",
"visible": false,

"actions": {
"play": "effect3"
}
},
{
"name": "step2",
"text": "start",
"actions": {
"play": ["effect2", "ha ha [Link]"],
"send": ["hi_call"]
}
},
{
"name": "button3",
"icon": "[Link]",
"actions": {
"play": ["effect4", "[Link]"],
"send": ["gls"]
}
}

],
Effects
Effects objects declare all possible effects, and the program distinguishes them by the
("name") attribute; The name attribute is unique in [Link] and [Link]. When needed,
they add into the 'EFFECTS' action list as a button in the server GUI by using the 'add'
action order. Effects objects attribute does set the main attribute of the button: the text
("text") to be visible to the user in server GUI and the icon ("icon") of the button.
Sometimes effects could contain only text or icon or none, so the app should adapt to it and
use the ("name") instead of text if the program didn't find the text attribute in the object.
The GUI should use a general STEPS icon; if the program didn't find the 'icon' attribute in
the object.

-The effects are saved in a particular server media folder.

-All effects are 5.1 channel sound.

- The program should play All effects in the background in a mixer capable of playing more
than one effect simultaneously.

-The program will continually update the status of playing effects on the server GUI effects
status in real-time.

-Status shows the count of effects playing, and when clicked, it shows a list of all effects
names playing in the mixer at that moment and time left to finish each one.

-the status list has two buttons for each effect, one to stop playing any of the effects and
the other to change loop mode (true/false) directly from the GUI.

-"loop" attribute is to set if this media shall loop after finish playing until force it to
stop by mixer the 'remove' attribute, the 'clear' attribute, or control from the GUI, loop
set to false is the default for effects.

-only effects with different name attributes can be played in the mixer at the exact moment.

-The EFFECTS GUI list shall not contain any effect object that is playing.

If an effect listed in the EFFECTS GUI list starts playing, then it will be removed during
playing and returned after the effect is stopped if it hasn't been removed before that.

If an effect was added to EFFECTS GUI list during its playing, it would be added after
finishing playing if it hasn't been removed before that.

**If the "visible" attribute is used with false as a value, then this object shall not appear
to the user in the Server GUI even if the 'add' action order adds it. It is just in case of
mistakenly adding this item by the JSON programmer

**when an effect is playing, then on_special condition on_effect_play met, and condition
on_effect_stop unmet when no effect is playing then on_special condition on_effect_stop met
and the on_effect_play unmet
"effects": [{
"name": "effect1",
"text": "love message",
"icon": "[Link]",
"loop": true,
},
{
"name": "effect2",
"text": "start",
"icon": "[Link]",
"visible": false,

"file": "[Link]"
}, {

"name": "effect3",
"text": "no message",
"icon": "[Link]",
"loop": true,
"file": "[Link]"
},
{
"name": "effect4",
"text": "ha",
"icon": "[Link]",
"file": "[Link]"
}],
Rings
Rings objects declare all possible rings, and the program distinguishes them by the ("name")
attribute; The name attribute is unique in [Link] and [Link]. When needed, they add
into the 'RINGS' action list as a button in the server GUI by using the 'add' action order.
Rings objects attribute does set the main attribute of the button: the text ("text") to be
visible to the user in server GUI and the icon ("icon") of the button and the media object
found in media in [Link] to be played when phone answered (audio files only). Sometimes
rings could contain only text or icon or none, so the app should adapt to it and use the
("name") instead of text if the program didn't find the text attribute in the object. The GUI
should use a general STEPS icon if the program doesn't find the 'icon' attribute in the
object.

**when the ring function fires ring action GUI list for only this client filter, including
the call button, will be disabled until the finish.

**the ringing function should continue without any interruption until the finish. When the
ring is activated, it sends a ring order to the client with a media attribute to perform a
call and play that media or fail after eight ringing tries.

**rings only take audio as media

** if rings order started by the client-side without server-side order, the client must warn
the server of it, and server must act as if it is his order and disable all rings buttons and
show the status that is ringing and update it in real-time for only this client action list.

** status of Ringing on client-side shall be presented on a particular location on the GUI.

** after a ring connected media has been played, the button associated to if found in the
server GUI must be removed and never re-add by the app even using 'add' action order, and
neither the server nor the client can play that ring even with auto JSON order again…

only one ring shall be performed on the same client simultaneously

If a Ringing is processing at the client right now (except a Ringing without media), it can't
be stopped or changed until it finishes.

The client should use a "client queue" for any new Ringing order the server or client asks to
do while waiting for the current Ringing to complete.

Suppose the server or client asks to do a Ringing that the client is currently doing or is
already queued. In that case, the server or client should assume that they did order to do
the Ringing and continue doing the action, usually as in JSON files.
after the playing ring end, a delay shall be in between the finish time and the start of the
new item in the queue, so playing the next ring in the client queue shall be postpend by 10
seconds

**If the "visible" attribute is used with false as a value, then this object shall not appear
to the user in the Server GUI even if the 'add' action order adds it. It is just in case of
mistakenly adding this item by the JSON programmer.

**when a call is processing, then on_special condition on_call_on met, and condition
on_call_off unmet, when no call is being processing then on_special condition on_call_off met
and the on_call_on unmet

**ALL ON SPECIAL CONDITIONS ARE MET ONLY FOR THE CLIENT OR CLIENTS THAT THIS ORDER WAS SENT
TO; NO OTHER CLIENTS' CONDITIONS SHOULD CHANGE STATUS EVEN IF IT DOES HAVE THE SAME NAME**

** 'for' attribute filters which client can handle this item and whose not. It was explained
above with more details in the GUI Actions Lists description.

"rings": [{
"name": "dead_call",
"text": "dead message",
"for": "gls_client",
"media": "dead"
},
{
"name": "love_call",
"text": "love",
"icon": "love_acc.ico",
"visible": false,
"media": "love"
}
],
Messages
**Set pre-defined messages to use as a list shown to the user when pressing the send messages
button in the server GUI. Double-clicking on one of them sends it instead of a new one on

**name can be used in messages to shortcut their use in messages action.

**media is the video or photo to send to the client to show with the text message, the media
send in real-time after selecting it from folder browser, it will be guaranteed to be small.

**If the "visible" attribute is used with "false" as a value, this object shall not appear to
the user in the Server GUI.

**when a message is being shown, then "on_special" condition "on_message_show" met, and
condition "on_message_unshow" unmet, when no message is showing then "on_special" condition
"on_message_unshow" met and the "on_message_show" unmet.

**ALL ON_SPECIAL CONDITIONS ARE MET ONLY FOR THE CLIENT OR CLIENTS THAT THIS ORDER WAS SENT
TO; NO OTHER CLIENTS' CONDITIONS SHOULD CHANGE STATUS EVEN IF IT DOES HAVE THE SAME NAME**

** 'for' attribute filters which client can handle this item and whose not. It was explained
above with more details in the GUI Actions Lists description.

"messages": [{
"name": "dead_call",
"text": "dead message from the user",
"time": 3000,
"visible": false,
"for": "gls_client",
"media": "love"
},
{
"name": "alive_rise",
"text": "alive message from the user",
"for": ["gls_client","gls_client2"],
"time": 20000
}
]
Media JSON
**This file is accessible by the server and all clients.

Media objects declare all possible media, and the program distinguishes them by the ("name")
attribute; The name attribute is unique in [Link] and [Link]. When needed, they add
into the 'CLIENTS' action list as a button in the server GUI by using the 'add' action order.
Media objects attribute does set the main attribute of the button: the text ("text") to be
visible to the user in server GUI and the icon ("icon") of the button and the ("file")
attribute is the name of the file to show for each media. Sometimes media could contain only
text or icon or none, so the app should adapt to it and use the ("name") instead of text if
the program didn't find the text attribute in the object. The GUI should use a general STEPS
icon if the program doesn't find the 'icon' attribute in the object.

*Thumbnail is used as a general icon for pictures and videos.

*Media will be saved in the media folder on the client-side.

When a video or audio media is running, all other media's buttons will be disabled for that
client until this media finish playing.

Video and audio should continue playing without any interrupt until the finish, and no other
media shall be shown until the current one finishes.

When the show media order is activated, it sends a show media order to the client with the
media 'name' attribute. In response client either shows that file on the client screen or add
it to the client queue.

** if media start shown by the client-side action without server-side order, the client must
warn server, and server must act as if it is order and disable all other media buttons, and
show the status that is playing file for that client

** status of media on each client-side shall be presented on a particular location on the GUI
when that client is selected.

** after a media except the default has been played, the button connected to if found in the
server GUI must be removed and never re-add by the app even using 'add' action order, and
neither the server nor the client can play that media even with auto JSON order again,

** after a media showing order sent, the button connected to if found in the server GUI must
be removed, even more, it will be unable to re-add by the app using 'add' action order, and
neither the server nor the client can play that media even with auto JSON order in any JSON
files… except the default medias

**Default media is a media that is played automatically and directly with a loop option on
(video and audio) after any other media finish playing or at the start of the client. There
are two types of default media:
 -Primary default media: only one media per client it distinguishes with a name
attribute value is 'default__CN__', it is used as the primary default media if found.

-General default media: only one media could be a general default media it
distinguishes with a name attribute value is 'default'. It is used if the Primary default
media is not found.

**if no default or audio default is found, then shows an only black screen

**default media can be any media

** server should be showing default when showing the default media

If a media is shown on the client right now (except the default media), it can't be stopped
or changed until it finishes.

The client should use a queue for any media the server or client asks to play while waiting
for the current media to complete.

Suppose the server or client asks to show a media that the client is currently playing or is
already queued. In that case, the server or client should assume that they did order to show
the media and continue doing the action, usually as in JSON files.

a gap shall be between each do of the media in the client queue equal to 10 seconds except
shows default.

**When a media is showing then "on_special" condition "on_media_show" met, and condition
"on_media_unshow" unmet when no media is showing then "on_special" condition
"on_media_unshow" met and the "on_media_show" unmet

**ALL ON SPECIAL CONDITIONS ARE MET ONLY FOR THE CLIENT OR CLIENTS THAT THIS ORDER WAS SENT
TO; NO OTHER CLIENTS' CONDITIONS SHOULD CHANGE STATUS EVEN IF IT DOES HAVE THE SAME NAME**

**If the "visible" attribute is used with "false" as a value, then this object shall not
appear to the user in the Server GUI. It is just in case of mistakenly add this item by the
JSON programmer

** 'for' attribute is to filter which client can handle this item and whose not. It was
explained above with more details in the GUI Actions Lists description.

**a special type of media is the one with the "timer" string as a file attribute value. This
type of media will show the timer countdown of the game on a black window on the client
screen, last 1 minute in the timer, the tick-tock sound should be played, and at the time
end, an alarm sound should be played with a flickering screen "TIME IS UP"…

{
"media": [{
"name": "default",
 "text": "love",
"icon": "love_acc.ico",
"file": "timer"
},
{
"name": "video2",
"text": "love",
"icon": "love_acc.ico",
"file": "[Link]"
}, {
"name": "audio1",
"text": "love",
"icon": "love_acc.ico",
"for": "gls_client",
"visible": false,
"file": "audio1.mp3"
},
{
"name": "love",
"text": "love",
"for": "gls_client",
"file": "love.mp3"
},
{
"name": "dead",
"icon": "love_acc.ico",
"for": ["gls_client1", "gls_client2"],
"file": "dead.mp3"
},
{
"name": "audio1",
"file": "audio1.mp3"
}, {
"name": "photo1",
"icon": "love_acc.ico",
"file": "[Link]"
},
{
"name": "photo1",
"file": "[Link]"
}]

}
CLIENT-SIDE JSON
The client is a raspberry pi 4 running a
standard raspberry Linux and 3.7
pythons. You may use any external app to
do any work you wish but keep in mind
the screen of the python app on the
client-side shall never show anything or
play any sound on it, nor any used app
should, except when showing a media's
objects or a message

The high and low function should run at

part of its algorithm the high or low
functions for raspberry pi SDK on that
pin
THERE COULD BE ONE OR MORE CLIENTS CONNECTED TO THE SERVER AT THE SAME
TIME; THEY ARE DISTINGUISHED BY CLIENT NAME (CN), THE PROGRAMMER
SHOULD SET THE CLIENT TO BE CONNECTED TO THE SERVER IN A DYNAMIC WAY.

Each client does have a properties object that contains

attributes:
"name": This string represents a client name (CN). It is unique among clients, and it
distinguishes clients from each other.
"text": This a string that be shown to the user to express this client on the GUI
"icon": This is an icon file to be used to express this client on the GUI.
"default_ring": true or false value to set this client as the default client to send unsigned
with '__CN__' ring orders to it if this client CN was part of the order's object 'for'
Attribute
"default_media": true or false value to set this client as the default client to send
unsigned with '__CN__' client(media) orders to it if this client CN was part of the order's
object 'for' Attribute.
"default_message": true or false value to set this client as the default client to send
unsigned with '__CN__' message orders to it if this client CN was part of the order's object
'for' Attribute

"handle_message": true or false value to set this client as a client that can handle
messages, if an order is sent by to a client that can't handle messages, then the messages
sent to the default, if no default, then forget the order and show the warning message.

"handle_media": true or false value to set this client as a client that can handle media. If
true, then show this client in the list of clients that you choose from which the media GUI
action list items are for.

If a client can't handle media, then even direct auto server/client of show media will be
sent to default or forgotten if there is no default.

"handle_ring": true or false value to set this client as a client that can handle rings, and
do a call or not in the list of clients to choose from which the rings GUI action list item
send to, if it can't handle rings then even direct auto server/client of the call will be
forgotten.

When the client is connected to the server, it shares all properties data, which the server
uses to identify the client and show to the user or run some orders in the right way. The
server may also share the status for greedy lock…etc., as the programmer sees it needed.

When the client connected, the server should read it pins__CN__.json and update status on the
pins status list

**if there is more than one default client, then the last client
report that is he is the default will be saved as default on the
server-side

Orders
**orders containing all possible orders The client could receive and process. They are
distinguished by the name attribute, which is exactly the string sent by the server to the
client. Post attribute is how much time delay the client should execute actions after
receiving the order.
Actions

** it is different than action in [Link]. It consists of classes that shall be read in

sequence and typically run in parallel. The 'wait' attribute with value set to 'true' if
found in the class. This class process must be completed before continuing to read the
sequence.

Each class contains a type of attribute that declares the function to process the value
attribute.

**"wait" attribute (optional) is a flag that halts the executions of a reading sequence of
classes until the class with the wait flag finishes. It then continues reading the sequence
and executing the classes in parallel until it finishes or meets another class with a wait
flag. To do attribute tell what the function should do**

Functions:

"greedy_lock": same as "greedy_lock" on the server-side. It asks for the server to assure the
client that all the listed clients in the "value" attribute are ready to take orders only
from the following actions alone until it finishes.

"high" / "low": they represent two functions in the client python app, one for "high" other
for "low", these two functions shall read an array of pins found in the "value" attribute in
a sequence but run in parallel (none wait for the other to finish) and run "high" or "low"
function on each pins number directly, or overtime depends on the pins array value at each
position, the array may contain three types of pins representation:
- by direct PIN like 1, 2, 3
- as a name of pins group (for example, "alive") which look for pins number in the
pins array defined by "name" attribute in the pins__CN__.json and read "value"
attribute to get all pins number. ["alive"]
- as fire on time pin or pins array, the variable at index 0 is either one PIN, a pins
array, a name of pins group found in pins__CN__.json, or combined of pins group
names and pins numbers, and the second variable is how many times to repeat, 3rd
variable is the time between each fire of the "high" / "low" function, 4th variable
is time to stay on that status before the change to the opposite status and make the
other loop, 5th variable is how long to postpend the first fire of the "high" /
"low" function on those pins [["alive", 2, 3, 4], 3, 1600, "+3000"]
- it can be a combination of two or more of the above. [1, "gls", ["alive", 3, 1600],
2].
The "high" and "low" functions consistently report to the server either "on" or "off" for
each object found in pins__CN__.json, and its "visible" attribute is not set to false.

The status section in the server GUI gives the ability to the user to change the status of
any group of pins; on click an order sent to the owner client to flip it is status. If the
group of pins is set to "low" then run the "high" function on that group. If the pins are
set to "high" then run the "low" function. Either way, update the status of that group of
pins at the server GUI.
Pins in the client are raspberry pi GPIO, so the max number of pins
for each client is 26. Each pin will work standalone from the client's
main thread on a job thread. The job thread does have a queue of jobs.
The queue of jobs is sorted upon the time needed to fire the HIGH or
LOW functions. Each time the client orders a new HIGH or LOW function
on a pin, a job, or multiple jobs (fire on time string), add to the
job thread's queue. This job may fire directly when it turns in the
queue or upon a time if it is a scheduled job.

If the '+' sign is added before the fire the first time, ex "+3000",
then that first time is added to the last scheduled time for that pin
for this new job. For example, a new scheduled after +2:21 min job for
pin x that has a scheduled job after 1:33 min from now, the new job
for the pin x first fire will be planned after 1:33 + 2:21 = 3:54 min.

Example of queue

name Pin 1 Pin 2 Pin 1 Pin 1 Pin 4 Pin 3 Pin 1 Pin 26

Time 0:00 1:00 1:30 2:00 2:02 2:02 2:30 2:39
(m:ss)

Add pin 1 after +2:00 schedule

name Pin 1 Pin 2 Pin 1 Pin 1 Pin 4 Pin 3 Pin 1 Pin 26 Pin 1
Time 0:00 1:00 1:30 2:00 2:02 2:02 2:30 2:39 4:30
(m:ss)

If no '+' sign is added before the fire the first time, ex "1000",
then that first time is added to the current world time for that pin
for this new job

** Wait time can be '0' or '+0' **

Example of queue
name Pin 1 Pin 2 Pin 1 Pin 1 Pin 4 Pin 3 Pin 1 Pin 26
Time 0:01 1:01 1:30 2:01 2:02 2:02 2:31 2:39
(m:ss)

Add pin 1 after 2:00 schedule

name Pin 1 Pin 2 Pin 1 Pin 1 Pin 1 Pin 4 Pin 3 Pin 1 Pin 26
Time 0:01 1:01 1:30 2:00 2:01 2:02 2:02 2:31 2:39
(m:ss)
"conditions_met": the value of it is "conditions" attribute consists of an array of
"on_special" conditions strings that were met by doing this step in action; ["Hello
conditions"," love"," die"], the client must check "on_events" and see if any events have it
is all conditions met with this change and then run it if found.

All conditions met are for this client only but reported to the server to keep track.

"conditions_unmet": the value of it is "conditions" attribute consists of an array of

"on_special" conditions strings that were unmet by doing this step in action; ["Hello
conditions"," love"," die"], it turns the switch off that these conditions are met.

All conditions unmet are for this client only but reported to the server to keep track.

"show": show on full-screen mode with no control of the video or photo on the screen of the
client or run the audio on the background with no control. (follow same server media rules)

"status": send a status from the client to the server. The server shall complete the response
action for that status silently if found.

"ring": do the call and update the ringing status on the server, for example:
Ringing tries… 1/8, Ringing tries… 2/8, No answer, Answer, playing record,
playing complete (wait 2 seconds then change to 'ready…'), ready to do Ringing
The call do_ring function does the Ringing for eight tries with a gap of 1000
milliseconds in between at the start of ringing function "on_special" condition
"on_ringing" is met do events and on "on_ringing_end" condition is unmet, then:
-If nothing happens during the tries: end call and update status on the server

-If during the tries received:

*end_call order, then cancel the Ringing and update the status.
*on_answer function has been called(you create this function) it shall stop the
Ringing and :
-If audio is found, then "on_special" condition "on_hang_up_media" is met,
and "on_hang_down_media" is unmet, do events and then play the audio, and at the end,
"on_special" condition "on_hang_down_media" is met, and "on_hang_up_media" is unmet, do
events.

-else then "on_special" condition "on_hang_up" is met, and "on_hang_down"

is unmet do events, and then it sends answer status to the server and waits until it
receives the "end_call" order fire by press end call on the server GUI then
"on_special" condition "on_hang_down" is met, and "on_hang_up" is unmet do events and
then on the client-side end the call.

** at the end of Ringing for any of the above reasons, "on_special" condition
"on_ringing_end" is met, and "on_ringing" is unmet do events

**during Ringing tries or answered but without media, then CALL button on server
GUI change to END CALL with red background and white font, pressing this button to send
the end_call order to the client.
 **the ringing function in all parts shall continually update the status on the
server.

***For any condition is met, check if any on_events want it, and run the events
if found before continuing…***

Play the audio at "on_answer" function shall be started and ended by doing actions for
all "on_event" object with "on_special" attribute with data equal "play_record" and
"on_high" and "on_low" attribute empty or their values met the current pins situation.
On stopping the "on_special" attribute data equal "stop_record" and "on_high" and
"on_low" attribute empty, or their values met the recent pins situation, on the end of
playing the record.

(follow same server ringing rules)

"message": show a message to the user. The value attribute is an array, the first index is
the message, the second is how long to stay on screen in milliseconds, and the third is the
media to play with if needed. The value attribute could be only a string; it shows the
message for 30 seconds before dismissing that string as the message. (follow same server
message rules)

"log": send to a server a status message that will be appended in the log list in the server
GUI.

"sleep": stop reading the sequence of classes for a while; equal to it is the value
attribute.

"functions": it is an array of functions array. Each function array consists of the

function's name to run in the client python app at index zero, and the rest is the value of
the variable to send to this function in order.
{
"orders": [{

"name": "gls",
"post": 3000,
"actions": [{

"type": "greedy_ lock",

"value": true
},
{
"type": "conditions_met",
"value": ["gls"]

},
{
"type": "high",
"value": [1, "gls", ["alive", 3, 1600], 2]

}, {
"type": "high",
 "wait": true,
"value": [3, "dead", "alive 3 1000", 6]

},
{
"type": "low",
"value": [6, "gls2", [15, 3, 1600, 1000, 3000], 1]

},
{
"type": "low",
"value": [6, "gls2", [[1, 2, 3, 4], 3, 1600, 3000], 1]

},
{

"type": "message",
"value": ["YOu ARE DEAD", 30000,"alive"]
},

{
"type": "show",
"wait": true,
"value": "video1"
},
{
"type": "sleep",
"value": 3000
},
{
"type": "low",
"value": [6]

},
{
"type": "ring",
"wait": true,
"value": "love"

},
{
"type": "status",
"value": "done"
},
{
"type": "log",
"value": "done"
},

{
 "type": "status",
"value": ["done", "done2"]
},
{
"type": “log",
"value": "we complete step one"
},
{
"type": “log",
"value": ["we complete step one", "ha ha ha"]
},
{
"type": "functions",
"post": 3000,
"to_do": [
["gls", 1, 2],
["war", 1, "ha ha", 3, 6]
]
}
]
},
{
"name": "hi_call",
"post": 1500,
"actions": [{
"type": "high",
""value": [6, "alive"]
},
{
"type": “log",
"value": "playing video"
},
{
"type": "show",
"wait": true,
"value": "video1"
},
{
"type": "status",
"value": "alive"
},
{
"type": "low",
"value": [6, 7]
}
]
}
],
**on_events contains an array of conditions set by the value of "on_high", "on_low", and
"on_special" attributes of each "on_event" object of on event. When all conditions are met,
it shall run the actions attribute of that "on_event" object. 'Actions' attribute shall run
as shown before in the same way. The app shall always follow up with pins status change and
check if any of the "on_events" objects met and run its actions attribute if it met.

"on_high": means that all the pins in the following array must be high for the condition to
be met.

"on_low": means that all the pins in the following array must be below for the condition to
be met.

"on_special": means that this action condition only met if the attribute value, which is
either it is a condition or an array of conditions encountered.

Condition is a string key for a hash table with a value either "true" (met) or "false"
(unmet). The condition can be added during the runtime by using "condition_met" and
"condition_unmet" action functions, or it can be a pre-defined one like "on_ringing". When a
condition is changed status by and "condition_unmet" action functions, the client app should
check immediately if any "on_event" object shall be run on that situation; if yes, it should
be run directly before continuing reading the sequence of actions.

Depending on its status, pre-defined conditions could be updated only by the client app.

"condition_unmet"/"condition_met"

**"__CN__" can add to the string of conditions that are sent to "condition_unmet" or
"condition_met" in that case, this condition will be met/unmet only for the client with a
name equal CN, for example, "on_r__GLS__".

**if no "__CN__" is found in the string of conditions that are sent to "condition_unmet" or
"condition_met" then this condition will be met/unmet only for the client with a name equal
CN, for example, "on_r__GLS__".

Type of predefined “on_spechial” conditions:

1. “on_message_show” / “on_message_unshow”

when a message has been shown, then on_special condition "on_message_show" met, and condition
"on_message_unshow" unmet when no message is showing then on_special condition
"on_message_unshow" met and the "on_message_show" unmet

2. “on_call_on” / “on_call_off”

when a call is processing, then on_special condition "on_call_on" met, and condition
"on_call_off" unmet when no call is being processing then on_special condition "on_call_off"
met and the "on_call_on" unmet
 3. “on_media_show” / “on_media_unshow”

When a media is showing then on_special condition "on_media_show" met, and condition
"on_media_unshow" unmet when no media is showing then on_special condition "on_media_unshow"
met and the "on_media_show" unmet

4. “on_effect_play” / “on_effect_stop”

**when an effect is playing then on_special condition “on_effect_play” met, and condition
“on_effect_stop” unmet when no effect is playing then on_special condition “on_effect_stop”
met and the “on_effect_play” unmet

5. “on_ringing” / “on_ringing_end”, “on_hang_up_media” / “on_hang_down_media”,

“on_hang_up” / “on_hang_down”

When the ringing function is trying "on_special" condition "on_ringing" is met and on
"on_ringing_end" condition is unmet, then:
-If nothing happens during the tries and end call then the "on_ringing_end" condition is met
and "on_ringing" is unmet

-If during the tries received:

*end_call order then cancel the Ringing then "on_ringing_end" condition is met and
"on_ringing" is unmet

*on_answer function has been called, it shall stop the Ringing, then the
"on_ringing_end" condition is met, and "on_ringing" is unmet.

-If audio is found then "on_special" condition "on_hang_up_media" is met and

"on_hang_down_media" is unmet, after playing the audio "on_special" condition
"on_hang_down_media" is met and "on_hang_up_media" is unmet.

-else, then "on_special" condition "on_hang_up" is met and "on_hang_down" is

unmet waits until it receives the "end_call" order fire by press end call on the server GUI
then "on_special" condition "on_hang_down" is met and "on_hang_up" is unmet.

"on_events": [{

"on_high": ["pins", 1, 2],

"on_low": 3,
"actions": [{
"type": " high",
"value": [1, "gls", ["alive", 3, 1600], 2]
}, {
"type": " high",
"wait": true,
"pins": [3, "dead", "alive 3 1000", 6]
},
{
"type": "low",
"pins": [6, "gls2", [15, 3, 1600, 3000], 1]

},
{
"type": "message",
"value": ["YOu ARE DEAD", 30000,"alive"]
},

{
"type": "show",
"wait": true,
"media": "video1"
},
{
"type": "sleep",
"wait": 3000
},
{
"type": "low",
"pins": [6]

},
{
"type": "ring",
"wait": true,
"media": "love"

},
{
"type": "status",
"orders": "done"
},
{
"type": " status ",
"orders": ["done", "done2"]
},
{
"type": “log",
"messages": "we complete step one"
},
{
"type": “log",
"messages": ["we complete step one", "ha ha ha"]
},
{
"type": "functions",
"post": 3000,
 "to_do": [
["gls", 1, 2],
["war", 1, "ha ha", 3, 6]
]
}
]
},
{
"on_low": 3,
"on_special": "on_ringing",
"actions": [{
"type": "show",
"media": "video2"
}]
},
{
"on_high": 3,
"on_special": "on_ringing_end",
"actions": [{
"type": "show",
"media": "video2"
}]
},
{

"on_special": ["play_record", "on_ringing_end"],

"actions": [{
"type": "show",
"media": "video4"
}]

}
PINS JSON
THES ARE RASPBERRY PI PINS, SO MAX COUNT IS 26 GPIO pins for each client, but that doesn't
mean the maximum number of pins' group is 26 too.

These files are used to declare a name for pins' groups. These names are used to build the
status of pins in server GUI and make pins in the "actions" attribute more simplified (write
a known name instead of remembering all pins numbers).

The "text" and "icon" attributes are used to build the object for the status of the pins
section in the server GUI. If the "text" attribute is not presented, the "name" attribute is
used instead. If the "icon" attribute is not given, it is left blank.

There is to status for pins either ON or OFF and two functions on each pin, high or low.
These two functions change the status of pins from ON to OFF. Vice versa, The 'on' attribute
value is either "high" or "low". If it is "high", then the "on" status is when the "high"
function been called on that pin, and "off" status if "low" function is called, if "on"
attribute is "low" then "on" status when calling "low" function and "off" on-call "high"
function.

The value attribute can be a set of pins, a single pin, a set of names of other pins groups,
or combined choices. When there are two or more pins in the value attribute ([1,2]), then the
status shall be affected by them all with '&' between them (is 1 ON & is 2 ON then ON else
OFF). If a group of pins names found [1,' live'], then that group of pins 'on' attribute
affects its status only, and only a pins number is affected by the 'on' attribute of the
current group.

** "input_pin" declare if this pin is input ("true" value) or output ("false" value), which
define the way the app should detect the changes in its status; if it is output, then it
should follow up with the "high" and the "low" function to update the status during the
client app running. Still, if it is input, then it should use the built-in GPIO
"add_event_detect" to detect status change:

********This is only to show a sample code, but in the actual app, it should be tested if it is safe for the board and working fine
by the programmer********

import [Link] as GPIO

[Link]([Link])
[Link](7, [Link], pull_up_down=GPIO.PUD_DOWN)
Last_status_is_high = true

def my_callback(channel)
input = [Link](7)
if input and not Last_status_is_high: # and check again the input
do something it change to high
Last_status_is_high = true
elif not input and Last_status_is_high:
do something it change to low
Last_status_is_high = false
GPIO.add_event_detect (7, [Link], callback=my_callback, bouncetime=300)

**remember how to detect the status affect the app, especially on_event

**any group of pins that don't have input_pin attribute set to True or declare by it is number only outside of pins__CN__.json
should be treated as an output pin.

{
"pins": [{
"name": "gls",
"text": "love",
"icon": "love_acc.ico",
"on": "high",
"input_pin": true,

"value": 16
}, {
"name": "alive",
"text": "alive",
"icon": "[Link]",
"on": "high",
"value": 10
}, {
"name": "dead",
"icon": "[Link]",
"on": "low",
"value": 11
}, {
"name": "all",
"on": "low",
"value": [12, 13, 15, "alive"]
}]
}