Narwhal
-
Posts
226 -
Joined
-
Last visited
-
Days Won
2
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by Narwhal
-
-
The old Emagic AMT-8 and Unitor 8 are very capable, stable, low-latency 1U MIDI interfaces with 8 ins and 8 outs.
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.
-
Would this help?
http://www.buildingi...ete-review.html
Someone would still have to get the keys, but it sounds like TestFlight would make it a lot easier to share the app with other people. It's free, too..
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.
-
Thanks TK.
I can compile again... and again. But there no installing on an iPad, because I don't have an developer account. Any chance somebody could include the installable app here, or is impossible install it that way?
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:
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.
-
On google I've seen plenty of stuff with the atoi function but it doesn't seem to work with me.
I have a string that looks like this: "0xA3" and want to put that A3 hexadecimal value into a u8 number.
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.
-
hi guys, have been developing an controller app of my own, just out of interest, can anyone think why this zero-conf method midimap is using has never been used before?! seems like the most obvious solution, but due to never hearing about it, i assumed it wasnt possible!
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:
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.
-
If ipMIDI becomes a defacto standard, it shouldn't be a big problem to provide it as an alternative option. The protocol is simple but primitive compared to OSC. I guess that the transfer performance is almost identical.
This is a controller which uses the Bonjour based protocol: http://futuremusic.c...or-apples-ipad/
According to the german introduction, no other iPhone/iPad application uses it yet, but the big advantage should be Plug&Play (no driver installation required)
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.
-
Guys, there is no real need to discuss about MIDI options via ethernet.
As mentioned before, there seems to be a standard solution for the iPad provided by Apple.
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.
-
Yes, different page views for more comfortable parameter entry makes sense and they are easy to realize.
I guess that at the end the "HW frontpanel" view will only exist for historical reasons ;)
Memory leak: I will check this once I get my hands on the real device - otherwise debugging will be too time consuming.
It's strange that printf() etc. are not working - the simplified version is implemented in printf-stdarg.c
Best Regards, Thorsten.
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 failedI'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. :-)
-
Plan B would be: find someone with a CNC router who can cut clear acrylic.... hmmm... *hint* :)
Yeah Twin-X why not route some acrylic for us? ;)
<ducks>
I will happily route some acrylic with my own CNC when I'm certain that I can get quality results. PM me if you have some spare acrylic you can send or a cheap source for practicing on? Work is consuming a lot of time right now, so the other thing to consider is that I may be kind of slow in getting to the point where I can make things. But making stuff like this is my ultimate goal, so hang in there.
-
BTW PCBs for the "bleeding edge prototypers" have arrived. POIDH? GTFO!
POIDH!
-
The case you have is clean an tidy nice work. Is it an old rack enclosure of a pc?
It's a rackmount SCSI drive case. It was made to hold 8 SCSI drives (5 vertical, 3 horizontal). I removed all the drive holder bays.
-
Awesome Twin-X! Way to hijack my thread hehehe :P
Looks like we'll have lots of production options without ever having to get robbed by FPE. :D
I'm sure, just based on stepper sizes that yours will run jobs much higher ipm than the micro.
Here is the case I put together this weekend to contain all of the drivers, parallel port isolator, and the relays.
DWA4dlC-W9s
-
Pity. I would quite a like a mill for 19" rack panels. Do you think it would be feasible to mill a panel as two separate jobs, so as to fit within the 12" limit?
I'm planning to make a jig to do 19" panels in 2 passes. I think it will be very easy to break up a g-code file into 2 separate jobs. Surely a script could be created to do it with a jig and little creativity. I think g-code itself is kind of a joke, but the skill of it probably comes mostly from knowing what is the best way to approach a particular material and pathing to produce the best cut.
-
Awsome, what are the cost for the machine?
I believe his cost right now is $1799 all inclusive for version 2, but I think it's going up to $1999. Mine is a version 1 and I did not want to get a computer and I bought in when the basics unit cost only $499 (I bought a few of the things that are now included (tool plate base, and spindle) and have spent $799). Brainchild (Grayson) seems always willing to make a kit up of just the parts you want if you want to take a chance and use your own computer (BTW I got lucky on this any my super old AMD Athlon computer gave great results when tested for realtime performance). Even the most bada$$ PC nowadays may not give you the greatest results you might think, but you'll have to research this yourself by going to www.linuxcnc.org and try out the EMC2 ubuntu CD.
Tascam MM-RC Conversion to Midibox
in Miscellaneous
Posted
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.