I have a bit of an unorthodox question. I am trying to do a little pet project purely out of interest and willingness to mess around for fun and giggles.
I want to read data (bytes, bits or whatever I can) from my rocksmith cable(usb cable attached to a guitar), and just go whack at it in some c# code. I actually have no idea if this is even possible. I have been playing around with libraries such as SharpUsb and LibUsbDotNet, but they don't seem to pick it up as a device, which kindof makes sense.
I also tried using System.IO.Ports.SerialPort, just to see if I can pick up anything but it does not.
So smarter genius people out there. Is this possible ? Any advice/ideas of what I can try ?
Any advice or ideas will be very much appreciated! For me this is purely an out of interest project for fun.
Thanks in advance!
Since the rocksmith Realtone cable is a usb to guitar cable, all you should need the dll file for that piece of hardware and import it into your project / call the proper methods associated with it.
More than likely the code will be in C++, so you will need to use DLLImport function as well.
Any further than that, I'm sure you could figure out where to go from there. You could possibly use XNA and use the microphone class if you have that usb device set as your default microphone, although, that is just a random thought.
Related
There are 3 projects: MyEXE and MyDLL in C#, and TheirEXE in C++.
All three projects are on the same computer, which I can upgrade if required. I use TheirEXE every day. I plan to get TheirEXE to use MyDLL for added functionality. I was told I would need to write a C++ wrapper for MyDLL because TheirEXE is COM. The details are frankly over my head but they will help so I assume it will work.
If I can get TheirEXE to reference MyDll, then I want a fast named pipe or some form of fast data transfer between MyDLL and MyEXE, capable of transferring in either direction a few dozen distinct 50 to 200 byte packages per second with high reliability.
Security is not an issue. Is this possible? Many thanks in advance for any help!
You can use named pipe or even a standard TCP-Socket (what way it would be ready to do it remote). I personally would go for the TCP-Socket but its a matter of personal taste I would say.
I have a problem that I think is very common among low-level developers whose start working with high-level languages. I made some research but didn't find a suitable solution to my problem.
I have a client-server application and I want to re-create all the client, from "scratch" using C# but as I want to keep the server as it is, the "new" updated client have to follow the actual protocols of sending and receiving data packets.
If the packets just contains unmanaged types (byte, int, etc) it should be ok, but my problem comes up when I have to work with strings between the managed client in C# and the unmanaged server in C/C++.
I already have found some solutions for this problem, but I really don't know which is the best or if there is a better solution that i didn't notice.
The first approach is use the fixed keyword to create structs that represents each packet of the application and doing this the C# allows me to easily and with very low cost (I guess) do my pointer casts (from byte* to packet_structure* and vice-versa) without worry about all the marshaling and other expensive methods. I think this approach is particular bad because forces me to use a sbyte data type on the buffers where should be a string in the packet and then make a cast to bring these bytes to the managed world to be properly processed.
The other approach I have made was to declare the struct of each packet as managed but marked with MarshalAs attributes to make use of the Marshal's methods for converting the data. This approach I think is more expensive, considering that the application is a game and the client, which I'm doing, is a real-time application. I think that make extensive use of marshaling on each packet can be very much expensive for the application.
Is there any simple and beautiful solution which I could follow something like C style or any other solution that my inexperience is denying me? In C a very simple pointer cast should be enough to free me the problems.
I'm in love with C# but I'm veeeery afraid I couldn't do this with this platform :(
Anyone could please shed me some light? :/
Thanks very much for your time, any kind of help will be VERY appreciated.
first I'd wanna say this is my first question here, I'll try to comply to the asking tips the best I can... Also I couldn't find a way to post this in a specific C# section so I just used it in the title.
What I'm trying to accomplish is intercepting the sound output of TeamSpeak, and figuring out which person on the channel is producing the loudest sound. I had a look at TeamSpeak SDK but it's more intended for building your own VoIP software than fooling around with TeamSpeak itself...
At first I'm just going to make a simple program that shows the names of the persons and a dB bar (or something that represents loudness) next to them.
I was surprised to see there isn't much discussion around this, I think there's a lot of cool snippets to be made (this one will be for kicking spastics swiftly.)
Does anyone know of an open source H.264 encoder in C# (or any other managed language)? I might be able to make do with a python implementation as well.
The libraries that I’ve found (e.g. x264) are written in pretty low level c (procedural with lots of macros) and assembly. Tweaking them is turning out to be far more complex than I'd thought. My project has no concern for performance or compatibility. We just want to test how some ideas will impact the perception of the outputted video.
We’d be willing to pay for or license the code if need be.
Thanks in advance!
Edit - Some important points:
I don't care about performance (e.g. real time encoding) at all. It could take 10 days to encode for all I care.
A wrapper isn't helpful since I want to actually modify the encoder itself.
No one would likely spend the time to develop the codec in those languages because they would be hopelessly slow for actual encoding. However, the reference implementation should be less optimized and more useful to you. It is still in C.
http://iphome.hhi.de/suehring/tml/download/
I don't think there is already such a port you need - you'll find wrappers for any langugae but a pure implementation does not have the critical mass. I'd recommend to port it yourself, document your port well and then start tweakening it.
If you'd want to port some encoder to C#, this should be easier to start with - about 8k LOC: http://sourceforge.net/projects/fevh264/
How about http://www.ffmpeg-csharp.com/?
http://forums.alliedmods.net/showthread.php?t=64767
The source acts like its missing a ton of stuff I can't find like uh TBX and some other things
I don't really know the language, but I have hoping I could get it to compile with delphi 2009/2010.net and then see about porting its IL. (to C# I guess)
The reasoning behind this is because pawnstudio is crash happy but the program (layout, syntax highlighting, the fact that the intellisense (clamsense) works with functions from includes, in the file, etc) is really easy to use.
Can anyone help?
That is a really, really bad idea. Stabilize first, then port (if needed). Porting introduces problems, and it is not nice when you cannot tell if the bug is existing or new.
[edit] I've downloaded the source. It is not what I'd call modern, well-refactored Delphi code. Long functions, no object-orientation visible, all code in the form event handlers.
TBX you can find at Torry
If you are using Delphi 7 you're using the VCL/various components native to delphi.
Those are NOT present in c# (in Delphi 2009/2010 probably yes), so you can't do a naive port, you will need to redo most of the program. (at least the interface part)
TBX is not yet supported but you can look at spTBX
It will not be very easy to port in C#.
If you don't know Delphi, you ought to get someone who does to help out. Delphi's an easier language to work with than most, but like any language it has subtleties, complexities and dark corners. If you try to port it without the necessary domain knowledge, then not only are you reinventing the wheel, you're reinventing it half-blind. Especially if you're not able to compile the original and test it.
What units does it say are missing, BTW?