RtMIDI under qt 4.7; using port 0 for midi in and midi out ports, using MIDI channel 1 to send and receive.
This works perfectly under OSX. Sends and receives, no issues whatsoever.
It compiles fine under Windows (running in a VMware Fusion Windows XP VM on my Mac), and the app can SEND messages to my control surface, but receives nothing... I never get a callback, so no midi input. Both the open of the MIDI input and output devices seem to go ok, no errors raised.
I can switch back to OSX, run the same app (compiled for OSX of course) and everything works again with no config changes on the control surface.
so : The surface is connecting and opening (it receives MIDI under windows); but I get nothing FROM it.
Am I missing something here?
TIA
Under Windows XP, the device opened for input needs to be device 1 (of 0...1)
Under Windows 7 starter, the device opened for output needs to be device 1 (of 0...1)
Under OSX, both input and output need to be zero.
That's all it was. A config dialog later, problem solved (well, at least handed over to the end user.)
RtMidi is a nice package, little short on documentation, but other than that, super.
Under windows device 0 is always the windows media player midi synth, midi devices start from device 1.
You can make the midi port selection by name if you read the port names then select the index value offset, that allows for the changing port positions when other devices are added/removed so your program selects the same default midi device.
Unlike OSX, Windows doesn't necessarily keep the input and output ports of the same device at the same ID/portNumber. Cool huh?
A config dialog is really helpful, but if you know one port then you can search through the port names of the opposite IO direction to get its counterpart.
Related
I currently have a pi zero which acts as a bluetooth keyboard which - when attached to a computer - types text read from the SD card. I followed this tutorial https://www.rmedgar.com/blog/using-rpi-zero-as-keyboard-setup-and-device-definition. I use only the USB "Data" port, to power it up and to send data.
This setup works really fine on nearly all computers I tested it on, just on some Windows 7 systems it is not working at all. The system where it is not working on identify the pi zero as "Unknown device" and then never "re-identify" it as the keyboard which it is supposed to be.
All other systems first identify the device as "Unknown device" and after some seconds "re-identify" it as the actual keyboard. IMO the problem is the one mentioned by scruss in this post: https://raspberrypi.stackexchange.com/questions/60056/cant-see-raspberry-pi-zero-via-usb-otg-on-windows-10
I'm looking for a possibility to fix this problem. Is there some possibility to configure the pi zero in a way that during boot it does not identify as any USB device. Maybe that during boot the data USB port acts only as a power USB port.
Or can I turn the USB port off and on after a boot so that form the computers point of view it looks like the usb devices is removed and reattached??
I fixed that with the help of a colleague.
The solutions seems super simple - just remove the usb gadget and add it again.
The code necessary is equally simple:
#Remove usb gadget
echo "" > UDC
#Add it again
ls /sys/class/udc > UDC
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).
I am trying to detect if my iPhone is in the same network as my Raspberry Pi. I would like to execute a script when I am at home and my iPhone's presence is registered in my LAN.
It seems that when the phone is in standby not even the iphone-sync port (6207/tcp) is found. "/usr/bin/nmap -n -sT -p62078 [my phone's local IP]" shows no host. I wonder what else I could scan for. Obviously the phone is online and ready to accept facetime calls (data via 3G is deactivated). Could I accomplish something with avahi which I am using on my Raspberry Pi, or are there other ways.
I've just spent a week beating on this problem so I can refrain from sending SMS home alarms to my wife when she's at work.
Pinging won't work because the iPhone won't respond to ICMP when asleep. Reading the ARP cache won't work because a sleeping iPhone will come and go (check it every 30 seconds for a few minutes).
The only way I have found to 'reliably' determine when my two iPhones are on my local (home) network is to use the PCAP dotnet library to look for any packets originating from either of the phones' MAC addresses. For example, if you run Wireshark with the capture filter
ether src <iphone-mac-address>
you will see a surprising amount of network discovery/announcement traffic from the phone. It still has quiescent states, but so far the longest interval I have seen between captured packets is around 10 minutes. You would have to wait until you have not heard from the phone for some interval (I use 15 minutes) before declaring it not-home.
With this technique you will find a phone quickly when it rejoins the home network, assuming your phone is configured for DHCP. I also use port mirroring on my main Ethernet switch to include traffic from my wireless access points.
I don't have a Raspberry Pi solution for this, because my linux expertise is very limited, but someone else may be able to help you along those lines. I have a Windows Service using the PCAP library and so far it works reliably, with the limitation of waiting 15 minutes before deciding an iPhone has left the network.
* update 2-3-2018 *
I have this detection algorithm down to about 5 minutes, using a combination of ping/arp messages directed to each phone, about once per minute. Seems to work great.
You can find a list of devices on your network by investigating your arp cache.
arp -a
Simply write a bash script to run arp -a at a regular interval, and search for the mac address of your phone.
You could go even further with this and perform different actions depending on what brand of device is connected.
The first 3 hexadecimal digits of a mac address are the vendor id.
Take the following mac address:
00:19:E3:AB:CD:EF
00:19:E3: is one of the registered mac address for apple devices.
By comparing the devices on your network with this list, you could detect when for example a '3com' device, or a 'dell' device attaches to your network.
http://www.coffer.com/mac_find/?string=apple
You can do "arp-scan -l -r10" for that (tested this myself), but the problem is if mobile data enabled the iphone will go and suspend wifi if screen is locked to safe battery. so you need to disable mobile data .. then arp-scan will work.
We have some boxes running Windows XP for an automated production process. I (not me personally but a robot) connect new USB devices to these boxes. There is a device driver for this device type and it's loaded after connecting a device and running like a charm.
But ... it takes about 8 to 10 seconds after pluging in a new device until it is accessible. When I connect an already previously seen device again it only takes 3 seconds. The driver has a catalog file. It's not signed by Microsoft WHQL but uses a test certificate we have installed on the machines.
There is only one inf/pnf file to be considered and so I wonder why it takes so long to detect a new device, create the information in the registry and load the driver.
Time is money and so I need to speed up the process.
Any hints for me? Especially does somebody know that WHQL-certified drivers are recognized more quickly by Windows / device manager?
These devices have unique serial numbers, correct? That's part of what Windows uses to create the per-instance data necessary to track whether it's seen this device before. In the case where you plug in a device that's already seen before, Windows will pick up the old instance data and load the appropriate driver. If you plug in a device that Windows has never seen before (e.g. same VID/PID but different serial number), it needs to go through the process of creating registry entries, parsing the INFs to find the correct driver, etc.
Are you sure those devices that show up quickly with WHQL'd drivers have never been attached to the system before? Also, are these systems configured to connect to Windows Update to look for drivers when a new device is attached? It's definitely true that Windows will prefer a WHQL'd driver over an unsigned (or self signed) package, so it's possible that Windows is trying hard to find something else before defaulting to your self signed driver.
-scott
Am I missing something glaringly obvious or is there no way to debug an iOS app which uses an external accessory that's connected via the 30-pin dock without using a bucket load of logs etc. I want to be able to use things such as breakpoints and Instruments.
Is there a way to remote debug perhaps, over Wi-Fi, Bluetooth?
Note: Yes, I asked this very recently and I deleted it because I thought I found the answer.. but the answer was only Instruments has support over Wi-Fi.. not Xcode debugging. So the question still remains...
And so...: Given that I've had no real luck finding the answer, and no one has given me an answer as yet - I take it that it is a big fat NO. :(
Makes me wonder are we just expected to magically guess where bugs occur, or log the crap out of everything while wearing out our dock connectors by continuously moving it back and forth between the device and accessory?
Time to file a bug report I guess.
At CES today, I talked to a developer from Wahoo Fitness that makes an ANT+ accessory for iPhone. They had this same problem, but found a solution.
They found a pass-through dock extender that has a mini-USB port. They used the mini-USB port for debugging while the accessory was connected.
The product they were using is http://www.cablejive.com/products/dockStubz.html
This blog talks about remote debugging iOS with a dock accessory attached
You could connect the external accessory to another iOS device (not the one tethered to the Mac running the Xcode debugger). Then tunnel all your EA framework messages from the accessory connected device to the device running the app being debugged over a pair of wifi sockets. Look at the code for tunneling accelerometer messages from a device to the iOS Simulator (a common trick for debugging game code on the Simulator) for one example of how this could be done.
After further researching, and having seen that people had to do sending strings over Wi-Fi to get around this, I'm concluding the answer is no.
I have filed a bug request for this.
In the mean time, it seems like the Wi-Fi logging, and on-device text logging will be the way to go for now.
Here's my understanding for why just the USB protocol works for some external accessories and doesn't for other external accessories. Looks like a fundamental problem, without an arbitrator, two masters can't talk to a single slave over USB, a serial Master/Slave protocol. So XCode is one master, the iPhone is the slave device. If the external accessory is a master too, one won't be able to connect the iPhone (Xcode slave) to the second master (the external accessory).
Probably the Wahoo Key for iPhone" is a slave device and that's why the dockStubz solution works for such an external accessory.
I have tested the dockStubz. It doesn't work for my external accessory. As suspected, the USB protocol can't be used to have two Master devices controlling a single slave device. Trying to hook up a Mac (Master) (via the mini USB ) & an external accessory (Master) (via the 30 pin connector) to the iPhone 4 (Slave) causes the iPhone to go in loop of connect & re-connect.
Following looks promising too, though expensive: digi.com/support/kbase/kbaseresultdetl.jsp?id=485.
Has any one tried to use USB to Ethernet connectors and use a router to route requests from two masters (XCode & External Accessory) to the slave (iPhone)? I am off to Best Buy to purchase USB to Ethernet cables and hook all three on to my IP router. Will report if it works.
This is what will be needed :
http://www.bestbuy.com/site/IOGEAR+-+USB+Ethernet+Extender/9614781.p?id=1218131339965&skuId=9614781&st=USB%20to%20Ethernet&cp=1&lp=1
http://www.frys.com/product/6103339
So connect XCode mac using the male end into the USB slot of your computer. . Use a ethernet cable to connect this to a router.
Connect the iPhone to the female part of the IO gear connector. Connect it to the router via ethernet cable.
Connect the external accessory with the male connector (Sabrent USB to Fast Ethernet Network Adapter.) Connect it to router.
I am still researching if this will work. Just ordered the parts. Will get it by Friday & will report back then.
Update:
The IOGear male end draws too much current when connected to router. Also, the female end can't charge iPhone when connected to the router even when 5V USB current supplied.
So tried to directly connect the iPhone to the USB slot of the router (used for printers). It does charge the iPhone. Also used USB to Fast Ethernet Network Adapter (BestBuy had one to connect Wii via USB) to connect the Mac to the router. It did connect to internet but couldn't find the iPhone. In the router client list I don't see any login entires for the iPhone. So this experiment was a failure unless someone have other pointers.