ultra

awesome. i had some problems with osc and ethernet on the liveapi side of things for my midibox live project, so i made a protocol over midi instead. i guess midi is the way to go anyway. :)

awesome :)

well the point of midibox live is so you don't have to know how to use liveapi. if you are comfortable with coding it yourself, you can certainly use it with the PIC core. the PIC can handle, i believe, 128 inputs. so basically you'll be using 40 inputs for the encoders. i think that leaves plenty of room for any button matrix. sending relative values is a good idea if you're using encoders. this way you can get any resolution you want out of it, and even modify it on the fly. for instance, note number could tell live what direction you're going, and velocity could translate into the percentage of change you want. let me know if you need any liveapi tips, i've gotten pretty comfortable with it. ultra

hey dev/null, on the software side of things, i am working on a project that integrates mios and liveapi. it would make it very easy for you to control clips and track their status. i assume you want the led/button matrix for these purposes. i started a thread on it here: http://www.midibox.org/forum/index.php/topic,12585.0.html and i started some documentation here: http://midibox.org/dokuwiki/doku.php?id=midibox_live ultra

yes this is the kind i was talking about :)

my opinion is that the panel mount type like the kind smashtv sells are best. you don't have to worry as much about perfect hole size, panel depth, or rotation.

check the pcb layout at ucapps to see where that pad connects to, and make sure there is continuity (ohm meter or continuity tester) from the bad pad to each other location it connects to. follow the traces out to see where they go. if you have a bad connection, solder in a small wire to the solder joints on the back. i hope what i'm trying to say is clear. ripping up a pad usually isn't game over. for soldering headers, here's what i do: put a small amount of solder on one of the pads. line up the header to the holes and flip it over. heat the solder and gently slide the header in. make sure it's flush and let the solder solidify. then you can solder the rest of them, and re-solder the first one once at least one other connection is in place. and if you don't get them flush, but the solder joints are good and you can still get a cable attached, leave it. although you just learned this one the hard way. if you must desolder a header, take off the plastic piece first and desolder one pin at a time. good luck. don't worry about the pad, you can still midibox :) ultra

i think this could work. here's what you'd have to do: use the apc40 normally. it should automap itself to clip, instead of you having to map them (if it doesn't suck ass). this automapping happens behind the scenes and still leaves regular midi mapping available. then you midi map as usual from the foot controller, however you'd want to do it. since this foot controller is on its own midi interface, you can map anything anywhere. so basically the answer is, if you're using each one properly (selecting the apc40 script from your list of control surfaces, enabling that input to attach to the script, and setting live to accept a second midi input) it should just work. there might be other options available if the apc40 has physical midi i/o on it (instead of just usb). alternatively, if you know how to code in c, you can wait until i'm done with my midibox/liveapi work and make yourself a controller with the foot pedal integrated into it. you'll have a lot more power and flexibility than the apc40, and you could use those sparkfun buttons for your clip matrix. doing it this way makes it possible to do whatever you want (put clip names on an lcd, etc). ultra

connecting to the gm5 was my first thought too. we had to write a paper at work on various wireless communications, and this was one of them. but i never thought of using it for midi. don't you think the latency might be a problem?

it's on a ucore so pinout is the same. it's a 18f452. not really sure how to switch modes, but stryd said to use a 452 because it supports 8 bit. i routed all the lcd traces for the ucore.

i'm trying to get some displays working that futureman had shipped to me. they're noritake vfd's. they work fine with a core32, but with a pic core i get garbage characters on the screen. the datasheet link is at the bottom of this page: http://parts.digikey.com/1/parts/678533-module-vf-display-40x2-5mm-char-cu40025scpb-w6j.html does anybody have an idea about why it would work with core32 but not the pic core? thanks, ultra

"push to make" and "momentary on" are the same thing. that's what you want for midibox.

can you throw in a bag of catnip?

how much for just the lasers???

superbad

it's spring if you're in the good hemisphere

i've just started working on it for mios32. well actually i've been working on it for a while, but i've been hung up with how to communicate with live. for now (and maybe permanently), i'm going with sysex, and midi made to look like sysex, since live will send but not receive sysex. if you need some tips on where to go, just ask questions here.

it's all just small pieces. understand each one and the whole thing becomes pretty clear.

echopraxia: what i mean is that wilba's control surface pcbs have holes in it that let you mount the ucore directly to it, and the core32 has different dimensions.

no problem xaro

why does the lcd pinout have anything to do with what application he's running?

i haven't looked into it, but i wouldn't know why not. does the mbfm even need the IIC ports?

2!

you're going to have to check the datasheets. i get mine at http://www.alldatasheet.com

i think since we each make our individual boxes for individual reasons, you might have to decide that for yourself. do you need access to all 16 faders at once? personally, i wouldn't mind setting up banks to save money and space. ultra