Posted on

Silicon Droid Inc. OV SSL certificate.

We recently got our site (www.SiliconDroid.com) SSL-OV certified, It involved having a local registered lawyer who knows us write an “opinion letter” proving that we are a legitimate registered company (Silicon Droid Inc.)

What exactly is OV SSL? Here it’s explained by Sectigo:

“Organization Validation (OV) SSL certificates provide an extra level of online trust by authenticating the business identity and legitimacy. Organizations must prove it owns the domain name it wishes to secure and confirm that it is a legally registered business. This extra level of confirmation makes OV SSL certificates an ideal option for public-facing websites representing companies and organizations as well as sites requesting money or information from users, such as e-Commerce.”

You can audit our certificate yourself; just click the padlock icon in your browsers address bar to view the certificate information.

Posted on

HEXEN V2 Released

Hexen, our modular synthesizer was updated to version 2.0 recently:
Here’s the version 2 release history up to the latest stable release:

< V2 .20 >
Loading last rack on startup is now an option (defaults to off).
Log Text button moved to top level menu.
Tweaked DEMO_15.

< V2 .19 >
Trying to fix rack loading hang on some devices (bad module position parse will fall back to sequential module stacking).

< V2 .18 >
Added DEMO_15.
Added new “Log Text” button in settings menu.
Fixed some underlying logging code that was found to be not totally thread safe.

< V2 .17 >
Trying to fix rack loading hang on some devices (wire bezier list functions changed).
Upgraded status now recognized when offline.

< V2 .16 >
Trying to fix startup hanging on some devices.

< V2 .15 >
Trying to fix startup hanging on some devices.
In MODULES object code, changed system scoped mutexes to app scoped object locks.

V2.14
< V2 .14 >
Double click module zooming now uses range you choose on slider.
Added loading percentage counter.
All texture atlases limited to 2048.
All graphics now use OpenGLES3.
Tweaked DEMO_13.
Tweaked DEMO_14.

< V2 .13 >
Double click module zooming now uses range you choose on slider.
Added loading percentage counter.
All texture atlases limited to 2048.
All graphics now use OpenGLES3.
Tweaked DEMO_13.
Tweaked DEMO_14.

< V2 .12 >
Improved graphics.
Added new demo (DEMO_14).
Made module textures hi-res.
UI now defaults to right handed mode on new installs.
Shaders now preloaded on boot up.

< V2 .11 >
Improved button graphics.
Added new demo (DEMO_13).
Fixed 2D theme (went invisible in V2.10).
Made rack texture resolution hi-res (again).
Various other graphics tweaks.

< V2 .10 >
Small dark text labels on LED buttons restored.

< V2 .09 >
Render speed increased with better GPU batching.
SCOPE module fixed line drawing shader (was pink and half missing).
Camera distance range reduced to prevent Z fighting when zooming.

< V2 .08 >
After adding a new module the menu system is now closed automatically.
MIDI crashes on some phones, MIDI module disabled while we find a fix.
LCD text in controls pushed forward slightly to prevent Z fighting when zooming out.
Reduced boot up time.
Main rack texture resolution increased back to 4096 square.
Added new demo (DEMO_12).

< V2 .07 >
Changed min/max android APIs to 26/33 to fix midi bluetooth crash on some devices.
Refined pinch/zoom to be smoother (still room for improvement).

< V2 .06 >
Removed location permission requirements.
Reduced minimum compatibility to Android 7.1 Nougat (API 25).
Reduced rack texture resolution to prevent crash on low RAM devices.

< V2 .03 >
Updated to Android 14 (API 34).
Offline registration.
Improved graphics.
Faster core DSP routing.
Zoom and scroll with pinch gesture.
Theme and color now separate options.
New button to quickly add module.
When adding a new module it will be placed near last touched module if possible.
When deleting a module patch cables will be added to replace the deleted module if possible.
HEX Mixer CV inputs now normalized 0…1 and multiplied with slider value (before were added).
RADIO module now always uses SSL connection over HTTPS.

Posted on

Slow Shipping to Europe

We’ve noticed that all of the #IOTA Watches shipped from Silicon Droid in Canada to Europe are experiencing relatively long delays. These delays seem to be happening to many overseas parcels entering Europe. We were surprised to see parcels getting to South Korean customers without delay. We checked all of the tracking info and it all seems OK, just delayed, so sit tight and enjoy your watches when they arrive, thanks again for your order!

Posted on

Interactive NFT concept (INFT)

What are INFTs?

Imagine Interactive NFT pet dogs that were 3D Tamagotchi, with interactive animations and audio, that’s far more fun than a regular NFT! Owners of such INFT pets could watch them explore their virtual cages, could pet them, feed them etc.

Requirements

INFTs must load within 3 seconds, preferably within 2, nobody wants to wait for their INFT to load up. Making INFTs load quickly is also environmentally friendly as it requires less data to be transmitted over the internet: the engine core binary data must be small: <~ 5MB, preferably <~2MB

INFTs must run smoothly, with a frame rate: >= 30Hz, preferably >= 60Hz.

INFTs must be viewable in all popular browsers running on all popular OSs. No browser plugins should be required. You send the link to anyone and that person should simply click on it to view the INFT.

INFTs of the same type shall use the same engine core stored on the server. For example an INFT pet dog range could procedurally spawn a million dogs using the same few megabytes of engine core data stored on the server.

Each INFT owner would be given a unique URL like: www.website.com/nft/IJdgktVekkCBjY3ai6j4y. The unique 128 bit code on the end prevents anyone without the URL from viewing the NFT. The 128bit code is read by the INFT when it starts running.

The INFT loads a small (<~1KB) metadata file from the server whose filename contains the 128 bit code. That metadata can specify a number of unique attributes for the INFT, like the owners name, the genome of a virtual pet etc. This means that a million dogs would only require a million metadata files (<~1GB).

The core engine binary data will be cached by the users browser, this means that after a user has viewed one dog, they only need to download the metadata to view another dog, this has the added advantage of reducing loading times greatly after first viewing.

Some persistent state of an INFT may be stored as cookie data in the client browser. This would be perfect for storing things like viewing preferences of artwork etc. It (cookies) is a very attractive solution because it scales without central server impacts.

NOTE: Local cookie storage would not be perfect for a pet dog state, because every different browser instance would have a different dog state, but it would still be fun, and from the perspective of a single browser would be consistent and solid.