Update
Video below
So that's what is working right now.
It's kind of neat . I've been at this point with SmileNet for two days now.
There's a slight issue with getting the letters to interprete uniquely. I'm going to attempt changing that as we speak.
I'm just working on A and B right now.
The issue mainly is that frequencies that are playing drop into the next 'listening' window, even as they are dying down.
This dying down of audio causes the stopping sound part of a previously playing frequency to actually be interpreted (using zero crossings) as a totally different frequency so when playing for instance, the B tone into SmileBasic, as the tone stops: My algorithm seems to detect the tone at the next 'listening' window as a B input.
This is input pollution and I haven't found a strong way to fix it yet without either creating extra delays between listens or somehow throttling it.
There's a better solution and the solution I'm going to try next is pair-inputs.
Pair inputs is a cool idea and I'm not sure it's widely used anymore but at one point or another it probably was.
Basically you get initial input of a signal.
Then you expect the same input to repeat once, to confirm that the signal is not lossy or bad.
If you can't get a pair input that matches both times then you assume some interference, and start over.
This is fine if operated by a human because the human can just repeat the input seeing that it failed the first time.
For more broad and real-time applications it isn't an ideal way to deal with signal loss.
I haven't gotten to dealing with the PC-end of things yet so perhaps after I do I can come up with a nice error-correction ratio.
I'm considering using a sigmoid function on the pc end.. or better yet.
An adjustable tone-frame rate.
Yes.. that's right.
An adjustable tone frame rate would allow SB to send the "same" data in the same tones backwards to the PC end.
This tells the pc program "This is the signal I have. "
The pc program can then compare the signal it used to the signal SmileNet's framework interpreted on that frame and issue a sync-wait.
This sync-wait can be used to better tune the pc program and the SmileNet framework to work together in synchronicity.
The goal this week is to get SmileNet to an input state that can allow me to type "Hello World" using my pc and to see the letters come up on the 3ds screen interpreted from a real time analog signal. if I can achieve this then I can move into trying to shrink the frame-window of the signal.
This is strictly speaking, a time domain issue at best. So it's not going to be too hard to solve. It's been done a lot and there are a variety of solutions that are reasonably quick that do not require FFT.
This means that probably on the 3ds end I'm going to try my hardest not to force people to use the dlc until I absolutely can't speed it up anymore.
At which point the features will be available without dlc, but enhanced with dlc so you will have two options as a SmileNet user.
Wish me luck. and yes eventually we will get SmileNet working with Twitch chat. ;)
*∞
