Narwhal

Ya I would buy one, rip it apart, and use it's guts inside your project. I'm sure there are schematics out there, and off the top of my head I would suggest Craig Anderton's book on guitar effects. Do-It-Yourself Projects for Guitarists and Electronic Projects for Musicians

You could merge a noise gate into the project so it's always built in as well.

The photos seems to have been lost in one of the forum conversions. Here is my Flickr set on the MM-RC. I'll see if I can dig up the eagle schematic that I was working on, but it's on a PC laptop that I user very very rarely.

And *plug* I'm the author of a free system preference panel for Unitor's and AMT8's on OS X. To some extent, the Unitors and AMT8's already allow you to do the internal routing configuration you want to do. GM5x5's are great as well.

That's a pretty good idea nangu. But someone would need to put together a build machine that gets SVN updates, builds the code with keys that are kept private, then publishes to a group of people with TestFlight. Then there is a limit (100 devices) to the number of devices that that TestFlight and debugging builds can run on. So this is not a good solution to the general public being able to install the app. For that someone will need to actually publish the code as an app on the app store. The other downside is that it really doesn't let someone do quick builds and test, everything checked in would become a live TestFlight automatically. On the flip side it's only $99/yr to be able do build anything you want on your iPads.

Sorry yoho, it doesn't work like that. You need security keys from both Apple and from a paid developer account to install on an iPad. You should be able to run it in the simulator without those keys though.

You will not need to buy additional hardware unless you want to reduce latency. At NAMM I saw a few hardware midi interfaces geared specifically to the iPad. Here are few links to those: www.iConnectMIDI.com Akai SynthStation 49 As for connection to PC's: A few apps you can use Tobias's windows rtpMIDI driver that we talked about here because on the iPad side it's basically free to code for that now in iOS 4.2 or >. I think you will get the best results that way anyway. A few other apps use their own methods of sending midi over UDP and in general most apps are good about having a server application available for both Windows and OS X. You will find the details on those applications on the authors webpages.

0xA3 is hex, you'll need and integer string like "163" for atoi() to work for you. But if you are going to do that, you might as well just write a hextoi() function yourself. Here is a simple conversion that will take a two digit hex string in the format "0xHH" and convert it to an int: #include <ctype.h> int hextoi(const char * valstr) { char valchr[3]; strncpy(valchr, &valstr[2], 3); valchr[0] = toupper(valchr[0]); valchr[1] = toupper(valchr[1]); int result = 0; int positionValue = 1; for (int i = 1; i >= 0; i--) { int valc = 0; if (isalpha(valchr[i])) { valc = (int)valchr[i] - (int)'A' + 10; } else if (isnumber(valchr[i])) { valc = (int)valchr[i] - (int)'0'; } result += (valc * positionValue); positionValue = positionValue << 4; } return result; } int main (int argc, char * const argv[]) { int result = hextoi("0xa3"); printf("%d", result); } If you want a char value result, it's easy to convert this function to do that.

Simply because the Apple-midi session protocol is not public. That means that there is no public specification for how to connect to a Mac that is running that network midi driver. As I show above, the only reason the MidiPad app is trying to do it is because one of the authors of the app has been involved with one of the protocols used (he is thanked in the RTP-MIDI document), and is also known to be involved in reverse engineering the Apple-MIDI session protocol (See the WireShark bug database links). So as of right now he is probably one of very few people in the world, outside of Apple, that knows how connect to the Mac's network midi driver.

** Like and idiot I edited, and amazingly deleted, my original message here rather than replying. So here is the new complete message with all the original info: Here we go: The midi service is browsable with bonjour on the iPhone/iPad. I just did it using a sample app called BonjourWeb that was installed from the xcode documentation. In the file "BonjourWebAppDelegate.m" I changed: #define kWebServiceType "_http._tcp"[/size] [size=2]to[/size] [size=2]#define kWebServiceType "_apple-midi._udp" Then lo and behold, when I ran it my mac showed up in the browser. If I click on the computer name it attempts to open the service on the phone, but it has no idea how to deal with it. Here are some links to details for the apple-midi protocol: CoreAudio mailing list 2008 RTP MIDI Page RFC 4695 RFC 4696 Sound on Sound article about how to setup the standard Apple network port driver MIDIShare Project that includes RTP Support RTP-MIDI seems to be far more advanced than ipMIDI as it is capable of handling lost packets. My current belief is that the MIDIpad guys have used this code to engineer their own connection to the apple-midi protocol. RTP does show up a few times in the dev docs, so maybe there is more there. The hunt continues... I just found more of a clue that the solution that MIDIpad is using is a custom one. One of MIDIpad's authors is Tobias Erichsen who has also contributed to the wireshark plugin that decodes RTP-MIDI and AppleMIDI session protocols. The source to these plugins is definitely illuminating as to the session protocol, and he has kindly included a capture file in the wireshark bug report.

Interesting.. if you turn up and info on how that's accomplished I certainly would like to take a peek at it. Maybe something in gamekit.. I'll snoop around there.

OSC would certainly work, but as you've documented elsewhere its a bit slower and is certainly a much thicker wrapper over the midi data than ipMIDI, which looks really awesome to me. Right now, I think any midi iPad apps that I work on are going to use that. What I was trying to say before is that there is no standard solution provided by Apple that I can tell of. At the time I wasn't really sure, but having just looked at "Core Audio Overview" in the iPhone documentation set, it clearly shows that CoreMIDI.framework, and CoreMIDIServer.framework are not available on the iPhone at all. Crazy huh. Yes OS X has a standard MIDI to Ethernet component, but its not available to even be accessed by mobile devices other than laptops. So this is why the one iPad app that I have right now uses DSMidiWifi.

It seems that the sprintf parameters conflict with something. Here are the errors it gives (I've shortened file paths): ../../../../mios32/common/printf-stdarg.c:205: error: expected declaration specifiers or '...' before numeric constant ../../../../mios32/common/printf-stdarg.c:205: error: expected declaration specifiers or '...' before '__builtin_object_size' ../../../../mios32/common/printf-stdarg.c:206: warning: conflicting types for built-in function '__builtin___sprintf_chk' ../../../../mios32/common/printf-stdarg.c:214: error: expected declaration specifiers or '...' before numeric constant ../../../../mios32/common/printf-stdarg.c:214: error: expected declaration specifiers or '...' before '__builtin_object_size' ../../../../mios32/common/printf-stdarg.c:215: warning: conflicting types for built-in function '__builtin___sprintf_chk' ../../../../mios32/common/printf-stdarg.c:222: error: expected declaration specifiers or '...' before numeric constant ../../../../mios32/common/printf-stdarg.c:222: error: expected declaration specifiers or '...' before '__builtin_object_size' ../../../../mios32/common/printf-stdarg.c:223: warning: conflicting types for built-in function '__builtin___snprintf_chk' {standard input}:unknown:Undefined local symbol L_MIOS32_COM_SendChar$stub {standard input}:unknown:Undefined local symbol L___umodsi3$stub {standard input}:unknown:Undefined local symbol L___udivsi3$stub distcc[78163] ERROR: compile ../../../../mios32/common/printf-stdarg.c on localhost failed I'm not sure what those __builtin___* functions are, or why they only conflict when building for the device. On the possible leak, I think it took about a half hour before it quit.

The response seems fine, but my fingers are big and those buttons are small. 40x40 seems to be the UI standard to iPhone and iPad. Seems like there is lots of space for UI options here. It would be fine if the LCD encoders were buttons and the main knob was all you turned. Notes: I had to comment out the two sprintf's, and snprintf to get it to build for the device. The right LCD is corrupted when it starts, but seems to fix up when you press any buttons or encoders over there. The app crashes when I let it sit.. memory leak?

Success. Video on the way.

Interesting app, but 79$!?! yikes. It can't be that hard to recreate it. Source for it would be needed to make use of that protocol on the iPad. I say we create an open MIDI UDP and TCP/IP Standard if one does not already exist. The proprietary stuff is ridiculous. BTW: I've been trying to get the iPad project to build for the device and oddly it has compile errors when device is selected. There is some crazy stuff you are doing there TK and I think some of the C to Obj-C bridging might be a little wrong from what I've been able to tell so far. I'm continuing to look into it, but I need to do some work for a client this evening, so I may have to pull myself away. It runs just fine in the simulator, but with this Mac Pro its hard to tell how much it will slow down on the actual device. I'll post some video when I get it going.

An iPad app that I'm using named AC-7 Pro is a Mackie Control emulator uses a Mac client called DSMidiWifi to receive from the iPad and transmit over virtual midi ports. It also used a midipipe setup to alter some messages. So from that it seems like running a client on the mac is necessary, but bonjour does seem like it would be a whole lot cooler. I'm at a developer conference called iPadDevLA this weekend, but I'll test out that project later today or tomorrow. Kurt

I'm a registered and active iPhone/iPad developer and I have an iPad here if you'd like me try out some code. Kurt

This app will let you drag any song you want on and off of your iPod. Assuming you use a PC. http://www.mediafour.com/products/xplay/ I forget the name of the app on the mac that does the same thing.

Hi Alex, It looks like its doing some alignment on the struct and zero filling with 3 bytes of zero for each struct in the array. I say this because each item has three zeros after it and that seems like a clue. If it is doing this, then the union elements are still working as you'd expect, its just that memory is being wasted in a different way than you might think. You could check this by taking the address of each element of the union. if (&menu[0].text == &menu[0].menu_func) { // then everything is still ok } It does seem to me that you can simply get rid of the struct all together. Something like this: typedef union { const unsigned char (*const text); //pointer to string const void (*const menu_func)(unsigned char); //pointer to menu-function } MenuItemType; MenuItemType menu[2] = {&testfunc,&teststring} Struct and union are actually quite similar to each other. Union is just a struct that has the additional condition that each item in it shares the same memory space.

Hmmm.. This took long enough that I wouldn't want to make hundreds of them, but I might be able to make a couple. :-)