I've got a guitar amp with a midi interface. I'm planning to see what's possible with the device that hasn't been built-in by the manufacturer. Since I have no experience with MIDI I'd like to know if it's possible to ruin a MIDI device by sending wrong data.
I'm not sure what data I'd like to send, and the device is basically a black box without documentation, so I can't give much more details. But one thing I'd like to attempt is overwriting the built-in effects.
MIDI commands are parsed and executed by the device's firmware.
Whatever effect(s) a command has is determined by what the firmware is programmed to do when it receives that command.
Typically, unknown commands are ignored, so it should not be possible to ruin a device by sending random data.
Most devices do no have any permanent state.
However, some devices allow upgrading their firmware through MIDI, so if you use the correct SysEx command, and manage to get any checksums correct, it would be possible to replace the original firmware with your own code (or some non-code that prevents it from working).
Related
Since we are still struggling with sending and receiving bluetooth data, we want to try a different way, ignoring bluetooth for now.
Is it possible to write a software, which Windows or Linux is recognizing as a Hardware Gamepad for simulating (so we only need to change the input of that tool to bluetooth input later)?
And if it is possible, what do I need to know for achieving that? Thank you!
(We are using C/C++)
I tried searching around, but couldn't come up with much on the topic of this.
Is there an API or code within various Security API's that would allow some sort of passcode locking mechanism to enable whenever a device is connected (by Bluetooth, etc) and disable whenever said device is paired with the phone? An interesting concept I had thought up earlier today but can't seem to determine a method available for this.
The concept is pretty much this: if the phone is close enough to be connected over Bluetooth to the device (would be something like a smartwatch or other wearable computing) then the phone is on you and passcode entry can be disabled. However, when the device is not found by the iPhone, there is a physical distance between the two devices and the phone should lock up and not allow entry. This could even be some form of superficial lock mechanism on some apps (which exists already) that could activate based on this proximity awareness. This method is meant to failsafe by being a "lock first, then check" mentality that is paired to a specific address of the wearable computing. This could, in theory, be hacked, yes, but for general usage allows a user to have a no-maintenance method that can save some passcode entries from time to time should one find it annoying, but still want it's security potential.
Again, this idea is based on the assumption that said device connecting to your iPhone that the phone itself is searching for is physically latched to you somehow.
Thanks and I appreciate any sort of input or direction.
I have an external device that we manufacture that basically monitors 4 voltages, converts them to a 16 bit digital number then streams this info back to a PC every 100mS or so, using a serial over USB style chip. Basically a data logging system.
We would now like to collect this information on an iPhone and I am wondering what is the best way to get the data into the iPhone?
I am assuming there is no way we can physically connect directly to the iPhone dock connector as the protocol to do this is not available to iOS developers?
Obviously we could do it over a WiFi network but there will not always be one and we want to keep the external hardware fairly simple, i.e. no need for a computer or Wireless router etc.
If we add Bluetooth connectivity to our hardware would this work? I read that only 'Made for iPod' type Bluetooth devices will connect, in which case how can we achieve 'made for iPod' status? It would be relatively easy to add the necessary Bluetooth chips to get the system up and running.
In an ideal world we would like to do this without having to use a 3rd party interface.
I have been thinking about trying to digitise data as an audio signal – like a modem, and send it into the line input jack, but I don’t think it will be fast enough – this would be new territory for me.
Anyway all suggestions gratefully received!
Thanks!
Intro: I have a Denon S-52 internet radio with an iPod/iPhone dock (the older 12V kind, so charging is not possible with newer devices but audio/control data is passed through). The radio has an external clickwheel-like control that worked beautifully with iPod nano/classic etc. Since the iPhone/iPod touch no longer have any clickwheel functionality, the signals from the Denon clickwheel no longer have any effect while playing (ie no seeking), but can navigate through some menus on iOS, and play/pause works. The few clickwheel apps I've tried obviously ignore the external signals.
Questions: How hard would it be for someone with no iOs programming experience (just C/C++/C#, plus an objective C tutorial from lynda.com) to develop a basic audio player app that would accept signals from the external Denon clickwheel to seek within an audio file (for my own use, at least at first)? I'm assuming this is possible because the signals are sometimes processed (as mentioned above), but I'd be happy to be proven wrong before I waste a lot of time and effort. I also assume a standard $99 iOS developer membership would be enough (since the device itself is already MFi)? Or perhaps an app that has this feature already exists?
How hard would it be for someone with no iOs programming experience (just C/C++/C#, plus an objective C tutorial from lynda.com) to develop a basic audio player app that would accept signals from the external Denon clickwheel to seek within an audio file (for my own use, at least at first)?
Nearly impossible. It's not just the challenge of figuring out how to access the dock connector and interpret the signals of interest. The real problem is that you want to use those signals to control music that's playing, and you're probably thinking of trying to control the iPod application rather than writing your own music player. Communicating between two apps is difficult at best, and probably not possible if the target app (iPod) doesn't provide a mechanism for external control. And the fact that you're new to the platform doesn't make any of this easier.
Your best hope is probably to file a bug with Apple requesting this feature and hope that they'll add it for you.
I was able to do this by jailbreaking my iOS device, which enabled me to access the serial port for iPod Access Protocol communication at /dev/tty.iap. Then I could incorporate something like the functions found in this iPhone Serial Port Tutorial (check archive.org if the link no longer works) to read the incoming signals and respond accordingly.
Update: An even better solution seems to be to write a tweak hooking into the iPodUI private framework and intercept the commands directly, and then message the Music player about what to do (see this post for more details).
Is it possible to transfer files of a bluetooth device, lets say a digital pen (e.g. Nokia or Logitech io2) to the iPhone? I am interested if I could do a native application that could somehow get that binary file sent by the digital pen and do something with it.
I am used to rfcomm and obex but I can only find inconclusive results when I search for that and the support in the iPhone SDK... Any ideas?
No, on a normal iPhone you are totally unable to do this.
However, it is totally capable and the functions most likely exist, but Apple doesn't want people using them so you aren't going to find anything in their documentation. An extremely large number of these functions exist. If you wrote an app containing one of these functions, Apple wouldn't let it into the app store.
They're extremely and reasonably concerned about safety. Bluetooth isn't exactly known for being secure in any form.
Look at the EAAccessory reference.
It seems like it should be possible to write a custom app that talks to any bluetooth device - you'd have to implement the file transfer protocol yourself, but now that apps are free to talk to bluetooth devices I don't think the API will prevent you from doing what you stated you want to do.
To my knowledge, no – the iPhone OS does currently not support filetransfers via Bluetooth. I think you will have to jailbreak the software to get enough access to the Bluetooth stack to pull it off.
It is very telling that even if you have Bluetooth turned on in your iPhone, it does not show up on other devices when searching for units to transfer files to. I suppose it's saying something in its Bluetooth signature that tells other devices that it doesn't receive files.