stryd_one

Sweet I got it right :) I'm getting better at this electronics crap, slooowly ;) Glad to hear it's all OK mate!

Midnight UTC tuesday night/wednesday morning is the time, and the PayPal Development Button in the top right corner of this page is the place :)

Shum see that "Delay between Sysex Blocks" thing? crank that up to 20 and see how it goes... Edit: Oh, and try MIDI-Ox....

Incomplete sysex bytes and resets, sounds like it still has problems with power or midi... Anyone have a list of error codes? What's 0B 01? Buggered if I can be bothered trawling source code right now ;)

That's a bit more obvious ;) Yeh $1 was just the minimum, I'd like to think we could say a bigger 'thankyou' than that ;D

Here's a thought for you though, a $50 Pentium 2 with a gameport midi interface running linux/PD can happily do the conversion from MIDI to OSC...And some other funky processing on the way :)

Cool thanks for the news smash! Take your time bud :)

Well silverfish looks like just a day or three to go, but a very poor turnout. Very disappointing. But even if it's just the two of us... Maybe we can donate enough for a nice cold beer ;) I'm going to pay up at midnight UTC tuesday night/wednesday morning. Anyone else ???

Nice!! :D Thanks again AC!

bingo. 2 points to audiocommander :)

Just looking into OSC, looks like it's focussed on 32 bit data, so is it worthwhile to implement on an 8bit MCU?

It's not impossible but it's not easy at all... Oh and if I remember rightly OSC runs over UDP so you'd have to write a TCP/IP interface too. Much of the work is already done in publicly available source code, but even strapping it all together is a big job. You could look at something like the Microchip ENC28J60 or similar... an IIC - Ethernet+TCP/IP+OSC module would be doable... But what for? Is there any practical use that MIDI couldn't cover off?

There is no such thing as too much Japanese food :)

Looks like 6U high to me. Nice job on the milling! What's the plan for the legend, screen print?

Ahh you didn't mention custom mappings before. Yeh you'll have to do it the way you said above. FWIW the sequential way works out somewhat lighter on codesize and instructions... It's a tradeoff, features vs size/speed, which is pretty typical. I'd stick with they way you've got it so you can include custom mappings.

I assume that the byte you XORLW with will be different for each event yeh? Have you considered using one of the compare W with F commands? It might save you some code size and allow it to be more modular. That whole repeated code things looks sus.... Edit: won't bother, seeing as I now know about the custom mappings, which disallows a sequential approach

It's already 10-bit, you would have to send (N)RPN's or pitch control to use it though. Have a search for RPN on the forum and you'll find lots of info :)

Well someone has to be the first to ask...Hey Smash are you going to stock the new IIC_MIDI module? :)

LOL Just picture a box of ganjaPot going through customs ;)

That adds another meaning to the phrase 'porno music' ;D

Well then one would need to implement the "other, faster interface" first. IIC_Ethernet perhaps?

Might be harder than you've envisioned. What you describe is like the way that digital touchscreens work (as opposed to resistive/conductive analog touchscreens) but you've missed a few little details which are required to make it work.

That'd be your problem...

That sh*t is a voodoo science to me, I've never made time to see how it works.. I think I have a mission for tomorrow. ugh...

Japanese MIDIBox Soup. Tasty.