History of the creation of SASER 2.0
History of the creation of SASER 2.0
The first SASER was released back in 2016, it was available as Standalone on the Max 6 platform and as Max for Live device. However, Cycling ’74’s policy with the release of SASER has changed. In Max 7, the internal structure of Gen~ patching was changed, which made it impossible to organize the broadcast inside the SASER application on the new Max for Live platforms. Moreover, even with the organized broadcast on the Max 6, such a tool could not be online for more than 30 minutes. It took years of hard work to coordinate the work of such a plugin with Cycling ’74. Now the Max 8 platform has managed to make the perfect code export, suitable for both the organization of trunk broadcast and music purposes. This required the creation of a new Hypervisor v9 from Compositor Software. The IPv6 SASER assembly process is viewed in the video below:
If you have already watched the video, I will make a few comments on it. In the video you can watch the process of connecting workgroups to the OSPFv3 IPv6 protocol. If the first SASER was completely in the IPv4 domain, the modern SASER allows you to multiplicate the length of the octet up to 32 bits, which in total gives a length of 128 bits when summing up four upscaled octets, which is the IPv6 address:
And you can access both EUI64 and EUI48 MAC addresses. Again, with the correct combination of parameters, you can connect not only through the network, but also at the device level, which allows you to see your local device as a member of a neighboring network, wherever such a network is.
It is believed that connecting via Ethernet protocol requires either a cable LAN connection or radio relay equipment capable of transmitting to the Ethernet network. The concept of an on-air network differs from the Compositor v9. In particular, in the video you can see how two beacon processes control RIPv1 and RIPv2 protocols. These are distance-vector protocols and the direction to the communication point indicates the torus in conjunction with the hypercardioid of flows. The result of this image is the multidimensional structure of Calabi-Yau. Z-spaces of which are equal to 16. This quantization is minimally sufficient to build a spherical picture:
What you see in the picture is the sum of spherical flows in quaternion rotation. Such rotation permeates space not only in 4 dimensions, like quaternion rotation, but sums up all 24 points of spherical space with the Z of the system, allowing you to quantize this space, filling it with additional translation points. This topology lasts until the next change of the multiplier by redrawing multidimensional figures with iteration that is difficult to predict. Therefore, the successful creation of the VLF (Very Low Frequencies) service can include more threads at the same time with an increase in the Z of the system. If the first SASER was on Z=4 and then at Z=8, then SASER 2.0 already includes Z=16 measurements.
Another thing is that connecting workgroups to Z=16, that in the Compositor’s system corresponds to the OSPFv3 protocol is able to create a larger network compared to Z=8. Given that the network includes 96 channels in total, when multiplying on 16 spaces, it already produces 1,536 points, not 648, as in the previous SASER. Therefore, in real time, in order for the broadcast network to produce traffic, it is necessary that each point produce at least one packet. Naturally, in a short video, such a volume of material would require at least 1 hour of broadcast, so I show the very principle rather than a physical entity capable of producing such a multicast effect.
