I would use an Omnimount : https://www.omnimount.com/products/speaker_mounts_and_stands/speaker_mounts/stainless_steel_series/25.0_c/
The critical part is making sure that the mount is attached to the ceiling in a safe and secure manner. I would make sure that your mounting bolts can handle at least five times the load you are suspending.
Noise Generator is a processing block found in the tools menu. Hex-string to set Pink Noise
02 88 79 80 1B 83 00 01 19 00 01 00 00 00 01 6A 03
// Program dependent addresses
Node = 79 80
Object = 03 00 01 19
// Object addresses
Parameter = 00 01
Data = 00 00 00 01
This is why this forum matters.
Even though the OP is about a year old I'll answer since I had to deal with this recently. Digest authentication essentially hashes (using MD5) several pieces of login information several times that makes decoding this information very difficult. I couldn't find any netlinx libraries that offered the functionality of MD5 hashing (which, by itself, is not a secure way of hashing sensitive information) but you can create your own function based on this pseudocode. https://en.wikipedia.org/wiki/MD5#Pseudocode
The process requires you to first send a simple request for the desired resource on the server and the response will be 401 (Unauthorized) along with a few pieces of information that you'll need to authenticate as seen in this example.
The pieces of information needed to finish authentication are as follows:
username: sent as "plain text"
realm: sent by the server in the first response
nonce: hash generated by the server and sent in the first response
uri: the resource you are requesting from the server (without the protocol and host)
qop: sent by the server in the first response. Depending on the value given from the server, you may need to hash different pieces of information together
nc: 16 bit counter padded with 0's. Depending on the server, you may have to increment this. In my case I could always send 00000001 and there was never a problem
cnonce: a random 4 Byte hex provided by the client device
response: this is the MD5 hex that is calculated based on what the value of the qop field is, sent by the server
opaque: a hash string sent by the server in the first response. In my case the server never sent this so I omitted it in consecutive requests
I had to develop a module that would connect to a server for a REST Web API. If I got the 401 response code I would go through the authentication process and save the necessary values if I needed to continue sending requests to that server.
Wikipedia was extremely helpful in developing the module as well as this collection of libraries (especially the includes for http and uri):