Variable Storage Table with TCP-IP-Sync [BETA]

[chackl]

Hello!

I've just developed another "usefull" eaxample.
This is the first Time that i used Ruby on my own so please if some ruby expert would be able to check the rubycode - well it is working but my ruby basics are not that good

What does this little thing do?
* You will be able to define a variable and a value as STRING
* All variables will be stored within arrays
* The whole variable-table is sync-able ofer network

What could be done with the variable-table
* You are able to store some data combined with a name for the data
* Changing the data of the variable
* Read out the data from the table

What enables the Network part of it
* You are able to sync the data - so if you change data in one table the network will spread it to all other conected
* You are able to have all same variables with the same value in several FlowStone apps on one ore more PCs
* This little thing will also help at "Multi-Instance" if you want to send data from one FlowStone-App to another FlowStone-App
* If one app crashes all other would not lose the conection and sync on - it is built up witrh a P2P structure that was made from me.

Things you need to know
* You'll be able to store any String into the table
* If you do not enter any data to the value, the variable will be ignored/ existing variable will be deleted
* Be careful not to get any Data-Feedback-Loop
* SAVE SAVE SAVE!!!! - FlowStone seems to have problems with TCP-IP if it gets complex
* The Network server will not be checked before conecting!!!
* The first started Sync-Server get priority and will overwrite maching variables to all peers that will conect after it.
* There are only up to 20 IPs possible - anything higher will slow down the System

CHANGELOG:
BETA0.2:
* Added DNS-Lookup for IP-Set
BETA0.3:
* Some Bug Fixes
* Added DATA-Security: Re-Send & Send 3x


Well i hope you like it
Feel free to ask any questions!
Feel also free to use it / change it - please reupload changed here again - i'll try to merge all sugestions here!

Regards, C.Hackl

[Tronic]

What would happen if an application instance on the same machine, crash ruby?
This has not yet been solved on the exe, continue to use the interpreter in a shared manner.

It will function safely, only application instances on different machines,
as for now every instance of application running on the same machine,
sharing the ruby interpreter, so if the interpreter crash, all other instances will no longer work.

it would be better to have an external dll to do these things, also to the benefit of performance.

But it seems that Malc wants to implement a primitive to call external dll.
As long as you do not actually know how will be the real implementation of the ruby,
and if there will be the possibility to call external dll, we had to stop every project,
because each update changes the system and you have to redesign everything,
and this is not nice on large projects

[chackl]

What would happen if an application instance on the same machine, crash ruby?
This has not yet been solved on the exe, continue to use the interpreter in a shared manner.

Well i did several tests in the last time - i heard that there were Problems at some users - i also know that some vst Hosts have Problems by using ruby - but i do no vsts anymore - because VirtualDJ is not able to get ruby loaded

But what i do is that i use several rubymodules from here and i absolutely NEVER had any Crash within the ruby runtime in exe files. BUT: I also have to say that i had severals crashes when i was developing this thing here. I can't find out what has gone wrong, i only know that there are a lot triggering Problems with the networkmodules - so i think that the Network modules did the Crash.
I have a complet rubyless Version here (uploaded here) but it Needs more CPU and has several Trigger Problems (This was just a preview Version for me)

It will function safely, only application instances on different machines,
as for now every instance of application running on the same machine,
sharing the ruby interpreter, so if the interpreter crash, all other instances will no longer work.

I designed this Little Thing for my next bigger Project that Needs to sync up with 4 PCs - The multi-Instance is just an Little extra ^^

it would be better to have an external dll to do these things, also to the benefit of performance.

But it seems that Malc wants to implement a primitive to call external dll.
As long as you do not actually know how will be the real implementation of the ruby,
and if there will be the possibility to call external dll, we had to stop every project,
because each update changes the system and you have to redesign everything,
and this is not nice on large projects

Well we will see what and where this will get us - i have to say that i'm not a great fan of external dlls because they have to be made also and i do not like "write lines" if it is not needed - this is the reason why i do not everything in ruby now ^^

But if there is a Ruby-Crash with this module in an exe please tell me here - i had never such crashes until now.

And here is the OLD NON-RUBY Version

[chackl]

BETA0.2:

I added DNS Lookup to the IP segment:

Instead of adding here an IP you are able to use the computername within the network.

Some Exampoles:
COMPUTERNAME = It will just get the IP and use the default port of the Server
192.168.2.XX = Any IP and it will use also the default port of the server
COMPUTERNAME:2001 = This will take the name to IP and connect to TCP-Port 2001
192.168.2.XX:2002 = This will connect to IP with TCP Port 2002
@LOCAL = This will get the local IP (The aktual computer you are working with)
@LOCAL:2000 = TCP Port 2000 on local computer

Regards, C.Hackl

[chackl]

BETA0.3:

I fixed several bugs that i found during testing.

New - DATA Security
This means if the Signal is changed (for any reason) the Server will note it and correct it.

Re-Send:
Does a simple resend of all variables. For default the server will sync one variable within 500ms. For Ethernet this is no problem.

Send 3x (Tripple-Send)
This means the signal gets sended 3 times. If one byte changes within one of those the server is able to correct it.
All bytes are compared and the most existing byte will take priority
Example where all 3 signals get broken but the server will be able to fix it:
******************************************************************************************
Data you send: 01 02 03 04 05 06 07

Data 1 received: 01 02 03 04 05 42 07
Data 2 received: 01 02 03 44 05 06 07
Data 3 received: 88 02 03 04 05 06 07

After Compare: 01 02 03 04 05 06 07
******************************************************************************************

Regards
C.Hackl

[steph_tsf]

hello chackl,

I found your post very interesting. I just completed a Flowstone design, and would like to split it into two entities, a Server and a Client running in two separate x86 computers.
The Server would compute two Float arrays, each having a length of 256, every second.
The Client would query the two Float Arrays on a regular base, possibly every second also.
There may be a "return" data path, like the Client telling the Server what is the required length of the Float arrays.

Can you please sketch a Flowstone canvas, that I would reuse on my side ?
This is Speaker Lab, located here : http://www.dsprobotics.com/support/viewtopic.php?f=3&t=1607&p=7391#p7391

Regards,
Steph

[chackl]

Hello!

Well

The client does not have to querry anything - just the server has to send out all in regular parts - and there is the hint -> All green data of flowstone are not realtime!!! - the timing is not acurate enough so the server will send one on sec 0.98 the next will kome on second 2.3 - it ist realy impossible to get a constant time trigger flow in green.

In ruby there is no problem doing that - BUT we have no TCP-IP modules for ruby or thay have to be coded if possible.
I experimeted already by getting sound ofer networt and i failt at the whole line - because of the timing issue.

Regards

[steph_tsf]

hello chackl,

Please don't feel discouraged. For Speaker Lab the jitter caused by the green math can be huge, it won't ruin the functionality. If you manage to get the Client/Server update delay anywhere between 2 second to 4 second, with a jitter of 2 second, that's okay for me. I was only quoting "1 second" to give a practical idea. In Speaker Lab, the trigger is under the supervision of the Analyzer, and doesn't need to be exported through TCP/IP.

Really, if you can publish a .fsm showing a barebone Client/Server arrangement of such kind, that will be very helpful.

By the way, the reason why Speaker Lab goes now towards a Client/Server arrangement is because of the Green Math jitter, and quite unpredictable USB+DAC+ADC+USB processing delays, especially when the PC is saving a file on disk, causing hiccups in the audio, and lost frames. Don't worry, I feel home with those limitations, I understand them fully, and I will apply the necessary adjustments and/or workarounds without complaining about your proposal.

Regards,
Steph