This is definitely a interesting idea. I've though of doing something similar but don't currently have the knowledge to do so. I would love to see a concept like this brought into reality.
Potential for SmileNet, a smilebasic based net service. (using sound analysis)
So yeah this is happening.
]
I'm teaching myself how to do analog to digital processing of sound.
So far i've been able to isolate one sound but not two.
Once I can isolate a differentiating set that is different than silence (in total 3 possible values)
I can begin on the numeric transferance algorithm.
This algorithm will not be based directly on FFT (Fast fourier transform) although depending on my time and reading comprehension I may borrow more than one trick from it if my math skills are up to the task. (they've been improving but not by leaps yet)
So here we go.
The plan:
Create a service mainly for users to plug into (literally)]
Requirements:
You will have to use a splitter cable in your 3ds and you will have to connect both the mic and speaker to a pc.
You will have to install a pc program.
You will have to leave smilebasic running to stay connected.
Limitations would be you can't hear game sound. While connected.
Possibilities:
*An eshop style software downloader for smilebasic programs since we can both save and load programs already.
*User based key system for storing and retrieving keys from the web.
*Non blocking server that allows connected users to utilize it. (Asyncronous packets)
*The ability to finally have a live chat inside a smilebasic game that isn't laggy.
*Yet another (silly) and alternative way to connect to SBS chat (possibly?)
*Item trading or other turn based goodies in smilebasic games.
How feasible is it?
Given that it will be mainly used for GAMES that don't require continuous (streaming) real time updates to stay connected.
Pretty feasible I'm sure.
Consider this player A wants to trade items with player B. Connect packets are exchanged and the handshake is at most going to be about 30 bytes between both players.
30 bytes can be sent fairly fast...
once connected different message packets can be sent in series of less than or equivalent to 3 bytes at a time.
Sending of ASCII characters would only require 2 bytes, the first byte telling the system that a character is coming through.
The message handler would be up to the user to code themselves.
An always on pc server would allow a connected pc to connect, and then the user would have to plug their 3ds cables into the pc headphone and mic slots.
Other possibilities?
If the latency isn't horrible, more than two player or three player games could be possible.
Games that feature rich items and the ability to trade or collect those items could be very feasible.
Something similiar to mystery gift in pokemon where users connect and get a trade.
Server PROVIDED events in SmileBasic games.
Basically on SmileNet there would be a network lay out as such
Network Lay out Proposal:
Spoiler
[]- One dedicated pc running a server.
- A 3ds running smilebasic connects to the server and tells the server through their pc what the ID of this server is.
- The PC server only sends packets meant for the id of the client coming in from other 3ds's.
- If the client ID the user is trying to connect to doesn't exist as a 3ds that is also connected then an error message is displayed.
- This allows more than one network session to run on the same server in an asyncronous way.
- It would be possible to use C# to create new server instances per host ID.
- A 3ds either connects on the pc as a host or client.
- The 3ds plugin for SB would have a handshake built in to confirm that it is connected to the pc client application properly for easier debugging of network issues within it.
- The smilebasic app would also feature a paired optimize feature which lets you adjust your sound volume while audio plays into the mic with different samples to best adjust your data stream and reduce errors or random noise.
- Possible to give the pc client the ability to auto optimize and pair with the 3ds app and get a handshake going with clear audio. and minimal interference using an adaptive algorithm.
- A smilebasic program optimized to do network handshaking, allowing for interpreted audio analog to digital inputs.
- A computer application running on any pc platform to allow hosting.
- A computer application running on any pc platform to allow a client to connect.
- Possibility of more than one server on pc end running (for private or p2p connections).
- PC-END Server Software will probably not be distributed by me.
This is definitely a interesting idea. I've though of doing something similar but don't currently have the knowledge to do so. I would love to see a concept like this brought into reality.After this Thursday I'll have plenty of time on my hands. I'm looming forward to it.
They is a very grand idea with some very useful features. I especially like the bit about "An eshop style software downloader for smilebasic programs." I personally would use it mostly to allow updates to be downloaded to for my programs and probably less for multiplayer, but that's just me.
If you can do it, I'll use it.
They is a very grand idea with some very useful features. I especially like the bit about "An eshop style software downloader for smilebasic programs." I personally would use it mostly to allow updates to be downloaded to for my programs and probably less for multiplayer, but that's just me. If you can do it, I'll use it.Now that would be extra cool. You could have 1 key for the base game (or like v1) and just have it get updates over the Internet.
It's about time someone finally did this. I can't wait to see how it starts coming together.
I was thinking of doing this, but I am shit at networking, nice to see someone taking this up(oh yes, I also am terrible at modem stuff)All I need to do is isolate at best 3 sounds. The first sound isolated is the microphone's neutral input when noise is just being generated. The second sound isolated is the sound of a "1" bit. The third sound isolated is the sound of a "0" bit. once I have that I can begin testing timing of the mic input and hopefully stream 0's and 1's arbitrarily to the smilebasic program reading the input. After that I can test sending repeatable inputs to the 3ds and test for latency and interference. If interference occurs all I have to do is learn one (or more) noise reduction algorithms that allow the slope of the sound wav's data to remain the same (this can be done a few ways one way is to find the peak amplitude of the interference and then subtract all sound by it's distance from average static amplitude) Yes I literally just came up with that idea but it should work.. (so long as the expected input peaks can shift with it) This would actually also allow for dynamic interference reduction.. however it would also bring inconsistencies with inputs. Ideally we dont want any interference on the mic line.. so.. I need to really refine this part before moving onto transfering actual bytes. Bytes would be transferred by their bits at very high rates. of on and off pulses. additionally I might be able to create meta bytes by examining 3 bit input patterns. For instance 3 0's could either represent the first 3 bits in a byte or they could represent a stream of 255. Once I get to interpreting pitch, 128 values will be possible to send. if using a reservation technique a compression algorithm can tell the transfer protocall between pc and 3ds whether to enumerate and add a value to the input or not.. the value could be selected from multiples of 2 all the way up to 1/2 of 255. Allowing for byte values all the way up to 255 to be processed through. (this means transfering programs or data would be by the file's bytes into an array and then translated into characters within SB written then into a program slot and saved as a program.) Pretty complicated but since no one else is doing it and I have the dream I may as well begin. It might be slow and I may not make fast progress, just be warned. I should have results within a month at the worst case.
some new information has led me to conclude that at best scenarios right now we'd be getting about 5 bytes per second with my current translation scenario..
it's possible to capture way more data than that. but i'm not using any advanced algorithms yet.
I'm just trying to use the raw audio that the mic data provides.
If anyone knows what the actual mic data represents in SB that would be super helpful.
is it something like every 8180 positions is a single second? (8 bit at 8180 sample rate? )
divide by 1000 to get samples per millisecond?
8.18 samples per millisecond
roughly 8 samples per millisecond.
at that point if 8 samples per millisecond could somehow represent one byte then we could send 1000 bytes a second (1 Megabyte i'm pretty sure)
To reduce error we could probably send the same data 3 times, and then send a close-wait packet so Sb has time to analyze the averages. tHen sb would send an open/read byte. and the pc program would then be able to send more data in a stream (again 3 times each time ).
seperated by a second of noise.
This messaging handshake would allow data to come into SB in short bursts... which is pretty fast.
in a real time game it would (or could) appear very laggy.
or instead send less data in even shorter bursts but more frequently (less lag more updates, smaller packets)
I'm going to look into how the data processing works as well..
keeping posted.
Update
Been doing my research on algorithms and it looks like fft is what I want for smilenet. Still working on the 3ds being able to isolate specific sounds or patterns.
I can not seem to remove interferences enough to isolate a static value, therefore I'm going to need to use a frequency detection algorithm of some sorts.
For the keen and curious here's a very in depth link I dug up on sound modulation to data and back (convert waves to binary and back etc)
http://archive.oreilly.com/oreillyschool/courses/data-structures-algorithms/soundFiles.html
I can't read it all right now but it looks like I have a somewhat steep learning curve.
Conclusion so far: SmileNet is possible just going to take some real coder elbow grease and excessive amounts of digging and studying (maybe a bit more understanding of math )
oh look I made a typo. A silly one at that. ^^loomingThis is definitely a interesting idea. I've though of doing something similar but don't currently have the knowledge to do so. I would love to see a concept like this brought into reality.After this Thursday I'll have plenty of time on my hands. I'm looming forward to it.
Maybe check out the code for petit modem.
Maybe check out the code for petit modem.I'm afraid it isn't that simple. Petit modem is likely to obfuscate much of the algorithm into code that for me wouldn't be easily interpretable. I've checked it out before and there are several variables with very vauge names. It's not going to be easy either way ... unless perhaps the *author* of petit modem wants to jump on board this idea? XD
the *author* of petit modem probably doesn'tMaybe check out the code for petit modem.I'm afraid it isn't that simple. Petit modem is likely to obfuscate much of the algorithm into code that for me wouldn't be easily interpretable. I've checked it out before and there are several variables with very vauge names. It's not going to be easy either way ... unless perhaps the *author* of petit modem wants to jump on board this idea? XD
the *author* of petit modem probably doesn't even know about SBS, much less your project haha, we're so insignificant and smallhttps://smilebasicsource.com/user/rei_nntnd I know you're bad but you can do better than this. Anyway, like I've said before, though I really want to say little on the matter, Petit Modem is... off from where you want to start with this.
So I managed to get frequency isolation to work yesterday, and today.
Then I was working on making it able to stream the audio better through the mic today and realized that having vsync during the audio stuff isn't a good idea...
it slows down the loop significantly.
making this really only ideal for one-screen transfer type stuff.. unless it's able to take turns but for continuous non stop streaming it's really not going to work.
Here's a treat though: https://www.youtube.com/watch?v=V25WD6ErH98
I managed to make it stream almost perfectly (with noise and stuff in the way of course)
Using higher time windows (upwards of 4 seconds) causes the audio to play too fast.
I finally got it to not be as scrambly though and to play more complex combinations of sound which is neat.
...anyway Smilenet technically works and today I was able to mathematically determine a tone very close to what it actually was so it's coming along.
More updates when I have energy *spent all day on this again*
Then I was working on making it able to stream the audio better through the mic today and realized that having vsync during the audio stuff isn't a good idea...
it slows down the loop significantly.
making this really only ideal for one-screen transfer type stuff.. unless it's able to take turns but for continuous non stop streaming it's really not going to work.
Here's a treat though: https://www.youtube.com/watch?v=V25WD6ErH98
I managed to make it stream almost perfectly (with noise and stuff in the way of course)
Using higher time windows (upwards of 4 seconds) causes the audio to play too fast.
I finally got it to not be as scrambly though and to play more complex combinations of sound which is neat.
...anyway Smilenet technically works and today I was able to mathematically determine a tone very close to what it actually was so it's coming along.
More updates when I have energy *spent all day on this again*
Oh here's a BGMPLAY frequency generator if you want
INPUT F
N=LOG(F/440,POW(2,1/12))+57BGMPLAY FORMAT$("@D%D@255T12N%D",(N-(N<<0))*63,N)Thank you 12Me21 that'll probably be very useful for talking to the pc.